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

  • 安井さんから1月下旬に頂いた「アジャイルな見積りと計画づくり」。

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

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

  • なんと読むのに二ヶ月かかってしまった...
  • 言い訳すると...印象に残った所に付箋をペタペタ貼っていたため。

  • 大変遅れてしまって申し訳ないが、読後感想などを...

全般

  • これからAgileを始めたい人はもちろん、既にAgile開発に詳しいつもりの人も、「俺はウォーターフォールでいいんだ」という人にも是非読んでもらいたい本。
  • 特に「進行基準」に興味ある人には強く推薦。
  • 読んだ後は「見積りを精査します!」なんて言ってる人を、「あー、バカなこと言ってるねぇ」と鼻で笑えるようになるよ。
  • 既にAgileに入れ込んでいる人でも、「なるほど」と思わせるテクニック多数。
  • 狩野分析法をしっかり解説した章もある。
  • 訳文は非常に読みやすい。
  • カタカナのままになってるAgile用語がちょいと気になるが、これは今後のAgileコミュニティ*1の努力でなんとかするしかないでしょ。

印象に残った言葉

  • 「なるほど!」「そうなんだよねー(うんうん)」と思った部分を抜粋。
  • 前後の文脈読まないと意味不明な所もあるかもしれないが、気になったら買って読んでみて。

第一部 問題とゴール

フィーチャではなく作業を計画している
(36頁)

パーキンソンの法則
(37頁)

マルチタスクが遅れを助長する
(41頁)

見積りがコミットメントになっている
(43頁)

フィーチャの技術的な依存関係を極力なくす
(50頁)

プロジェクトというものを定められた一定の手順を実行するだけだと考えるべきではない。むしろ、プロジェクトとは、新たな機能と知識とを迅速かつ安定して生みだし続ける活動と捉えるべきなのだ。
(51頁)

計画づくりとは学びたいことをはっきりさせることであって、(プロダクトを)どうしたいかを決めるものではない
(52頁)

目に見える範囲を大きく超えて計画を立てているにも関わらず、計画を見直す時間を組み込んでいないのであれば、そのプロジェクトは危険にさらされていることになる。
(53頁)

もしそうなれば、計画は変更すべきである。
(56頁)

第二部 規模を見積もる

アジャイルチームは規模の見積りと期間の見積りとを分けて考える。
(59頁)

ソーダを400グラム、ラザニアを170グラム、パンは85グラムください」などと言ったりはしないだろう。
(61頁)

アメフトのファンは試合の終了予定が4時だとしても、それが見積りに過ぎないことを経験から学んでいるのだ。
(68頁)

ある程度以上の労力を費やしても、見積りの正確さには寄与しない
(72頁)

見積もるための労力をかけすぎると、かえって不正確な結果を招くことがある。
(73頁)

見積りにゼロを使えると便利な事が多い
(75頁)

私が色々試した結果、アジャイルチームで一番うまくいくことがわかった見積り技法がプランニングポーカーである。
(79頁)

見積りでは絶対的な精度は重要ではない。妥当な労力に見合った妥当な結果を出すことが重要なのだ。
(80頁)

議論を長引かせないために
(81頁)

プランニングポーカーがうまくいく最後の理由は、それが楽しいからだ。
(83頁)

見積りに一貫性があることが重要なのだ。不正確ならば一貫して同じくらい不正確であればよい。
(87頁)

進捗が想定どおりでないという理由だけで再見積りしてはならない。
(91頁)

些細な違いに思えるかもしれないが、この考え方の違いは大きい。
(93頁)

ストーリーポイントにも欠点はあるが、ほんのわずかである。
(97頁)

第三部 価値のための計画づくり

そこで優先順位が必要となる。
(100頁)

フィーチャの優先順位付けに必要な、次の4つの要素を解説する。
(101頁)

プロジェクトには様々な種類のリスクがある。代表的なものは次の3つだ。
(105頁)

テーマの優先順位付けに回収期間を使うことで2つの利点がある。
(125頁)

狩野モデル
(128頁)

相対的重み付け
(134頁)

なぜ相対的悪影響を含めることが重要なのか
(135頁)

経験を積めば積むほど、簡単にストーリを分割できるようになる。
(137頁)

大きなストーリをうまく分割する手法の一つが、扱うデータによる分割だ。
(139頁)

操作の境界で分割する
(140頁)

パフォーマンス制約をストーリにする
(142頁)

ストーリをタスクに分割してはならない
(143頁)

第4部 スケジュールを立てる

リリース計画が、チームの現時点での最終目標とする地点を示してくれる。
(148頁)

ユーザストーリーは提供するフィーチャの説明であって、こなすべきタスクではない。
(149頁)

プロジェクトが進むにつれてチームが学習を深めていくと、間違いなく計画は進化していく。
(152頁)

私がちょうど良い落としどころだと考えるのは以下のようなやり方だ。
(152頁)

できあがったリリース計画を棚にしまい込んで、二度と眺めないようなことになってはならない。
(153頁)

新興ベンチャ企業なので予算も限られている
(155頁)

それぞれのタスクがどのストーリに結びついているのかがわかるようにしておくこと。
(159頁)

計画作りの現場ではカードの方が使いやすい
(159頁)

カードを使った方が民主的で協調を重視する手法だ。
(161頁)

イテレーションプランニングではタスクに担当者を割り当てない。
(161頁)

ベロシティ駆動
コミットメント駆動
(163頁)

新しいイテレーションの優先順位づけは、実際にそのイテレーションが始まる数日前に済ませたほうがいい。
(165頁)

もっとも効率よく今日の天気を当てる方法は「昨日と同じ天気」と答えること。
(165頁)

テストのタスクは重要だ。
(167頁)

イテレーション計画に「メール返信・1時間」というタスクを加えないこと。
(167頁)

ミーティングはタスクに含める。
(168頁)

アジャイルプロジェクトではグループで見積もるべきだと確信している。
(171頁)

詳細な設計を議論する機会は、イテレーション計画とは別に設けるべきだ。
(172頁)

頻繁に変わる情報は気軽に書き換えられる手書きのカードと相性がよい。
(172頁)

質問は「いま洗い出したタスクの完了を確約しますか」ではないことだ。
(174頁)

見積りはあくまでも「見積り」であって保証ではない。
(175頁)

ここで鍵となるのは、チームメンバーひとりひとりが自分の得意分野以外でもやれることを探してチームに貢献することである。
(175頁)

保守やサポート業務をこなさなければならないチームにとって、こうした臨機応変な対応を避けて通ることはできない。
(177頁)

だから私はイテレーション計画ではベロシティを使わないようにしている。
(179頁)

ここに魔法はないのだ。
(181頁)

イデアがソフトウェアになるのは平均1.5イテレーションの時間を要する。
(183頁)

アプリケーションはゼロからの書き直しだったので、イテレーションのオーバーヘッドは無視できるほどわずかなものだった。
(188頁)

リリースが次の四半期にずれ込むというのは、上場企業にとっては一大事である。
(189頁)

ここで注目してほしいのは、私が気にかけているのは個々のステップ(運転、駐車、チェックイン、保安検査)の遅れではないということだ。
(204頁)

守ろうとしているのは重要な締切り、つまりプロジェクト全体の締切りだ。
(207頁)

必要なのは50%見積りと90%見積りである。
(208頁)

二乗和平方根
(209頁)

スケジュールバッファは水増しではない
(212頁)

納期やフィーチャを交渉で切るのなら、交渉すべきだ。
(213頁)

バッファは全員がスケジュールに自信を持てるようにするためのものだと説明するのだ。
(213頁)

移動する先読み範囲(Rolling Lookahead Window)
(218頁)

合流バッファ
(220頁)

第五部 トラッキングと情報共有

完了していない作業をポイントとして数えてしまうと、3つの大きな問題が発生する。
(228頁)

その中間は無視するのだ。
(228頁)

未完成の作業は、仕掛かり作業として開発プロセスの流れの途中に積み上がっていくことになる。
(229頁)

コーディングに取りかかる前に、抽象度の高い受け入れテストを用意するのだ。
(239頁)

タスクボードを設置するときは「作業中」の列の幅はカード1枚分
(240頁)

投入した工数の実績と見積りとを比較すると「評価への不安」を招きやすい。
(242頁)

警告する。個人のベロシティをトラッキングしてはならない。
(243頁)

重要なのはチームとしてのベロシティだ。
(243頁)

見積りと計画に関しては、何を伝えるかよりもどうやって伝えるかが重要だ。
(245頁)

正直なコミュニケーションなしに、開発チームと顧客とが互いを信頼することはできない。
(245頁)

見積りと計画作りで、双方向のコミュニケーションが欠かせないのは、計画について対話し、議論を深めることが重要だからだ。
(246頁)

単に聞いてもらうだけではなく、理解させるのだ。
(246頁)

ガントチャートにはフィーチャを載せるべきだ.
(248頁)

あと何イテレーション必要かを予想する最善の方法は、予想の根拠に使うベロシティに幅を持たせることだ。
(249頁)

どうでも良いこと

  • 第十章の「金銭的価値による優先順位づけ」は、インフレ経済を前提に書かれている。
  • デフレ経済下における「金銭的価値による優先順位づけ」はどうなるのだろう?

*1:あーカタカナだ