[読書] アジャイルサムライ
アジャイル開発
読んだ本
| アジャイルサムライ――達人開発者への道 |  |
モチベーション
- こちらも SCRUM BOOTCAMP 同様に、職場から転職前に宿題として送ってくれたものです。
- こちらは、スクラムに特化したものというよりもアジャイル開発全般の実践に関する本でした。
- 著者は、Martin Fowlerの会社である Thoughtworks 社で アジャイルのコーチングをしてきた Jonathan Rasmusson さん
- 2001年のアジャイルソフトウェア開発宣言をベースに、実践的に解説されている本ということで源流の考え方に沿ってアジャイル開発を知ることができる期待大でした。
理解メモ(復習)
第I部：「アジャイル」入門
- 価値ある成果を毎週届ける
- 大量の製品文章や作業報告書よりも実際に動くソフトウェアを毎週提供してくれるほうが、顧客としては助かる
- 大きな問題は小さくする
- 本当に大事なことに集中して、それ以外のことは忘れる
- ちゃんと動くソフトウェアを届ける
- フィードバックを求める
- アジャイルな計画づくりがうまくいく理由
- 現在の状況を、ありのまま誠実に顧客に伝えるので、最初の契約の内容との乖離を受け入れてもらえる
- 完了は完了のことだ
- 動くソフトウェアができたときに完了になる
- 3つの真実
- プロジェクト開始時点にすべての要求を集めることはできない
- 集めたところで要求はどれも必ずといっていいほど変わる
- やるべきことはいつだって与えられた時間と資金よりも多い
- アジャイルチームのご紹介
- 役割分担ははっきりさせず、専任でなくてよい
- 分析、設計、実装、テストといった工程が連続的
- チームで責任を果たそうとする態度。品質に責任を持つのは開発者。品質保証部ではない
- チームをアジャイルにするためのコツ
- 同じ仕事場で働く。一緒に飯を食う。冗談を言い合う。
- エンゲージドカスタマー=プロダクトオーナーが必要。プロダクト開発に深く関わる顧客がいないのは犯罪的。
- 顧客と信頼貯金を貯めていく
- 自己組織化
- 自分たちで計画を立てる
- 動くソフトウェアを提供し続ける
- 自分から動ける人を探す
- 成果責任と権限委譲
- 職能横断型チーム
- チームメンバーを探すコツ
- ゼネラリスト
- 曖昧な役割に抵抗がない人
- 我を張らないチームプレイヤー
第II部：アジャイルな方向づけ
- プロジェクトがだめになるのはなぜか
- プロジェクトを開始するときにそれぞれの意識が合わないことはむしろ自然なこと
- チームメンバーが誰もいないところで合意したことを前提にしているとダメになる
- 手強い質問＝インセプションデッキ
- 我々はなぜここにいるのか
- エレベーターピッチを作る
- パッケージデザインを作る
- やらないことリストを作る
- ご近所さんを探せ
- 解決策を描く
- 夜も眠れなくなるような問題はなんだろう
- 期間を見極める
- 何を諦めるのかをはっきりさせる
- 何がどれだけ必要なのか
- エレベータピッチのテンプレート
- [潜在的なニーズを満たしたり、抱えている課題を解決したり]したい
- [対象顧客]向けの、
- [プロダクト名]というプロダクトは、
- [プロダクトのカテゴリー]である。
- これは[重要な利点、対価に見合う説得力のある理由]ができ、
- [代替手段の最右翼]とは違って、
- [差別化の決定的な特徴]が備わっている
- パッケージのデザインを作る
- ステップ１：プロダクトの効能をブレインストーミングする
- ステップ２：キャッチコピーを決める
- ステップ3：パッケージをデザインする
- ニーバーの祈り：
- 願わくばわたしに、変えることのできない物事を受け入れる落ち着きと、変えることのできる物事を変える勇気と、その違いを常に見分ける知恵を授けたまえ
- 何を諦めるのかをはっきりさせる
- プロジェクトに働きがちなフォース(四天王)
- Q：品質
- C：予算
- D：納期、時間
- S：スコープ
- トレードオフスライダー
- スコープは諦めてもらうことがあることを予め顧客に納得しておいてもらう
- どれも大事なものであることを顧客に伝える
- プロジェクトに働きがちなフォース(四天王)
第III部：アジャイルな計画づくり
- 文書に頼りすぎることの弊害
- 変化に対応できない
- 顧客のほしいものではなく、仕様にあわせてつくることになる
- 下手な憶測や前提を招き寄せる
- 多くの時間を無駄にする
- コラム：その要件は本当に必要条件なのか？
- 要件定義書の5%〜20%を満たせばビジネスの利益の80%を生み出せる様になっている
- 要件は、必要条件でもなければ、必須のものでもない
- よく書けているユーザーストーリーとは
- 技術用語を避けて、顧客がつかっている言葉で表現する
- E2E：エンドツーエンドになっている。アーキテクチャのすべてのレイヤーに渡って書く
- ストーリーが独立している
- 交渉の余地がある
- 予算の範囲内に収めるような余地が残っていると良い
- テストできる
- 小さい、見積もれる
- INVEST：Independent、Negotiable、Valuable、Estimatable、Small、Testable
- ユーザーストーリーのテンプレート
- ＜ユーザーの種類＞として＜達成したゴール＞をしたい。なぜなら＜理由＞だからだ
- Who、What、Why：誰のためのストーリーで、何をしたいのか、なぜそうしたいのか
- ストーリー収集ワークショップを開催しよう
- アジャイルな計画
- 顧客にとって価値のある成果を届けられる計画
- わかりやすくありのままを伝える、誠実な計画
- 約束したことを守り続けられる計画
- 必要に応じて変更できる計画
- 初回の計画づくり
- ステップ１：マスターストーリーリストを作る
- ステップ２：プロジェクト規模を見極める
- ステップ３：優先順位をつける
- ステップ４：チームのベロシティを見積もる
- ステップ５：期日を仮ぎめする
- 途中からなら、インセプションデッキのすべての質問に答えなくても良いが、以下は見ておく
- このプロジェクトにいるのはなぜ
- 成し遂げようとしていることはなに？
- 顧客は誰
- 解決すべき主要な課題は何
- 最終判断を下すのは誰
第IV部：アジャイルなプロジェクト運営
- アジャイルなイテレーション
- ステップ1：分析と設計：作業の段取りをする
- ステップ２：開発：作業する
- ステップ３：テスト：作業の結果を確認する
- ストーリー計画ミーティング
- ショーケース
- イテレーション計画ミーティング
- ミニ振り返り
- デイリースタンド・アップ
- 貼りものの作り方
- インセプションデッキ
- リリースボード
- ストーリーボード
- ベロシティとバーンダウンチャート
第V部：アジャイルなプログラミング
- ユニットテスト:動くことがわかる
- リファクタリング:技術的負債の返済
- 大掛かりなリファクタリングすべきかどうか＝以下の質問をしてみる
- プロジェクトの終了は近いか
- 少しずつやれないか
- 大掛かりなリファクタリングすべきかどうか＝以下の質問をしてみる
- テスト駆動開発
- 継続的インテグレーション:リリースに備える
- ソフトウェアのデプロイを失敗させる要因
- ヒューマンエラー
- タイプミス
- バグ
- チームメンバーとの連絡ミス
- 動作エラー
- 設定ファイルの誤り
- 開発環境とデプロイ環境との違い
- 古くなったドキュメント
- コードを統合していない期間が長くなるほど、マージが難しくなる
- 以下の４つを用意する
- ソースコードリポジトリ
- チェックイン手順
- ビルドの自動化
- 作業単位を小さくしようとする姿勢
- ソフトウェアのデプロイを失敗させる要因
第VI部：付録
- アジャイルソフトウェア開発宣言(引用)：
私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。
プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、
価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。
- アジャイルソフトウェア開発の12の原則(引用)：
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進捗の最も重要な尺度です。
8. アジャイル･プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10. シンプルさ（ムダなく作れる量を最大限にすること）が本質です。
11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
感想
- アジャイルソフトウェア開発宣言をベースとしていることもあり、TDDやリファクタリング、DevOpsがどうアジャイル開発とつながっているのかが理解しやすい本だった印象です。
- 私は長年受託開発に携わって来ましたが、受託開発の悪い点とそれへの対策につながる内容がアジャイルソフトウェア開発宣言にはある気がしました。
- 引用： どうでしょう？われわれはアジャイルでしょうか？ーーー君がアジャイルであるかどうかを確認できる「アジャイルチェックリスト」なんて誰にもつくれないんだ。
- 上記のとおり結局実践あるのみではありますが、源流としてのアジャイルの考え方にふれることができたのは、とてもよかったです。
- 長年ソフトウェア開発をやってきたからこそ、ソフトウェア開発でのアンチパターンに共感しながら、アジャイルソフトウェア開発宣言について考えることができてよかったかなと思います。
最終更新日: May 14, 2024