Agile Studioウェビナー~モブプログラミング＆テスト駆動開発はじめの一歩~

2022年4月のウェビナー資料。

Transcript

1. © 2022 ESM, Inc. Agile Studioウェビナー ~ モブプログラミング＆テスト駆動開発 はじめの一歩 ~ 1 2022年4月20日 株式会社永和システムマネジメント
2. © 2022 ESM, Inc. 目次 2 講義（モブプロxTDD） モブプロ練習の見学 (FizzBuzz問題) Q＆A
3. © 2022 ESM, Inc. ”人間性尊重と技術的卓越 の両方を大切にした 躍動感みなぎるチームを つくりたい！” コーチングのご相談はこちらまで https://www.agile-studio.jp/ienaga いえぴょん（家永英治）
4. © 2022 ESM, Inc. 目次 4 講義（モブプロxTDD） モブプロ練習の見学 (FizzBuzz) Q＆A
5. © 2022 ESM, Inc. 3人以上の人々がコンピュータに 集まって共に問題を解いていく活動 モブプログラミング https://www.youtube.com/watch?v=dVqUcNKVbYg https://www.youtube.com/watch?v=p_pvslS4gEI
6. © 2022 ESM, Inc. 2000年代にエクストリームプログラミングの一部のコミュニティで知られる 2014-15 辺り で Woody Zuillさんの講演での発表で再び脚光を浴びる 日本でも2018年に Agile Japanで講演など認知され、採用が増えている https://agile-monster.com/blog/agilejapan2018-mobprogramming/ モブプロの歴史
7. © 2022 ESM, Inc. 7 なぜモブプログラミング を行う？
8. © 2022 ESM, Inc. Goodな選択肢を選びクオリティを上げるため フロー効率を高めて、一個流しでリリース頻度を上げるため 誰かが抜けてもリリースし続けられるようにするため ものづくりを楽しむため etc… なぜモブプログラミングを行う？
9. © 2022 ESM, Inc. Goodな選択肢を選びクオリティを上げるため 問題定義 x 解決手段の空間 一人の場合の探索 多様な専門家による 集合知を使った探索 問題定義 x 解決手段の空間 一人の知性には限界があり 問題定義が間違っているかも？ (必要とされる背景の誤解、テストパターンの抜 け漏れ etc..) 解決手段が間違っているかも？ (影響範囲調査の見誤り、実現手段A,B,Cの選択 ミス、メンテナンス不能なコード記述 etc…)
10. © 2022 ESM, Inc. Goodな選択肢を選びクオリティを上げるため フロー効率を高めて、一個流しでリリース頻度を上げるため 誰かが抜けてもリリースし続けられるようにするため ものづくりを楽しむため etc… なぜモブプログラミングを行う？
11. © 2022 ESM, Inc. 顧客やユーザに価値がありリリースできるもの リソース効率:一人一人の稼働率の高さを重視する作戦。 レビュー待ち、遅れて設計不備や抜け漏れによって リリースできるものが１つもないに注意 フロー効率を高めて、一個流しでリリース頻度を上げるため TODO DOING REVIEW DONE STORY TODO DONE STORY レビュー中に抜け漏れが発覚して追加タスク。 過去の作業の抜け漏れ、設計不備が発覚し追加タスク DOING& REVIEW フロー効率:「価値を届けるためのリードタイム」を重視 １つ１つ確実に終わらせる作戦
12. © 2022 ESM, Inc. Goodな選択肢を選びクオリティを上げるため フロー効率を高めて、一個流しでリリース頻度を上げるため 誰かが抜けてもリリースし続けられるようにするため ものづくりを楽しむため etc… なぜモブプログラミングを行う？
13. © 2022 ESM, Inc. バス因子：「自分 のいるプロジェクトで、 明日姿を消したらプロジェクトやチームが 破綻してしまうと いう人はいるだろう か？」 誰かが抜けてもリリースし続けられるようにするため 単一障害点 ボトルネック 成長の阻害要因 知識共有 スキル伝搬 認知的徒弟制
14. © 2022 ESM, Inc. Goodな選択肢を選びクオリティを上げるため フロー効率を高めて、一個流しでリリース頻度を上げるため バス因子問題に取り組み、誰かが抜けてもリリースし続けら れるようにするため ものづくりを楽しむため etc… なぜモブプログラミングを行う？
15. © 2022 ESM, Inc. ものづくりを楽しむため やったー
16. © 2022 ESM, Inc. モブプログラミングの 最低限の原則 16
17. © 2022 ESM, Inc. 優しさ、思いやり、尊敬 多様なメンバーで見解が一致しない対話が続くことが”ふつう”だからこそ、大切にする原則 https://github.com/kawaguti/mobprogramming-woodyzuill-ja/blob/master/mobprogramming-ja.md
18. © 2022 ESM, Inc. Googleなら 謙虚、尊敬、信頼 心理的安全性
19. © 2022 ESM, Inc. 必要ならモブ前に チームビルディング のワークを
20. © 2022 ESM, Inc. モブプログラミングの よくあるコツ 20
21. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ
22. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ ドライバー:コード書く人（タイピスト）と ナビゲーター：アドバイスする人 に別れる
23. © 2022 ESM, Inc. 追加補足：タイピスト
24. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ 作業の段取りを TODOリスト や図解
25. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ 頭の中で考えて いることを声に だす
26. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ わからないこと があれば助けを 求める
27. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ ドライバー 時間交代
28. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ 小さなタスク単位 で交代
29. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ 特定の1人２人のみ が喋りすぎに注意 (アンチパターン)
30. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ 他の人に話す 機会を譲る
31. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ 必要ならファシリ テーターを立てる
32. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ 同調圧力が起きているなら 「悪魔の代弁者」役を立てるも 一案
33. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ 先行調査、ルーチンワークなど 作業内容応じてモブを分割
34. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ 休憩を忘れずに
35. © 2022 ESM, Inc. https://www.agilealliance.org/resources/experience-reports/harvesting-mob-programming-patterns-observing-how-we-work/ https://github.com/michaelkeeling/mob-programming-patterns モブプロのこつ チームで一度読み合わせや ふりかえりでブラッシュアッ プを続けるはお勧め
36. © 2022 ESM, Inc. テスト駆動開発と モブプログラミング 36
37. © 2022 ESM, Inc. RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA 1.はじめの一歩のテストケ ースを選ぶ 2. テストコードを書く 2. テストをパスする必要最 低限のコードを書く 3. リファクタリングし コードを整える 4. （完成まで続ける） 10分以下のサイクル
38. © 2022 ESM, Inc. プログラミングは色々なこと を検討しながらコードを記述する とても複雑な行為です。 一人で解決不能なら複数人で
39. © 2022 ESM, Inc. RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA ソフトウェアを使うユーザ の置かれた状況や困りごと って？ どの順番で作ると 完成できそう？ 何ができたら完成と言 える？テストケースの 抜け漏れは？ テストコードを読んで 仕様が理解できる記述に なっているだろうか？ メンテナンス可能なテスト コードだろうか？ テストしやすい設計を 導くテストコードだろう か？ あれGreenにできない。 エラーの意味は。。。 順番入れ替えてテストケ ース２を先にやった方が 先に進めるかも 実現手段A ,B,Cのなかで シンプルなのは。。。 修正による影響範囲は Xxxなので。。。 メンテナンス可能な プロダクションコードだ ろうか？
40. © 2022 ESM, Inc. 他人と会話しながら 確実にクリアにし タスクを終わらせていく
41. © 2022 ESM, Inc. RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA ソフトウェアを使うユーザ の置かれた状況や困りごと って？
42. © 2022 ESM, Inc. RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA 何ができたら完成と言 える？テストケースの 抜け漏れは？
43. © 2022 ESM, Inc. RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA ルートA,B,Cのどの順 番で作ると安全に素早 く完成できそう？
44. © 2022 ESM, Inc. RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA ユニットレベルで 動作確認できるようにするには？ （テストしやすい設計の判断）
45. © 2022 ESM, Inc. RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA テストは仕様が理解できる記述 だろうか？ （コードはドキュメント）
46. © 2022 ESM, Inc. RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA エラーレポートは 理解できる記述だろうか？
47. © 2022 ESM, Inc. RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA 修正による影響範囲は ….
48. © 2022 ESM, Inc. RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA 実現手段A,B,Cの中で良 さそうなのは。。。
49. © 2022 ESM, Inc. RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA あれGreenにできない。 エラーの意味は。。。
50. © 2022 ESM, Inc. RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA メンテナンス可能な プロダクションコードだろうか？ （コードはドキュメント）
51. © 2022 ESM, Inc. 実装中に新たなテストケースを発見 したら追加 RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA
52. © 2022 ESM, Inc. ルートA,B,Cの段取りが ダメとわかれば、 ルートZと立て直し RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA
53. © 2022 ESM, Inc. 実現不可能とわかれば、ユーザの困り ごとや達成したいことに立ち返って、 作戦の立て直し RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA
54. © 2022 ESM, Inc. 他にもたくさん！！！ RED Green Refactor テストケース1 テストケース2 テストケース3 あとで発見した テストケースD StoryA
55. © 2022 ESM, Inc. ユーザにとって役立ち ＆ 開発者にとってメンテナンス可能な プロダクトにするために 複数人の知恵を組み合わせ 難問に立ち向かう
56. © 2022 ESM, Inc. 目次 56 講義（モブプロxTDD） モブプロ練習の見学 (FizzBuzz) Q＆A
57. © 2022 ESM, Inc. 57 今日のルール
58. © 2022 ESM, Inc. 優しさ、思いやり、尊敬 Punch List (テスト項目をタスクリストに) ナチュラルスワップ （タスクのキリの良いところでニックネームで呼んでドライバー役を引き渡す） テストパスしたらやったー 60分で休憩 チェックアウト(小さくふりかえり) 今日のルール