アジャイルサムライ読書メモ
第１章
期待をマネジメントする
期待には明示的な期待と暗黙的な期待がある。
期待は一方的に「設定」して終わりではない。
進退窮まってから「調整」するものでもない。
あらかじめ定められた手段で「管理」もできない。
期待は継続的に「マネジメント」するものだ。
思っている以上にみな期待を伝え合わない。
関係者同士でプロジェクトの期待について話し合い、合意する。
3つの真実
1.プロジェクトの開始時点にすべての要求を集めることはできない
2.集めたとことで、要求はどれも必ずといっていいほど変わる
3.やるべきことはいつだって、与えられた時間と資金よりも多い
第２章
自己組織化
アジャイルチームは自己組織化されていなければいけない。
自己組織化とは、自らのエゴを押し出しすぎないように気をつけながら、チームで力を合わせることである。
顧客
チームには積極的に関わる顧客が必要である。ソフトウェアは顧客のために作られる。顧客はあらゆる要求の「真実の源」である。
アジャイルチームに必要なメンバーの資質
- ゼネラリスト
- 曖昧な状況に抵抗がない
- 我を張らないチームプレーヤー
第５章
リスクについて話し合う
リスクは早めにチームで話し合うべきである。以下のような効用がある。
- 課題が明らかになる。
- 違和感を表明するチャンスとなる
- 単純にすっきりする
小さく考える
本当に大きな仕事を成し遂げようと思ったら、それを小さな、制御できる単位へと分割しなければならない。
著名なFortune500各社の業務改善を行ったランディ・モットは、開発サイクルが6ヶ月を越えないことへのこだわりを持った。
プロジェクトの長さへの期待をマネジメントする
提供する見通しは「最善を尽くした当てずっぽう」を目指しているにすぎない。
見通しを提出するときの選択肢は以下の2つ
- 期日を軸にしてフィーチャを調整する
- 中核をなすフィーチャを届けることにはコミットするが、期日は幅を持たせる
第７章
概算見積もりの問題
見積もりを未来の正確な予測だと思い込んでしまうことに問題がある。
プロジェクト初期段階の概算見積もりは最大で4倍以上の誤差がある(不確実性コーン)
端的に言うと、前もって正確に見積もるなんて無理。
なので、以下の3つの条件を満たす見積もり手法が必要
- 今後の計画を立てられる
- 見積もりは当てずっぽうだという前提を踏まえている
- ソフトウェア開発の複雑さを認めている
相対的見積もりを行う。そして、一人でやるより複数人でやる方が精度があがる。
第８章
計画を固定しない
スコープを柔軟にする。
要求変更の提案機会を与える代わりに、1つストーリーを追加するために1つストーリーを削ってもらう。
見積もりをごまかしつづける「奇跡によるマネジメント」はしない。
事実をありのまま顧客に打ち明ける。
