「アジャイルな見積もりと計画づくり」を読んで

アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~

関西Ruby会議02のときに訳者の角谷さんからサインを頂いた本、1ヶ月かけてしまいましたが読み終わりました。

アジャイル開発といったら、僕も正直なところ「テキトーに開発していくんでしょ」のような印象を持っていたのですが、どれだけ間違った理解をしていたのかを思い知らされました。
全く逆で、プロジェクトを良いものにするためには不確実性をどう管理すればよいかを真摯に考えた成果、なんですね。だから計画や振り返りは非常に細かくやる。

読んでいくにつれ、自分の携わっているプロジェクトがどれだけ不確実性に対して無策でいい加減で破滅的なのかという絶望感ばかりが感じられて非常に苦しかったです。
しかし、いきなり「アジャイルやろうぜ！」と本で紹介されているような運営方法を無理に導入しても、メンバーの反発は目に見えているわけで。チームメンバー全員の協力が得られなければ、いくら良い運営方法を使ってもその効果は薄いでしょう。
未経験の手法を嫌う慣性に支配された環境を、どうやったらモダンな手法へ移行させていけるか、悩みます。「最初は反対意見があった中でもアジャイル開発を導入してプロジェクト管理を改善したぞー」という体験談が載ってる本や記事ってないかなぁ。

プロジェクトの進め方まとめ

• リリースプランニング
  • プロジェクトの満足条件設定
    • 納期主導か、フィーチャー主導か、など
  • ストーリーの洗い出し、見積もり、優先度付け
    • ストーリーポイント or 理想日 で
  • イテレーションの長さを決定
  • 初期ベロシティの見積もり
  • リリース日、盛り込むストーリーの決定
• イテレーションプランニング（新しいイテレーションの開始時）
  • 優先度の高いストーリーをタスクに分解
  • 各タスクの所要時間を見積もり
    • タスクに担当者は割り振らない、あくまでチームとしてのタスク
  • このイテレーションで取り組むストーリーの決定
• 1イテレーションの開発作業
  • タスクボード、バーンダウンチャートでモニタリング
• イテレーションレビュー
  • 関係者に成果物を見てもらいフィードバックを受ける
  • リリースプランニングの見直し
    • ベロシティ再計算
    • バーンダウンチャートで可視化
• 次のイテレーションプランニング
• …リリースまでイテレーションを繰り返す

疑問点

• 期間もフィーチャーも固定されていて、「間に合わなさそうなら人を増やす」というプロジェクトは多そうだが、プロジェクト途中で人員の増減があった場合のベロシティの見積もりはどうすべきか。
• 成果・進捗はチーム全体のもので、個人単位のトラッキングを行ってはならない、というのは賛成。ただ、現実の会社組織の中で適用しようとすると「人事評価をどうするか」が問題にならないか。
  • 単純に、チームがどれだけ利益をもたらしたかをメンバー全員の評価に反映する、というので済む話か
• フィーチャーごとの仕様書など、ドキュメント作成が求められる場合、その分の作業もタスクの一つとするんですよね。