Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アジャイルに向き合うソフトウェア開発の技術面 "ライトウィング" / Technical aspects of software development towards agile

アジャイルに向き合うソフトウェア開発の技術面 "ライトウィング" / Technical aspects of software development towards agile

7a37d60769f6f3004adee19a8ff2c219?s=128

Yuichi Tsunematsu

January 05, 2022
Tweet

Transcript

  1. アジャイルに向き合うソフトウェア開発の技 術面 "ライトウィング"
 Technical aspects of software development towards agile

    
 Retty, Inc
 常松祐一 / Yuichi Tsunematsu
 5th/Jan, 2022

  2. 自己紹介
 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
 
 SNSアカウント
 • tunepolo : 
 • tune : 

  3. None
  4. アジャイルの「ライトウィング」と「レフトウィング」
 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
  5. • アジャイルのゴールを実現するには「技術 面」も必要なはず。
 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 

  6. 技術面 “ライトウィング” の目的
 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. 

  7. • 自分が経験した事例を紹介。
 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 

  8. アジェンダ
 Agenda
 1. 設計 / Design
 2. 実装 / Implementation


    3. テスト / Test
 4. リリース / Release
 5. 監視/運用 / Monitoring and operation

  9. 1. 設計
 Design
 1. 設計 / Design
 2. 実装 /

    Implementation
 3. テスト / Test
 4. リリース / Release
 5. 監視・運用 / Monitoring and operation

  10. 「アジャイルは設計しない」なんてことはない
 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
  11. 大きな開発を始める前にユースケースと責務を議論
 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.
  12. タスク分解は開発を進めやすくするために行う
 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
  13. 開発に着手する前に実装方針を揃える
 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.
  14. コードを書き始める前にコメントで補足
 Add supplementary information in the comments before you start

    writing code 

  15. 2. 実装 (ブランチ戦略)
 Implemantation : branching strategy 
 1. 設計

    / Design
 2. 実装 / Implementation
 3. テスト / Test
 4. リリース / Release
 5. 監視・運用 / Monitoring and operation

  16. ブランチ戦略とは
 What is branching strategy? 
 Git Flow vs Github

    Flow git-flow GitHub Flow • ブランチの運用ルールのこと
 The branch operation rules. 

  17. ブランチ戦略はアジャイルのゴールに繋がっている?
 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. 

  18. トランクベース開発
 Trunk based development 
 開発者はTrunk(またはmaster)ブランチを共有し、ビルドが通る状態を保ちなが ら、小さな修正を直接コミットする。


  19. 大規模チームでのトランクベース開発
 Trunk based development at scale 
 短寿命(数日)のブランチを作り、PRベースのレビュー・CIを通じてTrunk(または master)にマージしていく。
 大きな機能開発は複数の

    PRが 揃って動作するように作る。 Large development is made so that multiple PRs can work together.
  20. フィーチャーフラグ(トグル)による機能の出し分け
 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. 

  21. 2. 実装 (リファクタリング)
 Implementation : refactoring 
 1. 設計 /

    Design
 2. 実装 / Implementation
 3. テスト / Test
 4. リリース / Release
 5. 監視・運用 / Monitoring and operation

  22. リファクタリングはいつ行うべきか?
 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? 

  23. ボーイスカウトルール : 来た時よりも美しく
 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? 

  24. 削除(不要機能・不要コード)も流れを作る
 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.
  25. ライブラリ更新
 Library update
 • 更新があることに気がつく仕組 みを作る
 Create a system to

    notice 
 that there’re updates. 
 • 更新を継続的に行うことで、自 分たちに合ったやり方が見つ けられる。
 We can find the right way to do this by continuously updating.

  26. 2. 実装 (コードレビュー)
 Implementation : code review 
 1. 設計

    / Design
 2. 実装 / Implementation
 3. テスト / Test
 4. リリース / Release
 5. 監視・運用 / Monitoring and operation

  27. コードレビューの目的
 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. 

  28. コードレビューがうまく回らない要因
 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. 

  29. 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. 

  30. 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. 

  31. 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. 

  32. 自分たちでスタイルガイド・ルールを作らない
 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 設計ガイド
  33. 3. テスト
 Test
 1. 設計 / Design
 2. 実装 /

    Implementation
 3. テスト / Test
 4. リリース / Release
 5. 監視・運用 / Monitoring and operation

  34. 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? 
 
 

  35. 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. 

  36. 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. 

  37. 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.
  38. 「重要なカスタマージャーニー」を継続的にテストする
 Continuously test the "critical customer journey” 


  39. 4. リリース
 Release
 1. 設計 / Design
 2. 実装 /

    Implementation
 3. テスト / Test
 4. リリース / Release
 5. 監視・運用 / Monitoring and operation

  40. 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." 

  41. 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. 
 
 アプリを安全にリリースするための取り組み (Release trainとClient release process) | メルカリエンジニアリング
  42. リリースにかかる工数を抑えるために
 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. 

  43. 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. 

  44. 5. 監視・運用
 Monitoring and operation 
 1. 設計 / Design


    2. 実装 / Implementation
 3. テスト / Test
 4. リリース / Release
 5. 監視・運用 / Monitoring and operation

  45. 計測し、見える化する
 Measure and visualize 
 AWS CloudWatch

  46. 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. 

  47. 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. 

  48. 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. 
 
 Diátaxis
  49. 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
  50. 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?" 

  51. その他
 Other topic


  52. 今日紹介しなかったが有用なプラクティス
 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

  53. Subway Map to Agile Practices


  54. Open Practice Library


  55. 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.