よい計画とは信頼できて重要な判断の基に耐えうる計画のことである。 ウォーターフォールと違って計画づくりはプロジェクト全体を通して行われ、よくある誤解のように全くしないということはない。 開発者たちの状況にあわせて変わっていくからである。つまり開発者の知識や技術のアップデートも含まれる。 そして計画を基に判断する側もアジャイルを理解していないと行けない。

まえがき 　まず、アジャイルチームは頻繁に計画づくりをおこなうが、プロジェクト全体の期間に均等に分散させておこなう。次に、アジャイルチームは、アジャイルでないチームが無視しがちな重大な要素に正面から取り組む。それは、不確実性だ。計画づくりは重要か?もちろん。知識を獲得したり不確実性が軽減したら計画を見直すことは重要か?もちろん。私が見てきた多くの組織では、あまりに早期に無茶なコミットメントをしてそれを結果的に守れないことが許される一方で、不確実性を考慮した現実的な計画を立てると「ルールに則っていない」「チームに馴染まない」とレッテルを貼られてしまう。こうした組織では、ソフトウェアを提供できないことは許容されるが、コミットしないこと(無茶な目標であっても)は論外なのだ。マイクが説明しているアジャイルなアプローチでは、価値を提供することに注力し、壮大だが実現不可能な計画やコミットメントのことは考えない。アジャイル開発者たちの言いたいことは、シンプルにすればこういうことだ。「私たちは、いまここでわかっていることを元に計画を立てます。あなたにとっていちばん大事な目標を達成できるように、私たちは計画を変更します。プロジェクトが進んで新たな知識を得たら、それにプロジェクトと計画を適応させます。私たちからあなたへのお願いは、ビジネスの変化へ柔軟に適応することと、当初の計画を死守することとは矛盾した要求だと、きちんと理解しておいてほしいということです」。「アジャイルな見積りと計画づくり」では、いま述べたことのひとつひとつが取り上げられている。 　不確実性にうまく対処することの難しさに立ち返って、アジャイル開発プロセスがいかにし て目標の不確実性(本当に作りたいものは何なのか)と方法の不確実性(どうやって作ればいいのか)の両方を軽減させるのかを、マイクは見事に整理してみせた。多くの従来型の計画立案手法は重要なことを見落としている―不確実性を踏まえていないものは計画ではないのだ。計画とは、いまこの時点で私たちが知っていることを元に立てられている。不確実性とは、目標と方法のそれぞれについて私たちがまだわかっていないことを別の言い方であらわしたものだ。ほとんどの不確実性(知識の欠落)は、具体的に何かしてみる―実践したり、開発したり、シミュレーションしたり―ことでフィードバックと知識を得なくては解消できない。多くのプロジェクトマネジメント手法は「計画-計画-計画実行」のように見える。アジャイル手法は「計画実行-適応」「計画実行-適応」の繰り返しだ。プロジェクトの不確実性が多ければ多いほど、成功するためにはアジャイル手法が必要となる。 １章　計画の目的 ■フィーチャ：ユーザーにとってのソフトウェアの価値を表現したものであり、ユーザーに直接価値を提供するもの。性能目標やセキュリティといったいわゆる非機能要件も含まれる。プリンターに赤インクを装填できることは機能であって、フィーチャではない。この場合は「フルカラーで印刷できること」がフィーチャである。オンラインショッピングのサイトに商品選択画面、注文確認画面、支払画面、注文完了画面があった場合、各画面はそれぞれ機能であるがフィーチャではない。ショッピングサイトのフィーチャは「欲しい商品を注文できること」である。ソフトウェアを使う側の視点から記述している、という点が重要である。 ■よい計画づくり ・リスクを軽減する ・不確実性を減らす ・意思決定を支援する ・信頼を確立する ・情報を伝達する ■まとめ 　見積りも計画づくりも極めて重要なのだが、難しく、そして誤りやすい。見積りや計画づくりが難しいからといって避けて通ることは許されない。プロジェクトの初期段階では不正確な見積りしかできないが、プロジェクトが進むにつれてより正確に見積もれるようになる。こうして見積りが徐々に調整されていく様子を示しているのが、不確実性コーンである。 　計画づくりの目的は、プロダクトの開発においてもっとも重要な質問、すなわち「なにをつくるべきか?」という問いに答えることだ。この質問への回答には、フィーチャ、リソース、スケジュールが盛り込まれる。この回答に説得力を持たせるのが計画づくりである。そのような計画づくりはリスクと不確実性を低減させ、信頼のおける意思決定を導き、信頼関係を確立し、情報を伝達する。 　よい計画とは、プロダクトとプロジェクトについての意思決定をおこなう根拠として信頼できるものである。アジャイルな計画づくりで大事なのはでき上がった計画よりも、計画を立てるという活動そのものだ。アジャイルな計画づくりは変化を促進する。アジャイルな計画づくりでは、立てた計画を容易に変更できる。アジャイルな計画づくりはプロジェクトのはじめから終わりまで何度も繰り返される。 ２章　なぜ計画づくりに失敗するのか ・プロジェクトの３分の２近くは、コスト見積りを大幅に超過する ・プロジェクトのフィーチャの64％は、めったに、あるいはまったく利用されない ・平均的なプロジェクトは予定スケジュールの２倍以上かかる ■作業を基準にしたスケジュールが遅れる理由 ・作業は早く終わらない ・スケジュールの遅れは先へと伝わる ・作業は独立していない 「仕事の量は、完成のために与えられた時間をすべて満たすまで膨張する」 ■まとめ 　2章では、従来型の計画づくりに内在するいくつもの問題を見てきた。数多くのプロジェクトが失敗してしまうのも、まったく不思議ではない。作業を基準にした計画はフィーチャを軽視することにつながるが、フィーチャこそが顧客にとっての価値なのだ。作業を基準にした計画が問題を引き起こしてしまい、スケジュールを守れなくなることも多い。良かれと思って、プロジェクトのメンバーはマルチタスク化によって状況を打開しようとするが、マルチタスク化に潜むコストのせいで、結果的にプロジェクトはさらに遅延することになる。そしてプロジェクトがスケジュールを超過しそうになると、提供予定だったフィーチャが削除される。ところが、フィーチャを開発する順番は開発側の都合だけで決めているので、ユーザーにとって価値の高いフィーチャが削除されてしまうこともある。 　ユーザーが最終的に何を求めるのかには不確実性があり、はっきりとはわからない。この事実を無視すると、プロジェクトとしては期日を守れたとしても、ユーザーにとって本当に重要なフィーチャを取りこぼしてしまいかねない。というのも、計画を立てた後で明らかになった重要なフィーチャを反映させられないからだ。また、プロダクトを開発する方法にも不確実性があることを無視すると、プロジェクト計画から必要な作業が漏れてしまう。その結果、プロジェ クトが遅れたり、土壇場になってフィーチャを削除することになったり、許容できない品質の低下が起きたりする。 　多くの組織が見積りとコミットメントを混同している。チームは見積りを出したら、それをコ ミットメントとするよう強いられてしまうのだ。 ３章　アジャイル手法 ■まとめ 　アジャイルチームはチームとして一丸となって仕事をするが、チームの一人一人には役割がある。プロダクトオーナーとは、プロダクトのビジョンを提供し、チームが開発するフィーチャの優先順位づけに責任を持つ役割である。顧客とは、プロジェクトへ資金を提供したり、完成したソフトウェアを購入する役割のことである。アジャイルプロジェクトには他にも、ユーザー、開発者、マネージャといった役割がある。 　アジャイルチームは、短くタイムボックス化されたイテレーションで作業する。各イテレーションの終わりには、稼働するプロダクトを提供する。イテレーションで開発するフィーチャはビジネスの観点から選択する。これにより、もっとも重要なフィーチャから順番に開発する。ユーザーストーリーはユーザーの要求を記述する手法で、アジャイルチームでよく使われている。アジャイルチームは、計画が立てたそばから実態と乖離し始めるものだと承知している。これに適応するために、アジャイルチームでは計画を頻繁に見直す。プロジェクトというものは、迅速かつ一定して、新たな機能と知識とを生み出し続ける活動だと考えるべきである。単に定められた手順を実行するだけではないのだ。プロジェクトから生み出される知識には2種類ある。それはプロダクトナレッジとプロジェクトナレッジである。計画を洗練し、組織にとっての価値を最大にするためには、どちらの知識も重要である。アジャイルチームは3つのレベルで計画づくりをする。それは、リリースプランニング、イテレーションプランニング、「今日」のプランニングの3つだ。リリース計画はリリース全体についての計画であり、3ヶ月から6ヶ月という期間がよく使われる。イテレーション計画は1イテレーション分の計画で、2週間から4週間である。「今日」のプランとは、日々のスタンドアップミーティングでメンバーがその日になにをするか決めた1日単位の計画のことである。 　プロダクトオーナーの満足条件を理解することなしに、リリースプランニングとイテレーションプランニングはできない。リリースプランニングでは、リリースでどうやってすべての満足条件を満たすかをチーム全員で決定する。ここでの満足条件には、スコープ、スケジュール、リソースも含まれる。すべての満足条件を満たすために、プロダクトオーナーは一部の満足条件を緩めなければならないこともある。同様のプロセスをイテレーションプランニングでも繰り返す。イテレーションプランニングでの満足条件は、実現すべきフィーチャと、フィーチャが期待通りに実装されたことを確認する概要レベルのテストとして表現される。 ４章　ストーリーポイントによる規模の見積り ■まとめ 　ストーリーポイントは、ユーザーストーリーの相対的な大きさを測る単位である。見積りが10ポイントのユーザーストーリーは、5ポイントのユーザーストーリーの2倍くらい大きいか、複雑か、リスクがあることを示す。同様に、10ポイントのストーリーは20ポイントのストーリーの半分の大きさか、複雑さか、リスクだということだ。ここで重要なのは、ストーリーに割り当てたポイントを比べたときの比率なのだ。 　ベロシティはチームが1回のイテレーションでどれだけ進めるか、すなわち速度を示す。イテレーションを終えるたびに、チームがそのイテレーションでこなしたストーリーのストーリーポイントを合計して、ベロシティを算出する。 　ストーリーポイントは、作業の規模だけを見積もったものである。プロジェクトの期間は見積もるのではなく、ストーリーポイントの合計をチームのベロシティで割ることで導出される。 ５章　理想日による見積り ■まとめ 　理想時間と現実時間は異なる。アメフトの理想時間は60分(15分のクォーターが4回)である。 　しかし、理想時間で60分の試合が実際に終了するまでには現実時間で3時間以上かかる。理想時間と現実時間とが異なるのは、試合中には当然のように割り込みが発生するからだ。ユーザーストーリーの開発にかかる時間は、現実日で見積もるよりも理想日で見積もるほうが簡単である。現実日による見積りでは、ストーリーの完了までに起こりうる、あらゆる割り込みを考慮しなくてはならない。理想日による見積りなら、ストーリーに必要な時間だけを検討すればよい。つまり、理想日は規模の見積りなのだ。ただし、ストーリーポイントほどには厳格に規模だけを考慮したものではない。 　理想日による見積りでは、1つのユーザーストーリーの見積りは1つの値にするのが望ましい。あるユーザーストーリーの見積りを、プログラマの4理想日、テスターの2理想日、プロダクトオーナーの3理想日と表現することは避けるべきだ。それよりも、合計した数字を使って「このストーリーには9理想日かかる」と表現したほうがよい。 ６章　見積りの技法 ■まとめ 　時間と労力を費やして見積りを出したからといって、必ずしも見積りが正確になるとは限ら ない。見積りに費やすべき労力は、見積りの目的に応じて決めなくてはならない。見積りは実 際の作業担当者がおこなうことが最適だとよく知られている。しかし、アジャイルチームでは 誰が実際に作業を担当するのかが事前にはわからない。よって、見積りはチームの協調的な作 業とするべきだ。 見積りには事前に定義されたスケールを使っておこなうべきだ。近い将来に必要とされる フィーチャは信頼性の高い見積りが必要になるので、非線形のスケールを使って細かい単位 で見積もるべきだ。このときのスケールは、1から始まって10を越えない範囲の非線形の値 にするのがよい。たとえば「1、2、3、5、8」 や 「1、2、4、8」といった数列を採用する。相対 的に大きなフィーチャがあっても、今後の数イテレーションの間には実装しない見込みであ れば、見積りの値は大きいままにしておいてよい。この場合は、たとえば「13、20、40、1001 といったサイズを見積り単位とする。「ゼロ (0)」を含めるチームもいる。 　見積りを出すための技法には、専門家の意見、対比、分割といった技法がある。これらの技法 を組み合わせた、楽しくて効果的な見積り手法がプランニングポーカーだ。プランニングボー カーでは、参加する見積り担当者に、見積りに使用できるポイントが記入された一揃いのカー ドを配る。フィーチャについて話し合った後、見積り担当者は手元のカードから自分の見積 りをあらわすポイントのカードを選ぶ。見積り担当者のカードは一斉にオープンする。参加者 全員が合意できる見積りポイントに達するまで、見積り担当者間での話し合いと、カードの選 択を繰り返す。 ７章　再見積り ■まとめ 　ストーリーポイントや理想日がフィーチャの規模の見積りだと理解していれば、再見積りのタイミングもわかりやすい。再見積りすべき時とは、ストーリーの相対サイズについての考え方が変わったときだ。進捗が想定どおりではないという理由だけで再見積りしてはならない。ペロシティを補正装置として使うことで、見積りの不正確さは解決されていく。 　イテレーションの終了時点で途中までしか完了できなかったストーリーは、ベロシティの算出に加えないことを私は勧める。私の好みは、ストーリーの全ポイントをベロシティに加える(ストーリーの実装とテストが完了して、プロダクトオーナーが受け入れた場合)か、さもなければ達成ポイントはゼロとみなし、ベロシティに加えないというものだ。とはいえ、部分的に完了させたストーリーのポイントを加えたい場合もある。よくある対処法は、ストーリーのうちでイテレーション中に完了させた部分をポイントとして見積もってペロシティに加算し、残った部分は別のストーリーとして書き直すというものだ。このとき、完了分のストーリーポイントと残作業分のストーリーポイント合計は、元々のストーリーのポイントと一致しなくてよい。 ８章　ストーリーポイントと理想日 ■まとめ 　見積りをするにあたって、チームはストーリーポイントと理想日のどちらを採用してもよい。それぞれに利点がある。ストーリーポイントにはチームの職能横断的な働きを促進する利点がある。また、ストーリーポイントは純粋な規模の見積りなので、チームが対象とする技術や業務分野に詳しくなっても再見積りの必要がない。多くの場合、理想日よりもストーリーポイントのほうが早く見積もれる。そして、ストーリーポイントは理想日と違って、チームメンバー間で比較できる。理想目による見積りでは、あるメンバーが4理想日と見積もったストーリーを、他のメンバーは1理想日と見積もることもありうる。この2人の見積りはそれぞれに正しいのだが、唯一の見積り値として合意する基準がない。理想日の利点は、チームの部外者に説明しやすいということと、最初に導入するのが簡単ということである。 　私はストーリーポイントのほうが好みだ。ストーリーポイントで見積もる利点には、採用の根拠になるだけの説得力がある。チームが純粋な規模の見積りに苦労しているなら、私なら、まず理想日による見積りで始めて、そのうちストーリーポイントに切り替えていく。このときの私のやり方は、見積りの際に「このストーリーには何理想日かかるか?」ではなく「このストーリーは、さっき見積もったストーリーに比べてどのくらいの大きさか?」といった質問をすることだ。変化は徐々に起こるので、多くのチームは気づかない。チームが気づく頃には、理想日ではなくストーリーポイントで考えるようになっているのだ。 ９章　テーマの優先順位づけ ■まとめ 　すべてのことをやれるだけの時間があることは稀なので、優先順位づけをして、どこから手をつけるのかを決めねばならない。優先順位づけにあたっては、重要なことが4つある。 1.金銭価値 2.必要となるコスト(おそらくはサポート等も含む) 3.得られる知識の量とその意義 4.低減できるリスク 　4つの要素を検討する際には、まず価値とコストの面から暫定的な優先順位づけをおこなう。それから他の要素を加味して、それぞれのテーマの優先順位を調整する。 10章　金銭価値による優先順位づけ ■まとめ 　テーマを財務的に分析することは優先順位づけに役立つ。ほとんどの組織において最終的な評価とはどれだけの金額を得たり節約したりできるかで決まるためだ。利益と業務改善の効果を予想するのは、2年間先まであれば大抵は十分である。もし必要であれば、もっと先まで予想してもかまわない。テーマから得られる収益をモデル化する場合には、4つに分類するとよい。新しい顧客から得られる利益、既存の顧客が追加で購入したり新たにサービスを利用することで得られる利益、既存の顧客が競合プロダクトに乗り換えなかったことで維持できる利益、業務の効率化による利益だ。今日稼いだり使ったりしたお金には、将来に稼いだり使ったりするよりも高い価値がある。現在の金額と未来の金額を比較するためには、現在の金額を割り引く。現在価値とは、銀行に代表される比較的安全な投資によって、将来のある時点での金額を得るために現在必要となる投資額のことだ。 　キャッシュフローを評価するのに役立つ指標が4つある。正味現在価値、内部収益率(または投資収益率),回収期間、割引回収期間だ。それぞれのテーマについてこれらの値を算出すれば、テーマ間の比較ができるので、プロダクトオーナーとチームとが協力して賢明な意思決定ができる。 11章　「望ましさ」による優先順位づけ ■まとめ 　ここで一歩退いて、なんのために優先順位をつけているのかを思い出そう。9章ではフィーチャ に優先順位づけする際に重要な4つの要素を検討した。 1.金銭価値 2. 必要となるコスト(おそらくサポート等も含む) 3. 得られる知識の量とその意義 4. 低減できるリスク 　10章では、フィーチャの優先順位づけにあたっては学習とリスク軽減とを考慮して全体的に評価することの重要性を説明した。 11章では、フィーチャの望ましさに優先順位を付けるための手法を2つ紹介した。狩野モデルと、相対的重み付け手法である。 　狩野の分析では、フィーチャは3つのカテゴリに分類できる。当たり前のフィーチャ、線形の フィーチャ、魅力的なフィーチャである。見込みユーザーに対してアンケートをとることで、 フィーチャは分類できる。アンケートでは各フィーチャについて2つの質問を用意する。それは 「このフィーチャがあったらどう思うか」と「このフィーチャがなかったらどう思うか」である。 相対的重み付けでは、あるフィーチャについての利点、フィーチャがないことの悪影響、開 発するためのコストの3つをもとに、フィーチャの優先度をあらわす数値を算出する。 12章　ユーザーストーリーの分割 ■まとめ 　ストーリーが1回のイテレーションに収まらないのであれば、分割すればよい。そもそも1回のイテレーションでは完了できない場合だけでなく、計画しているイテレーションには組み入れる余地がない場合にも、分割を検討する。また、1つの大きなストーリーを見積もるよりも、分割して見積もったほうが正確な見積りになる。より正確な見積りが必要な場合にもストーリーの分割は有効である。ストーリーの分割にはさまざまな手法がある。扱うデータに沿って分割することもできるし、ストーリーを実現するための操作に沿って分割することもできる。いわゆるCRUD(作成、読み出し、更新、削除)に沿った分割するというのはよくおこなわれているし、横断的な機能を個別のストーリーとして括り出すこともできる。横断的な機能とは、セキュリティ、ロギング、エラーハンドリングなどだ。また、最初はパフォーマンス目標を考慮せず、イテレーション内ではストーリーの機能要求を実現させることでストーリーを小さくすることもできる。パフォーマンス目標はそれ自体を個別のストーリーとして、後のイテレーションで実現するのだ。また、ストーリーには複数の要求が含まれていることも多い。これらの優先度が異なる場合には、それぞれを別のストーリーへと分割できる。 　それから、ストーリーをフィーチャの実装に必要な開発タスクへと分解してはならない。機能を必要なタスクへと分解するのは誰にとっても馴染みのあるやり方なので、ついストーリーもタスクに分解してしまいそうになる。大きなストーリーに、そのストーリーをリリースするのには直接関係ないが関連する変更を追加する誘惑を断つこと。大きなストーリーをさらに大きくしてしまっては意味がない。 　最後に、複数のユーザーストーリーを1つにまとめたほうが適切な場合もあることに注意。これは、バグ修正のようにひとつひとつはストーリーとしては小さすぎる場合に有効である。 13章　リリース計画づくりの基本 ■まとめ 　リリース計画は抽象度の高い計画であり、1回のイテレーションよりも長い期間を対象とする。 ほとんどのチームで、リリースは3ヶ月から6ヶ月の周期で繰り返される。ソフトウェアの種類 によっては、リリース周期がもっと長くなることもあれば、短くなることもある。状況が極め て単純であれば、リリースプランニングも簡単だ。想定されるベロシティを予定しているイテ レーションの数と掛けて、その結果を越えない範囲でユーザーストーリーを選択すればよい。 　リリースプランニングの段階では、個々のイテレーションで何をするかまで詳細に決める必要 はない。実際、そこまでの詳細が必要になることはめったにない。ほとんどのプロジェクトで は、最初の数イテレーションにストーリーを割り振っておけば十分である。残ったストーリー のイテレーションへの割り振りは、イテレーション計画を立てる際におこなえばよい。 リリースプランニングは繰り返し実施される、イテレーティブなプロセスである。まずはプロダ クトオーナーの満足条件を求める。この条件には通常、目標とするスケジュール、スコープ、リソースが含まれている。立てた計画がプロダクトオーナーの満足条件を満たせなかった場合は、計画が条件を満たせるようになるまで、繰り返しながら条件の基準を調整する。たとえばフィーチャを削らないのであればリリースを少し遅らせるとか、チームの人数を増やしてみる、といったようにだ。 　立てたリリース計画を壁に飾ったままにしてはならない。各イテレーションの開始時点で計画 を見直して、必要に応じて更新すること。 14章　イテレーション計画づくり ■まとめ 　リリース計画とは異なり、イテレーション計画は1回のイテレーションでの具体的な作業を扱う。リリース計画が3ヶ月から6ヶ月の期間を対象とするのに対し、イテレーション計画は1回のイテレーションだけを対象とする。リリース計画で扱う比較的大きなユーザーストーリーを、イテレーション計画ではタスクに分解する。ストーリーを分解したタスクは完了までにかかる理想時間を単位として見積もる。 　イテレーションプランニングの進め方は大きく分けて2つある。ベロシティ駆動とコミットメント駆動だ。どちらのやり方も手順の多くは共通しているので、できあがったイテレーション計画が似たようなものになることもよくある。 15章　イテレーションの長さを決める ■まとめ 　ほとんどのアジャイルチームでは2週間から4週間のイテレーションを採用している。いつでもどこでも、どんなチームにも適用できるイテレーションの長さというものは存在しない。イテレーションの長さは、それぞれのチームが自分たちの状況を踏まえて、自分たちに最適な長さを選ばねばならない。そのために考慮すべき要素は以下の通りである。 ・リリースまでの期間 ・不確定要素の高さ ・フィードバックの得やすさ ・優先順位が安定している期間 ・外部からのフィードバックの必要性 ・イテレーションのオーバーヘッド ・切迫感を感じ始めるまでの時間 16章　ベロシティの見積り ■まとめ 　ベロシティを見積もるには3つ方法がある。1つ目は、過去の実績値があれば、それを平均して使うというもの。ただし、この方法を使うにあたっては、チームやプロジェクトの性質、採用している技術などに大きな変化がないことを確認しなければならない。2つ目は、実際にイテレーションを実施するというものだ。これが最善の選択肢である。3つ目は、ベロシティを予想するというものだ。予想するためには、代表的なストーリーをいくつか選んでタスクに分解し、イテレーションの作業可能時間内に収まるかを調べる。この方法はイテレーションプランニングによく似ている。いずれの方法を採用するにせよ、ベロシティの見積りには幅を持たせる。見積り幅には見積りの不確実性を反映させること。見積りに持たせる幅をどれぐらいにするかを決めるには、不確実性コーンが役に立つ。 17章　不確実性に備えるバッファの計画 ■まとめ 　プロジェクトというものは非常にたくさんの不確実性を抱えている。しかし、この不確実性をきちんと反映したスケジュールが作成されることは稀である。不確実性が大きすぎる場合や、問題が起きた場合の影響が深刻な場合には、プロジェクト期間を見積もるのに工夫が必要になる。実際の開始よりもかなり前の時点でプロジェクト計画を立てねばならない場合や、スコープがまま固定で厳格な納期が設定されている場合、プロジェクトをアウトソースする場合、要求がごく表面的にしかわかっていない場合、納期を守れなかったときの(財務上、あるいはその他の影響が甚大である場合などがそうだ。 　バッファの持たせ方でよく使われる方法は、フィーチャバッファとスケジュールバッファの2つである。フィーチャバッファは、プロダクトに対する要求が優先順位づけされていて、そのすべてが必ず提供されるわけではないと合意できている場合に用意するバッファである。たとえば、アジャイルプロセスの1つであるDSDMでは、提供されるフィーチャの30%はオプションと見なすことを提案している。この30%がプロジェクトのフィーチャパッファである。時間が足りなくなったときには、フィーチャパッファにあるフィーチャを削ることでスケジュールを守るのだ。 　いっぽうスケジュールバッファは、スケジュールに適用するバッファである。スケジュールパッファはユーザーストーリーそれぞれの50%見積りと90%見積りから導き出される。各ユーザーストーリーについて50%見積りと90%見積りの差の平方を求め、その値の合計の平方根を算出することで、適切なスケジュールバッファを見積もれる。 　プロジェクトを機能面での不確実性から守るにはフィーチャバッファを用意し、スケジュール面での不確実性から守るにはスケジュールバッファを用意することだ。フィーチャバッファとスケジュールバッファを組み合わせて使うこともできる。むしろ、バッファは組み合わせるほうが望ましい。そのほうが、それぞれのバッファを小さくできるからだ。 18章　複数チーム編成プロジェクトの計画づくり ■まとめ 　アジャイルプロジェクトは、大規模なプロジェクトに対しては、1つのチームを大きくするのではなく、複数の少人数チームを編成することが多い。1つのプロジェクトに複数のチームが関わっていると、互いの作業を連携させる必要が出てくる。この章では1つのプロジェクトに複数のチームが関わっている場合に役立つ4つのテクニックを紹介した。 　1つ目は、チーム間で共有できる見積り基準の確立だ。そのためにはまず、すべてのチームが同じ見積り單位を採用すること。見積り単位はストーリーポイントか理想日のどちらかだ。それから、見積り基準についての認識を合わせるために、いくつかのストーリーを見積もって、その結果に合意できるようにしておくこと。 　2つ目は、複数のチームが同じプロジェクトで作業する場合には、ユーザーストーリーは早い段用で詳細化しておくことだ。これについては、ストーリーに対するプロダクトオーナーの満足条件を明確にするのが最も効果的だ。プロダクトオーナーの満足条件を把握できれば、ストーリーがきちんと期待通りに実装できていることを、実際に動かして確認できる。 　3つ目は複数チームによるプロジェクトでは、リリース計画に「移動する先読み範囲」を取り入れると効果的だ。計画における「移動する先読み範囲」とは、今後予定されているイテレーションのいくつか(通常2つか3つ)までの先を見越して計画を立てるということだ。これがあると、近いうちに各チーム間でどういった連携が必要になるかを、情報交換しながら調整できる。 　最後となる4つ目は、チーム間の依存関係が多くて非常に複雑なプロジェクトでは、合流パッファを計画に組み入れると役に立つというものだ。合流バッファは、あるチームの作業の遅れが他のチームの作業開始に影響が及ばないように、プロジェクトに用意する時間的な余裕である。 以上の4つのテクニックは、一般的には紹介した額にプロジェクトに導入するのがよいが、必ずしも順番通りである必要はない。 19章　リリース計画のモニタリング ■まとめ 　ベロシティはチームが1回のイテレーションで完了させた仕事量を測定したものだ。ベロシティの算出は、オール・オア・ナッシングだ。すなわち、イテレーション終了時点でストーリーが完了していれば、見積りポイント分すべてをベロシティに加算する。ストーリーに一部でも完了していないところがあれば、その見積りの数字は一切ベロシティに加算してはならない。 　リリースバーンダウンチャートは、各イテレーションの開始時点で、プロジェクト全体としてストーリーポイント(または理想日)がどれだけ残っているのかを把握するためのものだ。チームの残作業のバーンダウンが終始一貫して安定していることはない。見積りは不正確だったり、途中で変わることがあるし、そもそもリリースのスコープ自体が変化するからだ。イテレーションの途中でバーンダウンチャートがパーンアップすることもある。ある程度は作業を完了させていたとしても、未着手のストーリーのなかに過小見積りのストーリーがあることに気づくかもしれない。また、プロジェクトのスコープが広がった場合もプロジェクトはバーンアップする。リリースバーンダウンチャートを解釈するうえでのポイントは、チームの総合的な進み具合(正味進捗)が表現されているということだ。正味進捗とは、実際に完了させた作業量から、リリースに向けて増加した作業量を引いたものである。 　リリースバーンダウンチャートには、スタンダードな折れ線グラフ販の他にも、(場合によっては)より便利な棒グラフ版が存在する。棒グラフ版では、チームの選抜と、リリースに向けたスコープの変動とを別々に表現できるのが特徴だ。棒グラフ版では、縦棒の下端を伸び縮みさせることで、スコープの増減をあらわす。こうすることで、棒グラフ販のバーンダウンチャートは折れ線グラフ版よりも表現力を増すが、使うにあたっては注意が必要になる。組織によっては、スコープの変動を縦棒の上端(チームの進捗)に反映すべきか、それとも下端(スコープの増減)に反映すべきかで揉めることがあるからだ。 　パーキングロットチャートも、プロジェクト全体に対するチームの状況を概観するのに役立つ。このチャートでは1枚の紙で、実装予定のテーマ単位ごとに進持状況を表現できる。 20章　イテレーション計画のモニタリング ■まとめ 　タスクボードは、チームの作業を整理し、可視化する。タスクボードにはホワイトボードやコルクボードを使うことが多いが、壁の片隅でも構わない。タスクボードの列にはそれぞれラベルをつけておき、作業の進行に応じて、対応するタスクカードないしはタスクかんばんをチームメンバー自身が順番に右側の列へと動かしてく。 　イテレーションバーンダウンチャートはリリースバーンダウンチャートとよく似ているが、現在のイテレーションの作業をトラッキングするのに使う点が異なる。イテレーションバーンダウンチャートは、縦軸に残作業の合計時間を、横軸にイテレーションの何日目かを取る折れ線グラフである。 　タスクの所要時間の見積りと実績との比較はしないほうがよい。大抵の場合、予実を追跡することによるリスクと手間が利点を上回ってしまうからだ。 　個人単位でベロシティを測定したりトラッキングしてはならない。 21章　計画とコミュニケーション ■まとめ 　見積りと計画にまつわるコミュニケーションは、正直で頻繁な、双方向のコミュニケーションでありたい。実は、ガントチャートは計画を伝えるのに役立つツールである。しかし、フィーチャより細かく分解したタスクレベルには使うべきではないし、ガントチャート上でフィーチャを割り当てる期間の長さは実装予定のイテレーション全体の期間にすべきだ。 　バーンダウンチャートは最も重要な進捗報告ツールだが、バーンダウンチャート以外にも、過去のイテレーションのベロシティをまとめたグラフを用意することが多い。今後のチームのべロシティを予測する場合は、ベロシティを1つの値であらわすのではなく、幅を持たせたほうがよい。そのためにはベロシティを3つ用意するとよい。すなわち、直近のイテレーション、過去8イテレーションの平均、過去8イテレーションのワースト3の平均、の3つだ。これらの値は、それぞれに対応する状況をあらわしている。つまり、最近の状況、「長期的」平均、起こりうる最悪の事態の3つである。 　プロジェクトによっては「イテレーション終了報告書」があると便利だ。イテレーション終了報告書があれば、最新情報を報告できる。また、後から過去のイテレーションの記録として参照するために保存しておくこともできる。 22章　なぜアジャイルな計画づくりがうまくいくのか ■アジャイルな見積りと計画づくりのための12のガイドライン 1.チーム全体を巻き込む 2.複数レベルの計画を立てる 3.大きさの見積りと期間の見積りを区別するために別々の見積り単位を使う 4.不確実性はフィーチャか日付のいずれかで表現する 5.頻繁に計画を見直す 6.進捗をトラッキングして情報を共有する 7.学習することの大切さを受け入れる 8.フィーチャは適切な大きさで計画する 9.フィーチャを優先順位づけする 10.現実に即した見積りと計画を立てる 11.ゆとりを残す 12.複数チームの連携には「移動する先読み範囲」を使う 訳者あとがき 　スコープとスケジュールのいずれか(できれば両方)を調整可能にしてはじめて、ほんとうにアジャイルな開発――価値のあるソフトウェアを育て、リリースし続ける開発は実現できるのです。では「見積りと計画づくりをアジャイルに」しさえすれば、プロジェクトはアジャイルになるのでしょうか?残念ながらその答えは「いいえ」です。このことはすでに、空前のアジャイルブームを迎えた北米では(図らずも)実証されているようです。ジェームズ・ショアは「アジャイルの衰退と凋落」と題した記事で、ビジネスの要請だけにもとづいて短いイテレーションと頻繁な計画づくりを導入しても、プロジェクトを疲弊させてしまうだけだと警鐘を鳴らしています。 　重要なのは、技術とビジネスの調和です。開発者には自分たちで見積りを出す権利があります。しかし同時に、見積りの説明責任を果たすために、誠実で透明性のある進捗を報告する義務があります。顧客やプロダクトオーナーには要求を出す権利がありますが、要求がリリースやイテレーションに収まらない場合には優先順位の決断を下す義務もあります。

・ビズ側の人間が読んでおきたい本過ぎた。 ・工数とスケジュールを見積もる、という超基礎の作業が、実状的に顔色伺いで決まってるケースは多いと思う。知識がないから踏み込めない、迎合してモヤる、そんな当時の(？)自分に渡したい本。 --- ・この小話がついてるタイプの本も久々に読んだ。イイハナシダナア

良書だった。 私個人の体験。 まとまった仕事を任されることがある。 その際、なんだかんだ当初の予定期日に間に合わないか、がむしゃらに頑張って間に合わせる、ということが多い。 本書の内容を、考え方から具体的なプラクティスの部分まで実行できれば、これまでのような印象の悪いプロジェクト遅延をなくせるように思う。 ここで重要なのは、アジャイルを習得することは「決まった期限に決まったタスクを完了させる」スキルを得ることではないということだ。 アジャイルでは、価値あるプロダクトを作り、ターゲットに届ける上で何が必要か？どれくらいかかりそうか？を適切な議論をもって設定する。 そうやって算出した規模に対して、必要なイテレーション数（タスク実施をする期間の最小単位）を見積もる。 そして、全体工期には幅を持たせる。 それによって取捨選択をする余地も残す。 最終章の物語調のケーススタディも、それまでの座学の内容を一本の線として繋げるためにとても有効だった。 本書から知った具体プラクティスを１つずつ習得していきたい。

アジャイルに限らず計画する時の考え方の基盤となる本 不確実性やリスクを無視しがちだと痛感。 "コミットメントは確率ではない" という本書の言葉に感銘を受けた ソフトウェア開発における様々な手法が記載されており、明日から実践していきたい

ネットで本書が紹介されていた。 2ヶ月でヤレみたいなスケジュールが降ってきて(できるわけがない)、応急処置に応急処置を重ねてなんとか6ヶ月後ぐらいに対応できて、最初から6ヶ月あればもうすこしマトモな手段が取れたな〜と反省するまもなく、緊急対応が休むまもなく連続する、というような感じはよくあることだろうか。やっている本人は「これこそがアジャイルだ」と思っているけど、メンバーは疲弊するばかり。なんとかリリースは出すけれど実現されるものは年初計画とはどんどん離れていく。考課は推して知るべし。 本書で提唱する計画は、日数で見積もるのではなく、相対的なポイントでユーザーストーリーの大きさを見積もり、それに速度計数を掛けてイテレーションの計画を立てる。イテレーションの期間に遂行できるポイント量を割り当てて実行する、ということでもある。やってみると、これがよく当たる。スケジュールの精度が良く、将来の見通しが良くなり余計な仕事が減る。計画に用いるパラメータの具体的な計算手順や、ケーススタディも充実していて、分厚いがそのぶん実践的な本である。 自己流で工夫したやり方を重ねるよりも、外部で実績がある方法をまずは試して取り入れてみよう、となるかどうかは職場の雰囲気によるだろう。スケジュール管理・プランニングも、電気回路理論などの固有技術と同様に、理論や方法論があり、自己流の経験で苦労するよりも学んで身につけることができる技術ということを、まず理解しよう。だれしも、リンゴが落ちるのを観察して万有引力の法則を自分で苦労して再発見したくないだろう。

# 明日から実務で使える、アジャイル開発の指南書 ## 面白かったところ - ざっくり・ふんわりしたアジャイル開発特有の「見積もり」「計画づくり」「タスクとストーリーの違い」などが明瞭に説明説明されている点 - 「やるべきこと」と「やってはいけないこと」が説明されている点 - すべてを解説した上で、ケーススタディの物語が綴られていること ## 微妙だったところ - 特になし。強いて言えば、アジャイル開発初心者にはハードルが高い点 ## 感想 業務で信頼しているマネージャから推薦された一冊。ずっと積んであってこの機会に導かれた。 自分自身、アジャイル開発に対して蓄えた知識と経験が相まっており、当書を手に取ったタイミングが神架かっていた。 僧帽筋が膨れるほど頷いた一冊。 特に、「未完成で仕掛の作業が溜まっていくと、チーム全体のスループットを低下させる」というトピックだ。 タスクもストーリーもできるだけ分割し、作業開始・仕掛・完了のペースをできるだけ短くする経験は、自分の中にあるセオリーが正しかったと答え合わせができた。 また時が来たら読み返したい一冊。

・大規模チームの計画の立て方 ・イテレーションの長さの決め方 ・マネージャへの申告報告 ・ストーリーの優先順位付けの方法 ・プロジェクトの全体像を把握する などについての解説本。 計画したことは、ほぼ計画通りには進まず、その都度計画を見直し、再見積もりが重ねられるわけだが、それは予算や時間との戦いとなってくる。その鬼気迫る感覚は、「どんどん大きくなるクマとダンスする（トム・デマルコ）」ようなヒリヒリ感だ。本書はその相談役として、マニュアルとして助けてくれる。

見積もり、計画作りで重要。 WFに比べ、スケジュールが見えにくいアジャイルですが、この本理解することで、計画を作ることができます。

”PMBOKの計画づくりを本格的に学ぼうとしていた矢先なので、タイトルが気になり購入 --- T: P: O: --- ＜読書メモ＞”

具体的なやり方をなぜそうするのか含めて説明してくれているのでとても参考になった。 本に書いてあったからこうするのではなく、現場のフォースを見極めた上で適宜学んだ知識を適用していくよう心がけたい。

従来の計画は作業完了を基準にしているが、顧客からすると価値の単位はフィーチャーである （バリューストリームマッピングは意味がある） 作業基準の計画はパーキンソンの法則により、フルで使うようになってしまう。（という暗黙の了解を得る） 計画は確率であってコミットメントではない ユーザーストーリー→プロダクトバックログ→スプリントバックログ リリースプランニング→つぎのリリースのテーマやユーザーストーリーを検討 イテレーションプランニング→スプリント計画 プランニングポーカーのゴールは精緻な見積りを出すことではなく、低コストで価値のある見積りを出すこと（労力、正確性曲線の左上） プランニングポーカーの議論を長引かせすぎると曲線の右に追いやられ、労力に見合った正確性がでなくなる ベロシティは補正装置である 再見積りすべきときは相対サイズが変わったときのみ ベロシティを計測するときのポイントの乗せ方はオールオアナッシングが原則 チームが熟練してストーリーポイントが変わることはない（サイズが変化するのは例えばフレームワークを導入したとか） 目標の不確実性（なにを作るか）はいきなりなくせないことは前提にありながらも、早めに（優先的に）減らしていくべき スプリントレビューは誰でも参加可能 優先順位づけ（スプリント始まる前） スプリントレビュー（1つ前） スプリントプランニング（レビューと同日） スプリント（次のやつ） 開発はヨットで海を航海するようなもの （風向きや波によって進むべき進路が変わる） 個人のベロシティは測るべきでない

年初に購入してあったのにやっといま読み終わり。なんとか年内に読めた:-) 会社でこの本の読書会をやるというので読み始めたんだけど、前評判どおりのいい本でした。特に第一部はグッとくる。 読了したけど、読書会は年明けからが佳境になりそうで、それもふくめてまだまだ楽しめそうな一冊。

定評のある書籍だけど未読だった。 Agile開発の本でよくある「肝心なところがぼかしてあり、Agileであればなんでもバラ色」的な居心地悪さがない。 Agile開発は「アバウト」なのではなく、基準点として開発者の経験値を重んじ、数値を重要視するのが良く分かる。 総量としての見積もり数の制度を上げるのではなく、精度を高めていくという事がよく分かる。 実際には、経営資料や投資効率指数を駆使して、優先度を決定するなど、かなりハードコアな内容だ。 実際、びっしり文字なので、読んでいて、細部に入りすぎると感じすぎていたが、最初のチャプタのケーススタディーで、それまでの細部の情報がなぜ必要だったか分かる。 開発プロセスの本のケーススタディーも、読んでいていまいち居心地悪い感覚があったが、これはケーススタディーが秀悦だ。 システム開発の現場だけでなく、デザイン、設計、いろんな環境の職場に応用できる。 評判が高いだけあって素晴らしい内容だった。

ウォーターフォールは、ほぼ死んだ。そもそも、建築プロセスを見本にしたこのやり方がここまで命を永らえたのは、ソフトウエアに対する人類の知見がいかに未熟かを示す良い例だろう。　そのアンチテーゼとして、アジャイルが存在する。アジャイル・マニフェストから垣間見るその精神は高く評価されるも、ＨｏｗＴｏの決定打と思える本が無いのも事実だったのだが、この本は決定打だと確信できる。この本が２年も前に出版されていたのだから、浅学を恥じるのみである。

図書館 アジャイル ソフトウェア開発 プログラミング 見積り プロジェクトマネジメント コンピュータ マネジメント IT 開発

アジャイルに対して曖昧な理解しかなかったので、イテレーションをこなす見積りと計画づくりについてためになった。 アジャイル系で次読む本はテスト駆動開発入門かアート・オブ・アジャイル デベロップメントかな？

プロジェクトの見積りと計画をアジャイルに進めるにはどのようにしたらよいかが纏められた本。 「不確実な現状」と如何に向き合い、プロジェクトのゴールに向かって走り続けるか。この本にはそのための比較的普遍的なテクニックが書かれています。 アジャイルに物事を進めるには、変化を受け入れ変わり続ける必要があり、それは見積りや計画においても同じことが言えます。 この本にあることを如何にして自分たちのプロジェクトに落とし込めることができるか、が重要だと思います。

170528 中央図書館 プロのシステム屋からすれば、本書などは内容やテーマが１周（いや１０周くらい？）回って古い、と切り捨てるのかもしれない。今更「アジャイル」を冠して技術論を講じる人はいない、というところか。 しかし、プロジェクトのプランニングとマネジメントの重要性は、別にシステム開発だけの専売特許ではない。およそ「仕事」と呼ばれるものの全てに関係する。 たとえば、計画は、その個別内容の重みを考慮して、（構造を把握して、といえるかもしれない）シンセシスしてまとめる。また、不確定要素に応じるバッファを確保する。適時な進捗把握（マイルストーン）を設けて、チームの進度ムラを把握、管理する・・・などなど。 それぞれは、整理すれば当たり前のことに過ぎるが、「仕事」の現場では、時間に追われ、いまだにKKDで、指標や納期やコストを管理表に記入していることも多いだろう。ごちゃごちゃと管理のための精度を上げる作業をしするよりは、「とっととやってしまえ！」という知恵でもある。 そういったことを、継続的に考えるきっかけとなる読書。

ストーリーやベロシティの考え方など継続的に見積りを続けていくための参考になった。精度を上げるには継続して行くことが大事。

リスク軽減 最初にリスクを知っていれば、そのリスクを勘案してスケジュールが立てられる 不確実性を減らす 新しい知識を取り入れながら、計画が洗練される。更に新たなフィーチャーも追加される 意思決定を支援 計画をもとにリリース日の決定やフィーチャーの追加を決定できる 信頼を確立 計画通り進捗している証明 情報伝達 計画の根拠を示す。計画に従って、他部門も営業や取説が作られる 計画は常に更新すべき。計画ではなく、計画づくりが大切。 最初の作業で予定通りに行かなくて、次で挽回するとよく言うけれど、学ぶべきは次の作業も最初同様に予定通りにいかないということ。 従来型の計画づくりの問題点は見積もりがコミットメントになっている。それは日付で表される。そして、それは作業完了の確率が100%に満たない日。 ユーザーのフィードバックによって、フィーチャーの優先度が変わることを受け入れる必要あり。それで、プロジェクトへの投資から最大のリターンが得られるのであれば協力すべき。変化を受け入れる。 理想時間と現実時間。アメフトの試合、理想時間は60分、現実時間は3時間。 収益逓減の法則。見積もりへの労力と正確さは比例しない。見積もりは完璧にやっても、100%になりえない。 顧客満足度の狩野モデル。顧客満足度とフィーチャーの量の関係図。 満足条件を決める。日付もフィーチャーも主導なプロジェクトもありますね。 20章。個人のベロシティを測定するのは危険極まりない。それの結果が公表されるのであれば、個人のベロシティを上げることに終始し、チームに貢献する事を辞めるため。 計画は随時見直し続けられる必要がある。おしりのスケジュールだけ決めて、あとはよろしくじゃ何もマネージメントできてない！ 仕掛かり作業を次のイテレーションに持ち越すと、サイクルタイム（着手からユーザーに提供さるまでの時間）を延ばすことに繋がるため、避けるべき。残してはいけない。

ストーリー仕立ての最終章がわかりやすかった。リリースまでのスケジュールを図式化しまバーンダウンチャートの工夫や、チームメンバーの抱える仕事の見積もり方と調整など役に立つものが多い。

これはよかった。 ストーリポイントの見積り、分割の仕方、優先度の決め方、イテレーションの長さの決め方……参考になることばかり。 それと、いつイテレーションのレビューをすべきか(金夜より木夜みたいです)、なんて小さいけれど大事な話にも触れてて面白かった。あとは実践あるのみ。

アジャイル開発について概要は分かるのだが実際に適用するとなると、ユーザーストーリーの大きさはどれくらいか、ストーリーポイントはどうやって見積るのか、規模見積りをどうやって期間見積りにするのか、全体計画と各イテレーションの計画をどのように策定、更新するのか、などなど、具体的な疑問に突き当たり、いろいろ試行錯誤はするものの、これでよいのか自信がない…この本はそんな実践一歩手前の人向けのよいガイドとなる。 イテレーション計画において、詳細タスクを洗い出し、実作業時間を見積った上、稼働時間で割るなど、筆者が実際にやっているやり方なので安心して採用できる。また、巻末のケーススタディも、アジャイル全体の流れが良く分かって、読む価値が高い。 アジャイルについて、自分で実践したい、という人はぜひ読むべき。

「アジャイルプロジェクトの見積もりと計画づくり」ではなく「アジャイルな見積もりと計画づくり」を論じた本。 本書の序盤で書かれているとおり、両者は大きく異なる。前者は特定のプラクティスにおける手法に言及したものであるが、後者は「そもそも見積もり・計画づくりとは、なんぞや」という問いに答えるものである。 第一章の最初で「Planning is everything, plan is nothing」という、プロイセン参謀総長モルトケの言葉が引用されているが、これはまさに本書で解説される計画づくりの精神、すなわちアジャイルの精神を体現した言葉である。 計画とはすなわち、変化する状況に対応できる備えとしての思念的フレームワークを構成する（これが計画づくり）際に生まれる副産物に過ぎず、重要なのはそのフレームワークであって、計画そのものではない。計画そのものは、状況変化に応じて更新され、コロコロ変わっていくのである。 上記の哲学を第一部で語った後、残りの部分で、こうした思想に沿った計画づくりがどのようなものになるか、具体的な施策を交えて、詳細に解説してくれる。 ただ、いかんせん、長い。結局のところ、他のアジャイル本で散々解説されているストーリー・イテレーション・ベロシティ等々の話に過ぎないので、具体的施策の面で特に新規性のある話題が提供されているわけでもない。 哲学を語った第一部は秀逸だが、残りの部分はかなり冗長。本書の影響を割と受けていると思われる「アジャイル・サムライ―達人開発者への道」がコンパクトでありながら極めて分かり易く楽しく読めるぶっちぎりの名著であるため、そちらを読んだほうが良い。 ただ、第一部が、理念を把握する上でとにかくよかったので、☆４つ。

アジャイル開発の必要性やメリットデメリットが、分かりやすく纏まっている。 実践的な手法なども書かれていて、参考になる。 各章のまとめが良くまとまっているので、必要なときにまとめを逆引きで読んで、理解不足だったらその章と関連する章を読めば良さそう。 現在の自身の状況や自身が携わってるプロジェクトの特性に合わせて、じっくり読む章と流して読む章を分けて読んだほうが頭に入りやすい。 また、第6部で本書籍全体を通してのまとめもあるので、改めて読み直すときにここから読めばいい気がする。

なんで今まで積んでいたんだろう。タイトルとかから「読みにくい」とでも思ってたんだろうか……その予想は裏切られたわけだが。

この本を読み始めたころ、新しいプロジェクトで、そこでスクラムを実践しようということになり、色々とツールを導入したり、スクラムマスターにお越しいただいてた。チームのみんなの頭の中に、なんとなくのアジャイルやスクラムのイメージがあって、ツール導入が先に決まってしまった感じ。なので、なぜこのツールを使っているのか、なぜ見積もっているのか、といった理由はメンバーそれぞれの解釈でとどまっていた。 この本は、なぜ計画づくりをしなければならないか、それも定期的に頻繁に行うべきことなのかが書いてある。そして、プロジェクト全体、リリースからイテレーションまでの粒度での計画づくりをどのように行うのかが書かれている。「このツールはこういう理由で」となんとなく想像していた自分にとっては、その裏付けとなる理由や、自分では気づかなかった効果を知ることができた。この本で得られた理解から、アジャイル開発を支援するツールについて、どうしてそういう風にデザインされているかが見えてきたり、と色々と面白い感覚を得られた *1。 この本には、初めてのチームが、アジャイルな見積もりと計画づくりをどのようにして導入していくかについてはあまり触れられていない。しかしながら、素晴らしいゴールは与えてくれている。どのようにそこに向かっていくかは、それぞれの状況次第なので、ゴールを目指していくしかないのだろう。 初めてアジャイルを実践して、「なんでこうしてるんだっけ？」とか「この値はどういう意味だっけ？」などと疑問に思った時に見返すと良い本だと思いました。

ソフトウェア開発には、「計画」が重要なのではなく、「計画づくり」が重要ということを教えてくれた書籍。ウチのチームでもこれをバイブルとしてアジャイルな開発にチャレンジしています。

小規模開発チームには必読。ガチガチの旧来手法がことごとくうまくいかず、自分なりに考えてやっていたやり方にピタリとはまる。 大きな概念は取り込み、具体的な手法は出来るところから。

スケジュールの見積もりや計画をアジャイルで行って、随時見直しをして価値の高いプロジェクト、精度の高いスケジュールを作っていく手法が書かれています。非常に面白い本でした。これはおすすめです。翻訳のクオリティも素晴らしいです。本の紙質が少し固めで読みにくいのはちょっと気になりました。

この本はわたしの中で一大ヒット！！！本当にすばらしい。偶然手にとったわたしえらい！ 言われてみればそうなのに、なんで今までわかってなかったんだろう！ 見積もりは不正確なのだから、定期的に見積もって少しずつ精度を増していくことや、見積もりに幅を持たせること、どれも合理的かつ現実的。 システム開発のリーダーとかをやってるひとはみんな読んだら良いと思うし、取り入れたいって思ったら、チームのみんなにも読んでもらうべき。これは参加する人みんながこのやり方を理解してないと実現がむずかしい。逆にチームみんなでやることが、最大の成果を発揮するということだね。 具体的な進め方も十分に載ってるので、読んで自分のチームにあてはめたら実践できる。まだやりはじめたばっかりだけど、もっとブラッシュアップしてもっとみんなを巻き込んでやっていけると良い。がんばらねば。

そもそも作る前からシステムで実現したい内容がくまなくわかって、スケジュールもたてられるなんて無理に決まってるよね、しかも手段が目的化してて要らないもの作っちゃってるかもしれないよね、だったら前提が無理なのに無理に頑張って無理やりやるよりも、その前提をとっぱらって、「できる限りがんばってよしとしよう」、その代わり、できたとこから実装されてるから、顧客にとってもイメージしやすくちょうどいいところで止められて無駄にならないからいいじゃない、というのがアジャイルの思想と解釈した。 日本への適用という観点でいうと、「一度頼んだからにはとことんやらせないと損」というお客さん側の意識をどう変えていくかが課題か。

良書。自分で読む間にも同僚、他部署の上長など薦められる事しばしば。その推薦に足る本だと思う。 アジャイル開発の計画、見積もり、実測そしてフィードバックのやり方とその背景にある考え方がとても緻密に説明されている。恐らく、これ一冊だけで計画とその進め方について十分な知識が得られると思う。 ただもちろん題にあるように、スコープにしていないプロジェクトの多くの要素があるので、これだけでアジャイル開発ができるわけでない。アジャイルではチームビルディングからTDDなどのような下流のテクニカルプラクティスまでがこの計画の実行を支える大切な要素になっているので、それらについては別途学ぶ必要があるだろうと思う。

アジャイル界で、必読と言われている一冊だけあって、非常に良い内容でした。現プロジェクトでは、フォーターフォール開発なので、自分はリーダーでもないこともあり、実践できることは限られますが、得られた気づきを現場で有効に活用できればと思います。

表紙がキレイで好き。読まなきゃもぐりコーナーでよく見かけていたけどなかなか厚さに負けて勇気がでなかった本。意外とすんなり読めた。 優先順位付けの辺りは普段考えない内容ばかりで、今の私には退屈だったけど、最後のシナリオがおもしろく全体としてはお気に入りなので、コーヒーこぼしたのは多目にみてほしい…

しばらくチーム開発から離れていたのでとても為になりました。（PivotalTrackerを導入する前にその方法論を学ばねばと慌てて読みました。） 規模の見積りと期間の見積りを明確に分けるのは目から鱗。 ただ、受託開発の時にどういった契約書（請求書）出すのかがイメージ出来なかった。他にも参考になりそうな書籍を当たってみたい。

アジャイルな見積。計画→見直を行いながら、詳細化していく。 ゴールドラット氏のクリティカルチェーン的な内容が含まれています。 開発を行う方法としては、理想的です。 一方で、顧客は「要件」に匹敵する、「予算」を用意して（もしくは、確保して）いるが、発注されるためには、「要件」をクリアにする必要があり、また、「予算」は枠で確保されるのが現実である。 また、会社の内部に対しても、ソフト開発＝会社からカネを持ち出すということであるから、開発を開始するとき（＝お金を借りるとき）、「総額は1000万～2000万の間になると思いますが、ボンヤリとしたこういう機能を実現するのにお金を使いますので貸してください。段々詳細化していきますから」とは行かないであろう。 お金がからむと急にシビアになり、その予算に見合う機能としてもっと具体的に表現せよ・・・、といった羽目になる。 つまり、開発を進めるやり方の理想型と、事業を行うやり方の理想型にはギャップがあるということであり、このあたりのギャップに日々苦しめられています。

・アジャイルでPJを進めるための実ノウハウ ・サンプル通りにPJが推進できれば大変素晴らしい完成物ができあがる ・ステークホルダーから最初から完璧な計画立案を求められる実環境の中で、どうやって活用していくか・・・ 必要なタイミングがくれば、もう一回読み返す。

素晴らしい。わかりやすい。 第７部ケーススタディだけでも読んでおくべき本。 １０章はわかりにくかったが、EVMをやるよりは実現可能性が高そう。 実際にここをやることはないだろうけど。

ストーリーなどの見積もりについての考えを学習することができる。 見積もりについての経験と知識がない新人エンジニアは読んでいおいたほうがいい。もちろんベテランエンジニアの方も エンジニアやプロマネ以外の人も読んでおいたほうがいいと思う。

　良書。 　アジャイルに見積もりを行っていく…という言葉通り最初はザックリで情報が出そろえば精度を上げていく考え方は非常によく分かる。 　Scrumを使ったケーススタディ、狩野法、考え方や他にもTipsが満載なので、見積もりをする人(しないプログラマもできれば)は絶対読むべきだと思う。

この本を購入に至った目的・背景： アジャイル開発についての知識を得たいと思っていたところ、訳者の角谷さんのプレゼンで衝撃を受けたため たくさんの人がオススメされていたため 初読の感想： まずは導入しやすそうなプラクティスから読み進めていきました。 ゴールを定める、機能ではなくフィーチャ・ストーリーに重きをおくアプローチ、短い単位で動くプロダクトをインクリメンタルに開発する、タスクボードによる可視化、チームで立ち向かう、など、とても有意義でこれからの開発に希望が持てる内容でした。 現在、プラクティスを導入している二つ目のプロジェクトを進行中で、こまめに再読しています。 ずっとかたわらに置いておきたい自分にとってはバイブル的な書籍です。

アジャイル・プロジェクトにおけるフィーチャーベースの見積りについて詳説した本。 アジャイル計画時に陥り易い間違いや、具体的な見積り手法などが数多く紹介されていて、実践的。つーか、一回やってみないと判らないよね、こういうのは。