THE SOFTWARE PROJECT MANAGER’S BRIDGE TO AGILITY 読書会 #8 : Time Management （後半）

株式会社エンラプト 関口匡稔, PMP, PMI-ACP, CSPO

会場提供: PMI日本支部様

Chapter6: Time Management Iteration Planning: Developing the Schedule at the Tactical Level

時間管理 ～ PMBOKの定義（V5）

Initiation Planning ExecutingMonitoring

& Controlling

Closing

Time Management

6.1 スケジュール管理計画 6.2 アクティビティ定義 6.3 アクティビティ順序設定 6.4 アクティビティ資源見積り 6.5 アクティビティ所要期間見積り 6.6 スケジュール作成

6.7 スケジュール・コントロール

“Project Time Management includes the process required to manage the timely completion to the project.”

PMBOK guide 5th Edition

Scheduling Methods ( Software Extension )

Structured schedulingいわゆる従来型。マイルストーンを初期フェーズに決める。

Schedule as independent variable (SAIV)スケジュールを固定として、最も重要な機能から実装するスケジュール方法。スケジュールに合わせてスコープを調整する。

Interactive scheduling with a backlog ( Agile )要求に優先順位を付け、イテレーションに割り振り、実装前に詳細化する。rolling wave planning

On-demand scheduling ( TCO , Lean ) 前もってスケジュールを組まない。バックログからタスクを引き出し( pull ) 、消化していく。期間はケイデンス（リードタイム）により分かる。

Portfolio scheduling プロジェクト間・プロジェクト内の順序づけを組織レベルで決められた評価基準に基づき実施する。組織にとって価値の高いものから作っていく。

• Software Extension では、ソフトウェア開発におけるスケジューリング手法として、下記の5つがあげられている。

イテレーション計画

• 1ヶ月のイテレーションなら8h、2週間なら4hくらい

• チーム、プロジェクトマネジャー、顧客（プロダクトオーナー）が参加。他のステークホルダーは、オブザーバーとしてか、フィーチャーに関する有益な情報を提供するなら参加可。

• アウトプットは、イテレーションバックログ（チームのタスクの一覧）

• リリース計画との違いは、見積りの粒度

• リリース計画 - ストーリーポイント（またはハイレベルな見積り）

• イテレーション計画 - 時間

Strategy vs Tactic

Strategy Tactic

ゴールを実現するための計画やアクション 結果を得るための計画や手続き

「戦略は構想だ、と私は言ったけど、あるいは価値判断だというべきかもしれないね。戦略の段階で最善をつくしておけば、戦術レベルでの勝利はえやすくなる」!

- ヤン・ウェンリー(銀河英雄伝説)

Agileでの計画

Release1 Release2 Release3 Release4

Vision Meeting

Product Roadmap

Release PlanIteration Plan

ビジネス 価値

アクティビティ定義

Traditional Agileプロジェクトで計画されている全てのアクティビティが記載されたアクティビティリストを準備する。

イテレーションでチームは選択されたフィーチャーを分解して、タスクリストを作成する。これがイテレーションバックログ、もしくはイテレーション計画となる。

アクティビティの属性（担当者、先行・後続タスク、制約、前提、関節作業、等）を定義し、スケジュールに含める。

担当者や見積といったアクティビティの属性はイテレーション計画ミーティング中に定義し、イテレーション計画に含める。

プロジェクト全体のマイルストーンを定義し、プロジェクトスケジュールに含める。

個々のイテレーションのテーマはリリース計画中に決める。イテレーションが終わった時の動くコードの提供（増分）をマイルストーンと見なすことが多い。

アクティビティ定義での変更要求は、変更管理プロセスに通される。

イテレーション計画中に新たな要求が発見された場合は、顧客はそれをプロダクトバックログに追加する。イテレーションに含めるのは、顧客がタイムボックスを守るために、低い優先度のフィーチャーをプロダクトバックログに戻すことを承認した場合のみである。

アクティビティ定義の流れ

1. プロダクトオーナーが優先度高のフィーチャーリストを用意する

• 受け入れ基準（完了条件）とQAへの回答

• What & Why

2. チームがフィーチャーを実現するための全てのタスクの決定を行う。

• How初めてのチームは「タスクのブレークダウン」作業に慣れていないことが多く、作業の抜け漏れが多い。うまくファシリテー

トする必要がある。 ・タスク完了からその1つ前の

作業は？その前は？ ・最初に何をする？次に何をす

る？

タスクボード

Requirements UI Ready to

Code Coding Ready to Test Testing Ready

for live

Status

Bugs

Milestone ( Software Extension 6.2.3.3 )

• 従来型のソフトウェア開発では、マイルストーンは要件・アーキテクチャレビュー、顧客レビュー、製品のリリースなどを示すものだった。

• On-Demandな開発では、マイルストーンは「期日」に基づいてはいない。期日を設定して確認会を行っても良いが、ゴールは設定できない。

• プロジェクトリスクを減らすためには、プロジェクト間の相互依存を考慮した、統合マイルストーンを設定するのが良い（ハードの調達とソフト開発など）

ソフトウェア開発に On-Demandな開発というのは可能なのだろ

うか？ 自社サービスで、期日はASAPでとにかく継続してサービスを提供するような場合？

アクティビティ順序設定

Traditional Agile

アクティビティの順番を定義し、ネットワークダイアグラムで表現する。

イテレーション計画をファシリテートし、チームがタスクの順番を決定できるようにする。チームと顧客は共同で、技術や外部要員への依存がプロダクトバックログの順番に影響するか議論する。

アクティビティリスト、属性を更新し、変更履歴を記録してプロセスに則る。

チームが発見・解決した依存性を反映して、イテレーションバックログを更新する。

順序設定

• Waterfall: FS, FF, SF, SS

• ネットワーク図の作成に必要（ただ、MS Project等を使っていないと実質意味がない気が・・・）

• タスクの順序はチームが作成する

• 明日最初に何をする？ それが終わったら次は誰と何をする？

• 外部依存性をプロジェクトマネジャーが支援

Sequence Activities ( Software Extension 6.3 )

• ソフトウェアのアクティビティ順序設定は、PMBOKとは若干異なる

• 新規開発の場合はアクティビティ完了までの予測ができない

• アーキテクチャ構築は予測が困難

• 非機能要件は要件横断的なため、これも順序を狂わせる

• 初期に予測できない作業（ dark matter ) が存在する

• プロトタイプ／実験／欠陥修正

アーキテクチャバックボーン（スケルトン）を先行して作成することで、独立して構築するパー

トが明確になる

セキュリティは、検証に時間とコストがかかる（修正したら、再検証しないといけない）

これらは他のタスクに優先することが多いし、独立して追跡さ

れる。

アクティビティ所要時間見積り

Traditional Agile

アクティビティにかかる期間を見積る。

チームメンバーがイテレーション計画ミーティングの中でタスクの見積りを行う。イテレーション中でも、タスクが追加されたときや、タスクが変更されたときにも見積りを実施する。

所要時間の見積り

• イテレーションの期間は固定

• リリース毎のストーリーポイントはそんなにぶれないようにする

• イテレーションの合計時間がチームの能力を超えないようにする

見積りは経験とともに上達する

• 現在までの経過と速度から、到達時間がより正確に予測できる

Nexco西日本http://www.w-nexco.co.jp/safety_drive/faq_mark/

アクティビティ資源見積り

Traditional Agile個々のワークパッケージに必要なリソースを特定する。

チームはイテレーション開始前に編成され、イテレーションに専念できる。他のリソース（の手配）はリリース計画にて計画される。

リソースの必要性や空きを示したカレンダーを作成する。

チームにイテレーション中の非稼働日（休日、トレーニング、休暇、等）を考慮させることを忘れないようにする。

資源見積り

• チームは専任で、プロジェクトの当初から従事する

• 個々のタスクへのリソースのアサインは考えない。

• チームメンバーは “多能工”

• より大きなリソースアサインメントを考える

• 例）4ヶ月後にデータアーキテクトが必要になる

Estimate Activity Resources ( Software Extension 6.4)

• ソフトウェア開発は開発者のスキルが命!!

• プロジェクトのゴールとプロジェクトチームの総スキルを比較

• Gapがあれば、それは別のチームか増員が必要ということ

• しかし・・・

• PMにそもそもメンバー選択の権限がない

• PMがロール／メンバーのJob Descriptionを出してといわれる

• ソフトウェア開発外のリソースも必要（構成管理／テスト環境／複数プラットフォーム）

戦術レベルのスケジュールコントロール

Traditional Agile

承認された変更、ベースラインにそってスケジュールを更新する。

イテレーション中は変更が禁止されているので、チームは妨害されることなくフィーチャーを慣性できる。ただし、顧客は現在のイテレーションの価値がなくなるような変更の場合、イテレーションを中止する判断を下せる。

スケジュール差異(SV)とスケジュール効率指数(SPI)を計算する。

チームに毎日必ずイテレーション中の残作業を更新させる。チームはまたベロシティの計測を行う。

変更要求を追跡し、文書化する。顧客はプロダクトバックログと（または）リリースバックログを更新する。

プロジェクトを軌道に乗せるための修正活動を明確化、分析する。

顧客とチームの間の取るべき適応活動ディスカッションのファシリテートを行う。（追加のイテレーション、チームの追加、フィーチャーの削減、プロジェクトの終了、等）

15分のデイリースタンドアップ

• 報告内容

• 昨日行ったこと

• 今日行うこと

• 障害となっていること

• チーム内での状態の同期を取るイベント

• （デイリースタンドアップ後）タスクの追加・削除や、順番の変更を行い、プロアクティブに動く

単なる作業報告にならないように、適切なファシリテーション

が必要。 「昨日はタスクAをやりました。今日は続きをやります。特に問題ありません」というような朝会には意味がない

イテレーションの振り返り• このイテレーションで実現したフィーチャーは何か

• 実現は想定より多かった？少なかった？

• フィーチャーのテストは全部できた？残があるなら、リリースプランへの影響は？

• チームのベロシティは？ ベロシティは増加しているか、減少しているか？ その要因は？

• リリース中の他のイテレーションへの影響は？

• 追加のイテレーションが必要か？統合、パフォーマンステストに追加のイテレーションが必要か？それとも低優先度のフィーチャーを削りプロダクトバックログに戻すか？

• この結果からチームは計画に対してどんな印象を持っているか？

スケジュールコントロール

• リリース計画やイテレーション計画の変更は、「リアルタイム」に行われる

• イテレーション毎の増分は高い品質なのが前提。プロジェクト／製品の現状が、「見て」分かる

• イテレーションレベルのコントロールはチームに任せる

• なんかコントロール不在な感覚が・・・→ もっと大きな仕事に励む

• 契約／調達／課題・リスク解決 アジャイルになるからプロジェクトマネージャーの仕事がなく

なるわけではない。 適切なファシリテーションが非常に重要になるし、チーム外の事により目を向ける必要がでて

くる。

イテレーションバーンダウンチャート

線が上がっているのはタスクの増加

フラットな線は更新なし （障害か、更新のサボりか）

ベロシティ

グレーが予定 緑が実績

Cumulative Flow Diagramステータス毎のタスクの変化が追跡できる

AgilePM Change List for Time Management

Traditional PM Agile PMプロジェクト計画を立てる前にプロジェクトの要求を洗い出しておく。

顧客とチームの議論をファシリテートし、見えている範囲でのフィーチャーを詳細に定義する。顧客が簡単に維持できるプロダクトバックログを作成することを支援する。

詳細なプロジェクトスケジュールを元に、リソースマネジャーとともにいつ、どんなリソースが必要になるかを検討する。

リソースの増減のない専任チームの一貫性を満喫する！リリースプランで想定した例外的な要求について、引き続きリソースマネジャーとともに作業する。

要求を完了するために必要なタスクの見積りをお願いする。

プロダクト／リリースバックログでハイレベルな見積りを行う。イテレーション計画で、タスクについてより細かい粒度の見積りを行う。

全てのタスクの依存関係を明確にし、スケジュールを調整する。関係性を明らかにし、最善の管理方法を示す。

タスクの依存性の管理はチームを信じて任せる。プロジェクトのより大きな依存性と外部との協調に注力する。

プロジェクトスケジュールを作成する。リリース計画、イテレーション計画をファシリテートする。そこでチームはハイレベルなリリース戦略と、詳細なイテレーション計画を作成する。

プロジェクトスケジュールを更新する。スコープ・クリープ（漏れ）を防ぐための変更管理を実施する。

チームがバーンダウンチャートの更新するのを支援する（イテレーション／リリース進捗）。チームの進捗に応じて、顧客にプロダクトバックログとロードマップの更新を促す。

• 本書で記載されているアジャイルのやり方に変えたときに、チームが遭遇するであろう疑問・問題・障害を3つ考えてください

• ホワイトボードに貼り付けて、利点や疑問とあわせて整理し、ディスカッションします。

グループワーク

5min

次回 Part II Chapter7: Cost Management

発表者（一部でも）募集！！