Downloaded 11 times
Uploaded byTadatoshi Sekiguchi
Agile PM 読書会8
The software project managers bridge to agility 読書会 #8 Project time management 後半
![[Agile Japan 2017 NRIサテライト（再演）]Social change starts with you～三周目のAgileの世界への招待状～](https://cdn.slidesharecdn.com/ss_thumbnails/aj201720180307-180307054631-thumbnail.jpg?width=640&height=640&fit=bounds)
Agile PM 読書会8
- 1. THE SOFTWARE PROJECTMANAGER’S BRIDGE TO AGILITY 読書会 #8 : Time Management （後半） 株式会社エンラプト 関口匡稔, PMP, PMI-ACP, CSPO 会場提供: PMI日本支部様
- 2. Chapter6: Time Management IterationPlanning: Developing the Schedule at the Tactical Level
- 3. 時間管理 ∼ PMBOKの定義（V5） InitiationPlanning Executing Monitoring & 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
- 4. 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つがあげられている。
- 5. イテレーション計画 • 1ヶ月のイテレーションなら8h、2週間なら4hくらい • チーム、プロジェクトマネジャー、顧客（プロダクトオーナー）が参加。他のステー クホルダーは、オブザーバーとしてか、フィーチャーに関する有益な情報を提供する なら参加可。 •アウトプットは、イテレーションバックログ（チームのタスクの一覧） • リリース計画との違いは、見積りの粒度 • リリース計画 - ストーリーポイント（またはハイレベルな見積り） • イテレーション計画 - 時間
- 6. Strategy vs Tactic StrategyTactic ゴールを実現するための計画 やアクション 結果を得るための計画や手続き 「戦略は構想だ、と私は言ったけど、あるいは価値判断だとい うべきかもしれないね。戦略の段階で最善をつくしておけば、 戦術レベルでの勝利はえやすくなる」! - ヤン・ウェンリー(銀河英雄伝説)
- 7. Agileでの計画 Release1 Release2 Release3Release4 Vision Meeting Product Roadmap Release Plan Iteration Plan ビジネス 価値
- 8.
- 9. アクティビティ定義の流れ 1. プロダクトオーナーが優先度高のフィーチャーリストを用意する • 受け入れ基準（完了条件）とQAへの回答 •What & Why 2. チームがフィーチャーを実現するための全てのタスクの決定を行う。 • How 初めてのチームは「タスクのブ レークダウン」作業に慣れてい ないことが多く、作業の抜け漏 れが多い。うまくファシリテー トする必要がある。 ・タスク完了からその1つ前の 作業は？その前は？ ・最初に何をする？次に何をす る？
- 10.
- 11. Milestone ( SoftwareExtension 6.2.3.3 ) • 従来型のソフトウェア開発では、マイルストーンは要件・アーキテクチャレ ビュー、顧客レビュー、製品のリリースなどを示すものだった。 • On-Demandな開発では、マイルストーンは「期日」に基づいてはいない。期 日を設定して確認会を行っても良いが、ゴールは設定できない。 • プロジェクトリスクを減らすためには、プロジェクト間の相互依存を考慮し た、統合マイルストーンを設定するのが良い（ハードの調達とソフト開発など） ソフトウェア開発に On-Demand な開発というのは可能なのだろ うか？ 自社サービスで、期日はASAP でとにかく継続してサービスを 提供するような場合？
- 12.
- 13. 順序設定 • Waterfall: FS,FF, SF, SS • ネットワーク図の作成に必要（ただ、MS Project等を使っていないと実質 意味がない気が・・・） • タスクの順序はチームが作成する • 明日最初に何をする？ それが終わったら次は誰と何をする？ • 外部依存性をプロジェクトマネジャーが支援
- 14. Sequence Activities (Software Extension 6.3 ) • ソフトウェアのアクティビティ順序設定は、PMBOKとは若干異なる • 新規開発の場合はアクティビティ完了までの予測ができない • アーキテクチャ構築は予測が困難 • 非機能要件は要件横断的なため、これも順序を狂わせる • 初期に予測できない作業（ dark matter ) が存在する • プロトタイプ／実験／欠陥修正 アーキテクチャバックボーン（ス ケルトン）を先行して作成する ことで、独立して構築するパー トが明確になる セキュリティは、検証に時間と コストがかかる（修正したら、 再検証しないといけない） これらは他のタスクに優先する ことが多いし、独立して追跡さ れる。
- 15.
- 16. 所要時間の見積り • イテレーションの期間は固定 • リリース毎のストーリーポイントはそんなにぶれないようにする •イテレーションの合計時間がチームの能力を超えないようにする 見積りは経験とともに上達する • 現在までの経過と速度から、到達時間がよ り正確に予測できる Nexco西日本 http://www.w-nexco.co.jp/safety_drive/faq_mark/
- 17.
- 18. 資源見積り • チームは専任で、プロジェクトの当初から従事する • 個々のタスクへのリソースのアサインは考えない。 •チームメンバーは “多能工” • より大きなリソースアサインメントを考える • 例）4ヶ月後にデータアーキテクトが必要になる
- 19. Estimate Activity Resources( Software Extension 6.4) • ソフトウェア開発は開発者のスキルが命!! • プロジェクトのゴールとプロジェクトチームの総スキルを比較 • Gapがあれば、それは別のチームか増員が必要ということ • しかし・・・ • PMにそもそもメンバー選択の権限がない • PMがロール／メンバーのJob Descriptionを出してといわれる • ソフトウェア開発外のリソースも必要（構成管理／テスト環境／複数プラットフォーム）
- 20.
- 21. 15分のデイリースタンドアップ • 報告内容 • 昨日行ったこと •今日行うこと • 障害となっていること • チーム内での状態の同期を取るイベント • （デイリースタンドアップ後）タスクの追加・削除や、順番の変更を行い、プ ロアクティブに動く 単なる作業報告にならないよう に、適切なファシリテーション が必要。 「昨日はタスクAをやりまし た。今日は続きをやります。特 に問題ありません」というよう な朝会には意味がない
- 22. イテレーションの振り返り • このイテレーションで実現したフィーチャーは何か • 実現は想定より多かった？少なかった？ •フィーチャーのテストは全部できた？残があるなら、リリースプランへの影響は？ • チームのベロシティは？ ベロシティは増加しているか、減少しているか？ その要因は？ • リリース中の他のイテレーションへの影響は？ • 追加のイテレーションが必要か？統合、パフォーマンステストに追加のイテレーションが必 要か？それとも低優先度のフィーチャーを削りプロダクトバックログに戻すか？ • この結果からチームは計画に対してどんな印象を持っているか？
- 23. スケジュールコントロール • リリース計画やイテレーション計画の変更は、「リアルタイム」に行われる • イテレーション毎の増分は高い品質なのが前提。プロジェクト／製品の現状 が、「見て」分かる •イテレーションレベルのコントロールはチームに任せる • なんかコントロール不在な感覚が・・・→ もっと大きな仕事に励む • 契約／調達／課題・リスク解決 アジャイルになるからプロジェ クトマネージャーの仕事がなく なるわけではない。 適切なファシリテーションが非 常に重要になるし、チーム外の 事により目を向ける必要がでて くる。
- 24.
- 25.
- 26.
- 27. AgilePM Change Listfor Time Management Traditional PM Agile PM プロジェクト計画を立てる前にプロジェクトの要求を洗い 出しておく。 顧客とチームの議論をファシリテートし、見えている範囲 でのフィーチャーを詳細に定義する。顧客が簡単に維持で きるプロダクトバックログを作成することを支援する。 詳細なプロジェクトスケジュールを元に、リソースマネジ ャーとともにいつ、どんなリソースが必要になるかを検討 する。 リソースの増減のない専任チームの一貫性を満喫する！リ リースプランで想定した例外的な要求について、引き続き リソースマネジャーとともに作業する。 要求を完了するために必要なタスクの見積りをお願いす る。 プロダクト／リリースバックログでハイレベルな見積りを 行う。イテレーション計画で、タスクについてより細かい 粒度の見積りを行う。 全てのタスクの依存関係を明確にし、スケジュールを調整 する。関係性を明らかにし、最善の管理方法を示す。 タスクの依存性の管理はチームを信じて任せる。プロジェ クトのより大きな依存性と外部との協調に注力する。 プロジェクトスケジュールを作成する。 リリース計画、イテレーション計画をファシリテートす る。そこでチームはハイレベルなリリース戦略と、詳細な イテレーション計画を作成する。 プロジェクトスケジュールを更新する。スコープ・クリー プ（漏れ）を防ぐための変更管理を実施する。 チームがバーンダウンチャートの更新するのを支援する （イテレーション／リリース進 ）。チームの進 に応じ て、顧客にプロダクトバックログとロードマップの更新を 促す。
- 28.
- 29. 次回 Part II Chapter7:Cost Management 発表者（一部でも）募集！！