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 SNSアカウント • tunepolo : • tune :
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
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
• 高速に石橋を叩いて渡る / 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.
• 自分が考案したものではない。 It is not something I invented. • 全ての状況でうまくいくわけではない。 It doesn't work in every situation. Photo by Drew Patrick Miller on Unsplash 期待値調整 Adjusting expectations
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
• ユースケースを拾い上げ正常 系・異常系を網羅しているか確 認。 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.
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
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.
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.
• デプロイなく外部からシステムの振る舞いを変更できるソフト ウェアスイッチ。 Allows you to change the behavior of the system without deploy. • 準備ができたら設定を変えて動くように作る。 When it's ready, change the settings and make it work.
Yurasits on Unsplash • 「リファクタリングの時間が取れない」という言い訳 Excuses for not taking time to refactor. • あなたが知っているすごいプログラマは「リファクタリングして いいですか」と許可をとっていないのでは? The great programmers you know don't ask for permission to refactor, do they?
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?
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.
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.
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.
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.
reason not to use it, so the sooner you use it, the better. • アーキテクチャの決まりや文言、アクセシビリティをチェックす るものもある。 Some of them check architectural rules, texts and accessibility.
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.
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?
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.
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.
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.
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."
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. アプリを安全にリリースするための取り組み (Release trainとClient release process) | メルカリエンジニアリング
/ Automate release ◦ インストーラーを作る。 / Setup Installer ◦ CIを使ったインストール。 / Setup install system via CI ◦ ChatOps / GitOps • 問題時にロールバックできるようにする。 Make it possible to rollback in case of problems.
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.
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.
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. Diátaxis
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
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?"
Unit test / Test Driven Develelopment • Pair programming / Mob programming / Swarming • Canary release / Blue-Green-Deployment • DesignDoc / Architecture Decision Records • Working Out Loud
/ 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
watal
mochan_tk
moepy_stats
amarelo_n24
kochizufan
yuzutas0
tarugoconf
tdys13
yuhta28
oracle4engineer
rakus_dev
sat
marktimemedia
mraible
bryan
danielanewman
maltzj
tenderlove
chriscoyier
bkeepers
yeseniaperezcruz
dougneiner
addyosmani
andyhume
