自己紹介 Self introduction 顧客にとって価値のあるプロダクトを、チーム一丸となって協力し、短期間にリリースす る開発体制のあり方を模索しています。 I'm trying to find a way to create a development system where the entire team can work together to release products that are valuable to customers in a short period of time. 常松祐一 / Yuichi Tsunematsu ● Engineering Manager ● Software Engineering Coach ● Agile Development
アジャイルの「ライトウィング」と「レフトウィング」 Two aspect of agile, “right wing” and “left wing” https://blogs.itmedia.co.jp/hiranabe/2012/09/rightwing-and-leftwing-of-agile.html “Left wing” Culture and mindset “Goal of agile” business value, etc “Right wing” Technical practice
● アジャイルのゴールを実現するには「技術 面」も必要なはず。 We need to learn “technical practice” for agile goal. ● 事例を広く共有し、良い知見を探究していき たい。 I would like to share the case studies widely and explore good knowledge together. Photo by Thomas Serer on Unsplash 今日の話の背景 Background of today’s talk
技術面 “ライトウィング” の目的 Purpose of “Right wing” a.k.a technical practice ● 高速に石橋を叩いて渡る / Hit the stone bridge and cross at high speed ○ 早期に失敗する / Fail earlier ○ 高速に失敗する / Fail faster ○ 頻繁に失敗する / Fail more frequently
● 上記を実現する技術プラクティスを紹介します。 I will now introduce the technical practices that make the above possible.
● 自分が経験した事例を紹介。 A case study of my own experience. ● 自分が考案したものではない。 It is not something I invented. ● 全ての状況でうまくいくわけではない。 It doesn't work in every situation. Photo by Drew Patrick Miller on Unsplash 期待値調整 Adjusting expectations
「アジャイルは設計しない」なんてことはない There is no such thing as "enagile does not design in agile development 「アーキテクチャ」「クラス・テーブル設計」「言語 ・技術選定」が取り上げられるが、他にすべきこ とがある。 "Architecture," "Class and DB Table Design," and "Language and Technology Selection" are covered, but there are other things that need to be done. Photo by Evgeniy Surzhan on Unsplash
大きな開発を始める前にユースケースと責務を議論 Discussing use cases and responsibilities before starting huge development ● ユースケースを拾い上げ正常 系・異常系を網羅しているか確 認。 Confirm that use cases are properly picked up and that normal and error paths are covered.
● 総務・営業・企画・CS・QAなど 関係者を含めて行う。 Include all stakeholders such as general affairs, sales, planning, CS, QA, etc. Minutes from the discussion of the coupon verification process of "Go to Eat" campaign.
タスク分解は開発を進めやすくするために行う Let's do task planning to make it easier to proceed development ● 分担して進めやすい形を考える Think through a form that is easy for the team to share and proceed with.
● 細かければ良いわけではない It is not enough to have a detailed unit.
● 付箋を使えば良いわけではない It's not enough to use sticky notes. Sprint backlog for recommend feature development
開発に着手する前に実装方針を揃える Aligning implementation strategies before starting development ● 実装が終わってからPull Requestで設計議論を始めない。 Don't start design discussions with pull requests after implementation is finished. Feature requests to add radio button to hide some contents. Throughout the discussion, developers found it desirable to control the function, not the display.
ブランチ戦略はアジャイルのゴールに繋がっている? Is branching strategy linked to agile goal? Photo by Evgeniy Surzhan on Unsplash ● コントロールできることがリリースまでの長期化に繋がってい ないか。 The ability to control change lists makes it easy to prolong the release process.
● ブランチの寿命を短くし、細かく統合し続けなくてはならない。 Need to keep branch lifetimes short and keep integrating continuously.
大規模チームでのトランクベース開発 Trunk based development at scale 短寿命(数日)のブランチを作り、PRベースのレビュー・CIを通じてTrunk(または master)にマージしていく。 大きな機能開発は複数の PRが 揃って動作するように作る。 Large development is made so that multiple PRs can work together.
フィーチャーフラグ(トグル)による機能の出し分け Enable/disable features by feature flag (a.k.a. feature toggle) ● デプロイなく外部からシステムの振る舞いを変更できるソフト ウェアスイッチ。 Allows you to change the behavior of the system without deploy.
● 準備ができたら設定を変えて動くように作る。 When it's ready, change the settings and make it work.
リファクタリングはいつ行うべきか? When should we refactor code? Photo by Brian Yurasits on Unsplash ● 「リファクタリングの時間が取れない」という言い訳 Excuses for not taking time to refactor.
● あなたが知っているすごいプログラマは「リファクタリングして いいですか」と許可をとっていないのでは? The great programmers you know don't ask for permission to refactor, do they?
ボーイスカウトルール : 来た時よりも美しく Boy scout rule : “Always leave the campground cleaner than you found it Photo by Andrea Sánchez on Unsplash ● 修正を入れるたび、元より綺麗なコードにする。 Make the code cleaner every time you commit it.
● タスク分解時に「リファクタリングする」タスクを積んでみたら? How about adding a "refactoring" task automatically when planning?
削除(不要機能・不要コード)も流れを作る Also create a flow for removing unnecessary functions and codes Create a branch to remove unnecessary code, and verify and release it all at once. In most cases, the main page will be tested automatically, and if there are no errors, judges it's OK.
ライブラリ更新 Library update ● 更新があることに気がつく仕組 みを作る Create a system to notice that there’re updates. ● 更新を継続的に行うことで、自 分たちに合ったやり方が見つ けられる。 We can find the right way to do this by continuously updating.
コードレビューの目的 Purpose of code review Photo by John Schnobrich on Unsplash ● “The primary purpose of code review is to make sure that the overall code health of Google’s code base is improving over time.” from Google Engineering Practices Documentation
○ バグを見つけるプロセスではない。 It's not a process of finding bugs. ○ 「読みにくいんですけど」と率直に指摘したい。 I would like to point out frankly, "It's hard to read.
コードレビューがうまく回らない要因 Factors that prevent code reviews from running well Photo by Aubrey Odom on Unsplash 1. 特定の人しかOKを出さない、出せない。 Only certain people will or can give you the OK. 2. 自動アサインされ、他の人は見ない。 Automatically assigned and no one else sees them. 3. コードを書くことだけが仕事だと思っている。 Developer think their only job is to write code. 4. 普段からよい設計を考えておらず、コメントが浮かばない。 Because they don't usually think of good design, they can't come up with any comments.
Photo by christopher lemercier on Unsplash レビュー自動アサインの悪い面 The bad aspects of automatic review assignments ● 「偏らないように使っている」というが、レビューしない人がいる問題 をこじらしているだけでは? Some people say, "We use automatic assignment to avoid unbalanced man-hours," but isn't that just complicating the problem that some people don't do reviews?
● 「レビューも開発の大事な仕事だからやれ」ではダメ? Isn't it enough to say, "Reviews are an important part of development, so do them.
● 早くレビューすればデリバリーまで短くできる。 If you review quickly, you could shorten the time to delivery.
linter/formatterの活用 Utilize of linter/formatter ● さっさと入れた方が良い。 There is no reason not to use it, so the sooner you use it, the better. ● アーキテクチャの決まりや文言、アクセシビリティをチェックす るものもある。 Some of them check architectural rules, texts and accessibility.
linter/formatterを頻繁に動かす Run linter/formatter frequently ● エディタと連携させる設定を知らない人が意外といる。 Some developer don't know the settings to link with editors.
● Git hooksを設定し動かす。commit・pushの前など。 ○ husky(Node.js), pre-commit(Pytnon), Lefthook(Go) Set up and run Git hooks in the repository, pre-commit and pre-push timing.
● CI(Continuous Integration)でもチェックしよう。 ○ Danger JS, Reviewdog Check in CI process.
自分たちでスタイルガイド・ルールを作らない We should not create our own style guide/rules. ● テックジャイアントがコストかけて作ったものを超えるのは大変。 It's hard to surpass what the tech giants have cost to build. Google Style Guides API 設計ガイド
Photo by Glenn Carstens-Peters on Unsplash テストが多いほど良いわけではない More tests are not always better ● 失敗しないテストは書く意味がない。 There is no meaning to write tests that never fail.
● 「その単体テストはどういう時に失敗するんですか?」 “When does the unit test fail?”
● 「その障害は単体テストがあれば防げましたか?」 Could the incident have been prevented by the unit test?
Photo by Artur Pokusin on Unsplash 意味のない自動テストが書かれる要因 Backgrounds that produce meaningless tests ● 実装とテストが別の人/別タスク Implementation and testing are done by different people/ they’re separate tasks.
● カバレッジ目標の門番化 Coverage goals as a gatekeeper.
● どんなテストケースを書くべきか話せていない Developer doesn't talk about what test cases to write with teams.
Photo by Jerry Wang on Unsplash テストコードよりテストケースのレビューをしたい We'd rather review test cases than test code ● どんな状態を想定してテストを用意したのか、わかるように 書いて欲しい。 Write test description so that everyone could understand the test target and scope easily.
● 英語で説明できないなら日本語で書いてほしい。 If you can't explain it in English, please write it in your native language.
Table Driven Tests Table Driven Unit Tests in Go Table Driven Tests Given a table of test cases, the actual test simply iterates through all table entries and for each entry performs the necessary tests. The test code is written once and amortized over all table entries, so it makes sense to write a careful test with good error messages.
Photo by Ibrahim Boran on Unsplash リリース日をコントロールするメリットとは? What’s the benefits to control release timing? ● 「今日は差分が少ないからスキップし ましょう」 "There's not enough diffs today, let's skip it."
● 「この機能を入れたいのでリリースを延 期しよう」 "We want to add this feature, so let's postpone the release."
Photo by Rachel Loughman on Unsplash 定期リリースでリズムを作る Create a rhythm with the regular release ● 不具合が入り込んだタイミングが特定しやすい。 It is easy to identify when a defect enters the system.
● リリース作業を簡単にする力学が働く。 Mechanisms to simplify the release process
● リリーストレイン = 電車の時刻表のように時期が来たらリリー スを行う。 Release train = release when the time has come, like a train timetable.
リリースにかかる工数を抑えるために To reduce the man-hours for release ● 自動化を進める。 / Automate release ○ インストーラーを作る。 / Setup Installer ○ CIを使ったインストール。 / Setup install system via CI ○ ChatOps / GitOps ● 問題時にロールバックできるようにする。 Make it possible to rollback in case of problems.
Photo by Matthew Smith on Unsplash Rettyのリリースサイクル Release train cycle in Retty Inc. ● Web : 1 release /day ○ 飲食店・カスタマーサポート・営業に事前周知が必要なこともあ り、1日1回で十分。 Once a day is enough since CS, restaurants, and sales need to be informed in advance.
● Mobile App : 1 release / week ○ プラットフォーム側のレビューがある。 ○ すぐ切り戻しができないため検証も念入りに。 Because of the platform-side review. Because of the lack of immediate cutback, verification is also very careful.
Photo by Luke Chesser on Unsplash 警告・エラーを0にする。 Keep the number of warning / error to 0 ● おかしな状態が一目でわかるように。 To be able to see strange conditions at a glance.
● 「このエラーは大丈夫なもの」のような見分け方を人は容易に 身につけてしまうが、将来見る人にとってノイズになる。 It is easy for people to learn to distinguish between errors like "this error is okay", but it becomes noise for future viewers.
Photo by Luke Chesser on Unsplash 毎日見る、みんなで見る Check everyday, check with all team members ● 問題発見の属人化を防ぎやす くできる。 Enables multiple developers to find problems.
● 問題を直す動機づけになる。 Motivates developers to fix what's wrong.
Photo by Arisa Chattasa on Unsplash ドキュメントで全てを引き継げるという幻想 The illusion of being able to hand over everything to others in a document ● 量が多ければ良いものでは無い。目的を明確にする。 A large amount of documentation is not necessarily good. Clarify the purpose. ● 見る人がいないドキュメントは価値がない。 If there is no one to see it, it is worthless.
Photo by Hans Eiskonen on Unsplash バス係数(トラックナンバー)を小さく保つコツ Tips for keeping the bus factor (track number) small ● タスクを日頃から分担して属人化を防ぐ。 Work together on tasks on a regular basis to prevent dependency. ● スキルマップを作り、ボトルネックを意識する。 Create a skills map and be aware of bottlenecks. スキルマップ作成のすすめ | Ryuzee.com
Photo by Hans Eiskonen on Unsplash それでも作業を属人化させる人がいる時 Advice for when someone still monopolizes the work ● 「離れる時に引き継ぎ資料をたくさん書きたいですか?」 "Do you want to write a lot of handover material when you leave?"
● 「お休みから戻った時に仕事が進んでいる・終わっているほう がよく無いですか?」 "Wouldn't it be better to have your work in progress or finished when you return from vacation?"
今日紹介しなかったが有用なプラクティス Useful practices that were not introduced today ● Unit test / Test Driven Develelopment ● Pair programming / Mob programming / Swarming ● Canary release / Blue-Green-Deployment ● DesignDoc / Architecture Decision Records ● Working Out Loud
Photo by William Bout on Unsplash まとめ Conclusion ● 高速に石橋を叩いて渡る / Hit the stone bridge and cross at high speed ○ 早期に失敗する / Fail earlier ○ 高速に失敗する / Fail faster ○ 頻繁に失敗する / Fail more frequently ● アジャイルのゴールにつながる技術プラクティスを研鑽して身 につけていきましょう。 Study and learn the technical practices that lead to the goals of agile.
tunepolo
hiashisan
mixi_engineers
devopstaiwan
pauli
imsaku
kyonmm
bengo4com
karawoo
whywaita
miu_crescent
riru
nagiss
skipperchong
destraynor
jmmastey
eileencodes
danielanewman
rmw
bkeepers
searls
scottboms
addyosmani
ammeep