アジャイルな見積りと計画づくり

こんばんわ、いまさらですが読んでおります。名著といわれる「アジャイルな見積りと計画づくり」
よくあるウォーターフォール型開発をただ否定しまくる本ではもちろんなく、アジャイル開発の手法のXPでペアプログラミングしてイテレーション切れば身長が180cmになって彼女ができてモテモテ！というような本ではもちろんありません。

最初のほうは今までの方法がどう間違っていたのか、なんで間違えていたのか。を解説しています。
不確実性の把握、予想、根拠。顧客との信頼が最も重要であること、顧客を含めて一つのチームとして動くことの重要性。要件が明確に鳴っていない時点での見積りがコミットメントしてしまうことの間違え。
そういった所に重きが置かれています。
ここだけでも「なるほど！」となること請け合いです。

後半になると実際の計画の立て方、見積りの立て方、不確実性の読み方（不確実性コーン）、バッファの見方、及びバッファ算出の根拠。といったところをいくつかの手法を丁寧に解説しています。
また、この筆者自体が経験した体験談を交えて「こうするとうまく行った」という実体験で現実感を与えます。

アジャイル開発というと「XPでペアプログラミングしてイテレーション切れば身長が180cmになって彼女ができてモテモテ！」とか「無計画でも大丈夫！随時見てもらえば詳細な計画なんてなくても大丈夫！」とか考えてしまう人も実際にいますが（いや本当にいるんですよ）そうではない。という。
計画を計画することが凄く重要で、常に緊張感を持って開発を行うこと。いってみれば一つのプロジェクトを短い期間、細かい単位に区切ってPDCAサイクルに近いものをなんども回す。という感じです。

受託開発だとよくあることの一つとして予算も期間も決まっている。開発するものも大体きまっている。というものです。（要件定義はされていないが既にフィーチャがまとめられている）
という案件です。
これを見たときに絶対無理！と判断するのは誰でもできる。でも、予算も期間も決まっているのであればそのなかでできることはなにか、どの機能の開発ならコミットメントできるか、どの機能が絶対条件になるのか、を話しあえばリリース時点で必要なものだけの実装で事足りるかもしれない。そのためにも顧客満足条件というのを適切に話しあって把握（設定）する必要がある。
そういった具体的な例も含まれています。

一昔まえに「アジャイル型開発」という言葉が大流行して一人歩きしていたときに
アジャイル開発の説明にたまに見られたのが大規模案件（数百人月プロジェクト）や自社内開発、パッケージ開発、請負の業務系開発がベースで話されていてWEB受託開発（規模はせいぜい数十人月（時には数人月）で予算は決まっていて開発期間も短い）には通用しない手法ばかりが述べられているもの（マインドはもちろん参考になる）。
ですがこの本の場合はそういった短期プロジェクトにも応用がきく手法がたくさん解説されています。

これは名著や！という感じですので本当にいまさらですがPMの方、開発系のディレクタの方、プログラマの方で読んだことない方は是非読んでみてください。
できれば営業やクリエイティブの方も読んで損はありません。開発もクリエイティブも結局目指すべきものは同じなのでマインドは同じはずなんです。（ちょっと開発に特化した書き方をしてあるので慣れない単語は多いと思いますが・・・）

結構読みやすいですが繰り返し繰り返し同じ章を読んだりしちゃうので時間はかかります。
冬の夜は寒くて長いですからね・・・是非！