AEP(アジャイルな見積りと計画づくり)読書会21章計画とコミュニケーション

AEP読書会(21章) 計画とコミュニケーション 2016/2/5 Arata Fujimura

“コミュニケーション手段が進歩すればするほ ど、コミュニケーションしなくなる” “The more elaborate our means of communication, the less we communicate.” ‒ジョゼフ・プリーストリー

• 見積りと計画に関しては、何を伝えるかよりもどうやって伝 えるかが重要だ。 • 計画について頻繁に伝えることが重要なのは、アジャイルな 計画とは頻繁に更新されるものだからだ。 • 計画はプロジェクトの期間を通じて変更されるものであり、 変更された結果は伝えねばならない。 • 計画の変更内容を伝えるのに失敗すると、フィードバック ループを活用できない。 • フィードバックループなしには、プロダクトの価値を向上 させることも、プロジェクトが成功する可能性を高める ことも、計画を有効活用することもできない。

• 正直なコミュニケーションなしに、開発チームと顧 客とが互いを信頼することはできない。 • プロダクトオーナーが本当の期日を隠しているこ とに開発者が気づいたら、開発者はもうプロダク トオーナーを信頼しなくなる。 • 開発者がプロダクトオーナーに伝えた見積りが現 実離れしたものだとわかったら、開発者はプロダ クトオーナーからの信頼を失ってしまう。

• 信頼関係なしに、正直なコミュニケーションは望めない • 信頼を失うことにつながる事態をもっと深刻に捉える べきだ。 • 自分のタスクに予想以上の手間がかかりそうだとわかっ たら、そのことをチームで共有するほうが安心だと思 うようになるべきだ。 • 正直なコミュニケーションを阻害するようなチームで は、問題が起きたときの発見が遅れることになる。

• あなたが伝えようとする相手全員に、伝えたい内容を正 しく理解してもらうのは、あなたの仕事だ。単に聞いて もらうだけではなく、理解させるのだ。 • 誰にも誤解の余地がないように伝えなくてはならない。 • アジャイルなチームが大きな目立つグラフを好んで使う 背景にはこうした理由もある。 • 40ページある週次報告書の32ページ目にプロジェク トが遅れていることが「明確に」記述されていても、 誰ひとり気づかないかもしれない。

1.計画の情報共有

• プロジェクトのスケジュールについて 質問されたら、どう答えればよいだろ うか？ • 提供予定の全ストーリーポイントを 合計し、ベロシティの予測値で割っ たうえで「6月14日にお届けします。 7.2イテレーション後です」

• プロジェクトのスケジュールについて 質問されたら、どう答えればよいだろ うか？ • ✖ 提供予定の全ストーリーポイントを 合計し、ベロシティの予測値で割っ たうえで「6月14日にお届けします。 7.2イテレーション後です」

• あたかも現時点での計画が、正確な見積 りを出せるぐらいに精密な情報を提供し ているかのような印象を与えてしまう。 • できる限り目標期日とその見積りの確度 を併せて伝えるか、目標期日に幅を持た せるようにする。 • 両者を組み合わせるのもよい。

• 「予定したフィーチャは90%の確率 で7月31日までに完了できそうです」 • 「現時点で想定しているプロジェクト 規模とチームのパフォーマンスからす ると、プロジェクトの期間は3ヶ月か 4ヶ月かかりそうです」

• 「予定したフィーチャは90%の確率 で7月31日までに完了できそうです」 • 「現時点で想定しているプロジェクト 規模とチームのパフォーマンスからす ると、プロジェクトの期間は3ヶ月か 4ヶ月かかりそうです」 ◎

“計画の伝え方の例” www.XProgramming.com ‒ロン・ジェフリーズ

• http://www.xprogramming.com

• 現時点では、このプロジェクトが使えるポイントは200ポイントです。 • 他のプロジェクトでの実績(当てずっぽうともいいますが)を元に考えると、プ ログラマがn人、あなたがプロジェクトに密接に関わるという前提で、この程 度の規模のプロジェクトであれば、4ヶ月から6ヶ月で終われると思います。 • ですが、ソフトウェアはプロジェクト開始から2週間おきに提供していきます。 • 提供する機能はあなたが設定した満足条件を満たすストーリーを実装したもの です。 • このやり方の良いところは、もしも気に入らなければプロジェクトを止められ ることです。 • さらに良いこともあります。 • もしも予定していたすべての機能が完成する前に満足したら、そこでプロジェ クトを止めてしまってもかまいません。

• ただし、都合の良い話ばかりではありません。 • あなた自身の満足条件をはっきりさせなければなりませんから、私たちと一緒に働 いてもらう必要があります。 • その代わり、このやり方には他にはない利点があります。 • 実際に使えるぐらいにソフトウェアが仕上がったと思ったら、いつでもデプロイす るように指示してください。 • 私たちはそれに応じてデプロイします。 • プロジェクトが進むにつれて、進む速度もわかっていきますから、そうなれば機能 の実装に必要な時間も正確に見積もれるようになります。 • あなたはいつでもプロジェクトがどうなっているかを知ることができます。 • 価値を提供するソフトェアが実際に動作している確たる証拠として、あなたが仕様 として求めたテストケースの実行結果を見ることができます。 • 私が知り得たことはすべて、すぐにあなたにも知らせます。

ガントチャート

• 会社によっては、プロジェクトのスケジュールを伝 えるのに、お馴染みのガントチャートを使うことが 通例になっている。 • ガントチャートは悪名高いが、その原因はプロジェ クトのタスクの予想とスケジューリング、そして調 整するのに使われてきたためだ。 • ガントチャートに抵抗を感じる人は多いが、イテレー ションにフィーチャを割り当てた機能を一覧するう えではとても役立つツールである。

• フィーチャレベルまでしか示しておらず、それより下のタスクレベルは表示してい ない。 • プロジェクトのフィーチャ分割構成であって、作業分割構成(WBS)ではない。 • それぞれのフィーチャの線が、割り当てられているイテレーション全体の期間にわ たって引いてある。 • フィーチャはイテレーションの途中で完成したとしても、イテレーション終了 までは組織に見せることができない。 • リソースの割り当てを一切書いていない。 • すべてのフィーチャを提供することに責任を負っているのはチーム全体。

2.進捗の情報共有

• 改めて書くまでもないが、リリースバーンダウンチャートが進捗 を伝える最も重要なツールである。 • リリースまでに必要なイテレーション数の単純な計算法は、開 発が必要な残ポイント合計をチームのベロシティで割り、端数 を切り上げた整数を求めればよい。 • 100ポイント(残ストーリーポイント) ÷ 10(チームのベロ シティ) = 10イテレーション • 実際には、計測した過去のベロシティも緻密なものではないし、 未来のベロシティは変動する。 • あと何イテレーション必要かを予想する最善の方法は、予想の根 拠に使うベロシティに幅を持たせることだ。

• 予測に使うベロシティを複数にする • 最近の状況 • 直近のイテレーションのベロシティ：19ポイント • 「長期的」平均 • 過去の8イテレーションの平均ベロシティ：17ポイント • 起こりうる最悪の事態 • ワースト3イテレーションの平均ベロシティ：14ポイント

• 特定の日付までにどれぐらいのストーリーポイントをこなせるかを予測する のに、3つのベロシティを利用する • たとえば、5イテレーション後にプロダクトをリリースする場合、チーム がこなせるポイント数の予測 • 少なくとも70ポイント分のストーリーの完成は期待できる • 85ポイントを超えた領域にあるフィーチャについては、きっとできない 説明 ベロシティ イテレーション数 合計ポイント ワースト3平均 14 5 70 過去8イテレーション平均 17 5 85 直近 19 5 95

3.イテレーション終了報告書

• 「イテレーション終了報告書」だなんてなんだかアジャイ ルっぽくないように見える • • しかし、これまでに話をしたマネージャのほとんど全員 から「報告書は用意してもらえるのか」とたずねられた 1回のイテレーション終了報告書を30分以内に準備でき て、参加しているプロジェクトの多くが1イテレーション 2週間 • プロジェクト終了報告書の準備に費やしている時間は毎 週およそ15分

プロジェクト概要 • • 日程 • イテレーション開始日：9月1日 • イテレーション終了日：9月14日 • 作業日数：9日 要員 • 今回のイテレーションでプロジェクト作業に従事 した要員は以下の通り。表では作業日数の予定と 実績を併記している。

プロジェクト概要 名前 予定作業日数 実績作業日数 カリーナ 9 9 ワジム 9 7 サーシャ 8 9 ディミトリ 9 9 35 34 合計 • 作業日数 • イテレーションの途中に休日やメンバーの休暇があると、作業日数が減るので、 イテレーションによって作業日数は変動する。 • ワジムが予定よりも作業日数が2日少ない。 • • 病欠？ サーシャは予定よりも作業日数が1日多い。 • 休暇を1日取るつもりだったのを止めた？

指標 • ナイトリービルド結果 日付 結果 9月1日(月) Build failed 9月2日(火) 812 unit tests passed;1431 Fit Nesse tests passed;104 user interface tests passed 9月3日(水) 826 unit tests passed;1433 Fit Nesse tests passed;104 user interface tests passed 9月4日(木) 1 unit test failed 9月5日(金) 841 unit tests passed;1442 Fit Nesse tests passed;105 user interface tests passed • 行には色をつけよう • ビルドの成功は緑色、ビルドやテストに失敗した場合は赤色 • 結果の列には、ビルドに成功した場合にだけ、実行したテスト結果が書いてある • テストがどれか1つでも失敗したら、結果の列には失敗したテスト件数だけを記 載する • 「100件中99件成功した」という表現は、全体としてはうまくいっていると考 えてしまいがち

指標 • 300 225 150 75 0 イテレーションバーンダウン

指標 • ベロシティ

実施内容と評価 ストーリー 結果 予定ポイント ベロシティ 加算ポイント 完了 8 8 完了 (予定より大きかった) 8 8 完了 3 3 着手 (未完) 1 0 20 19 コーチとして、チームのすべての選手の名前とプロフィールを入力できる コーチとして、練習を設定できる 水泳選手として、ある競泳種目について、自分のタイムをすべて見ること ができる 選手として、自分のプロフィールを変更できる 合計

実施内容と評価 • イテレーションレビュー • 9月15日9時にイテレーションレビューを実施。レビュー で決定したアクションアイテムと担当者は以下の通り。 アクションアイテム 担当者 マークから、彼の知っているコーチの誰もが、練習計画の履歴画面で は現状の表示とは逆に、日時の降順で表示させているとの指摘があっ カリーナ た。何人かのコーチに対して指摘通りの画面表示にして確認してみる ゲーリーから、選手成績を競泳種目ごとにグラフ表示するストーリー を追加してはどうかと提案があった カリーナ

話し合ってみよう 1.プロジェクトにあと150ストーリーポイント分の仕事が残ってい るとする。過去10イテレーションでのベロシティの実績は、10、 12、13、5、14、7、6、12、16、14ポイントだった。プロジェ クトがいつ終わるかたずねられたとしたら、あなたならどう答える だろうか？ •全合計：109ポイント •過去8イテレーションの合計：87ポイント 2.あなたのプロジェクトでは期日をどう表現しているだろうか？特定 の日付(9月18日)だろうか？それとも幅を持たせた表現(9月11日〜 9月25日)だろうか？どちらの形式で表現しているにせよ、なぜその 形式を選んだのだろうか？ 3.あなたのプロジェクトの完了予定を、幅を持たせたイテレーション もしくは日付で表現したとしたら、完了予定はいつになるだろうか？