agilepm読書会 #5
DESCRIPTION
Agile PM読書会 #5の発表資料です。 今回は、Integration Managementをお題に、従来のPM手法とAgilePMの違いについて考えます。TRANSCRIPT
THE SOFTWARE PROJECT MANAGER’S BRIDGE TO AGILITY 読書会 #5 : Integration Management
株式会社エンラプト 関口匡稔, PMP, PMI-ACP, CSPO
会場提供: PMI日本支部様
前回までのおさらい
Traditional PM vs Agile PM• Traditional PM 1.計画重視 2.工数見積 3.進捗・品質レビュー 4.人月単価・外注 5.失敗が許されにくい 6.ステークホルダー管理 7.チームビルディング
• Agile PM 1.柔軟・自由度が高い 2.成果に価値 3. （該当なし） 4.稟議通らなそう 5.変更を受け入れる 6.チームへの貢献 7.自主的、自律的 A.良好な人間関係 B.見える化 E.タイムボックス
従来型のPMとAgilePMの違いに ついてのディスカッション(#0)
青で囲った部分がギャップの大きいところ
12 PrinciplesAgile Manifestoと 12 Principleに
ついての考察 (#1)
PMIとAgile
• 2005年、PM Network (PMIのニュースレター) にAgileの記事が掲載される。以後もAgile関係の記事が継続的に掲載されている。
• “Reconciling Differences” 2005, April より要約抜粋
• アジャイルプロジェクトとプロジェクト管理は一見相反するように見えるが、多くのソフトウェア開発者はその二つが協力する方法を見つけだしてきている!
• 顧客を開発に巻き込むことは、製品の顧客満足度を向上させる!
• 素早く、それでいて明確な開発ペースによって、顧客は高品質で準備がと整った製品で市場を攻めることができる。!
• ストーリーを基礎としたアプローチにより、開発者は顧客を「生きた」（動かせる）拡張の容易な開発に誘導することができる
PMIの歴史とAgileへの取組み (#2)
Vision Product
RoadmapRelease Release
Project Retro-
spectives Project
Adaptive Life Cycles ( Agile )
• フラクタルな構成
Release Planning Iteration Iteration
Release Retro-
spectives Release
Iteration Planning
Daily Work
Daily Work
Iteration Retro-
spectives Iteration
Daily Stand-up
Task Completion
Task Completion
Update Progress
Daily
プランに 始まり
レトロスペクティブに終わる
Agileのライフサイクル (#3,4)
Process groupとAgile プラクティスの対応付け
Initiation Planning ExecutingMonitoring
& Controlling
Closing
Projectビジネスケース フィージビリティ
契約
プロジェクトキックオフ ビジョンミーティング リリースロードマップ計
画
動作するソフトウェアの継続的なデリバリ
成果物、プロセス、進捗の定期的なレビュー
プロジェクトレトロスペクティブ
Release ロードマップ リリース定義
リリース計画ミーティング
動作するソフトウェアの継続的なデリバリ
成果物、プロセス、進捗の定期的なレビュー
リリースレトロスペクティブ
Iteration イテレーション計画ミーティング
イテレーション計画ミーティング
（動作する）機能の完成までの作業
タスクボード バーンダウンチャート デイリースタンドアップ、完成機能の受入れ
イテレーションデモ レビュー
レトロスペクティブ
Daily Work
モーニングコーヒー またはティー
デイリースタンドアップミーティング
タスクの完了までの作業
チームによる障害の発見
タスクの記録と バーンダウンチャート
の更新
PMBOKのプロセスグループ
PartII: The Bridge - PMBOKガイドとAgileプラクティスの対応付け Chapter4: Integration Management
＿人人人人人人人人人人＿ ＞ 突然のグループワーク ＜ ‾Y^Y^Y^Y^Y^Y^Y^Y^Y‾
Global Integration training session by global integration on Flickr : http://www.flickr.com/photos/globalintegration/
そもそも Integration Management : 統合管理とは何か?
integration by certified su on Flickr : http://www.flickr.com/photos/certified_su/229016531/
ORIGIN mid 17th cent.: from Latin integrat- ‘made whole,’ from the verb integrare, from integer ‘whole’ (see integer). Compare with integral and integrity.
integrate |ˈɪn(t)əәˌɡreɪt|
New Oxford American Dictionary
“Project Integration Management includes the processes and activities to identify, define, combine, unify, and coordinate the various processes and project management activities within the Project Management Process Groups”
PMBOK guide 5th Edition
つまり、 「プロジェクトにまとまりをもたせて ばらばらにならないようにすること」
• プロジェクトの中で行う「まとまりをもたせる、ばらばらにならない」活動を書き出して下さい
• 分類してディスカッションしつつ、本日のお題にうつります
グループワーク
5min 5min
→ Agile 進捗管理は、Dailyミーティングと見える化（バーンダウン）へ
→ Agile スケジュールは、リリース計画、イテレーションバックログへ
PartII: The Bridge - PMBOKガイドとAgileプラクティスの対応付け Chapter4: Integration Management
Integration Management
• プロジェクトの全ての活動にIntegration Managementは関係してくる
Initiation Planning ExecutingMonitoring
& Controlling
Closing
Integration Management
Develop Project Charter
Develop Project Management
Plan
Direct and Manage Project
Work
Monitor and Control Project
work !
Perform Integrated
Change Control
Close Project or Phase
Initiation Planning ExecutingMonitoring
& Controlling
Closing
Integration Management
Develop Project Charter
Develop Project Management Plan
Direct and Manage Project Work
Monitor and Control Project work !
Perform Integrated Change Control
Close Project or Phase
Traditional PM Agile PMプロジェクトの目的と根拠について、適切な関係者から情報収集・フィードバックを得る。
ビジョンミーティングの一部として、プロジェクトの目的と根拠について、チームと適切な関係者から情報収集・フィードバックを得る。
プロジェクト承認に必要なビジネスケース（予算申請）および関連ドキュメントの準備を行う。
必要があれば、プロジェクト承認に必要なビジネスケース（予算申請）および関連ドキュメントの準備を行う。
企業で承認されたソフトウェア開発手法を利用する。それに沿って準備を行う。
アジャイル開発手法を利用し、それに沿って準備を行う。
Vision Meeting Agenda see youtube
• 開会の挨拶 （プロジェクト支持者、スポンサー）
• イントロダクション、基本原則、アジェンダのレビュー（プロジェクトマネージャー）
• このミーティングの目的は何か？スコープの承認者は？私に関係することは何か？（プロジェクトマネージャーとプロダクトオーナー）
• プロジェクトに期待されていることは何か？そこに到達するためのアーキテクチャ計画はあるか？ビジョンを共有せよ！（プロダクトオーナーとアーキテクト）
• 誰が協力者か？（プロジェクトマネージャー）
• 質問、提案、懸念点（チーム）
• エレベーターステートメント作成セッション（チーム）
• 製品パッケージデザインセッション（チーム）
• プロジェクトデータシートを埋めるだけの十分な情報を得られたか（チーム）
• ハイレベルプロジェクトスケジュールが想定できたか（チーム）
• ビジョン／プロジェクトに影響を与える課題、リスクは何か（チーム）
• 最終的なエレベーターステートメント、製品パッケージ、プロジェクトデータシートはどうなったか（チーム）
• チーム規約は何か？（チーム）
• 閉会：コミュニケーションプラン、空のパーキングロット、アクションアイテム、ネクストステップ
Elevator Statement
• Jim HighsmithがAgile Project Managementで提案している手法
• 2分間でプロジェクトの意図を説明するための簡潔な文章。
• 誰のために（ターゲットとする顧客）
• どういう特徴の（ニーズまたは機会）
• この製品（名称）は（カテゴリ）で～
• （ベネフィット、購入したくなるような動機付け）であり、
• ～（主要な競合）とは異なり～
• という製品である（競合との差異）
チームを分けて それぞれ作成してもらう。
!作成したElevator Statementを並べて議論し、ビジョン
を明確にしていく
Design the Box
• 同じくJim Highsmithが提案している手法
• 製品のパッケージを考える
• 製品名やロゴ
• うたい文句
• 主要機能
Design Blog Sociale - 23 June 2008 - Vitamin Packaging by Robert Ferrell E on Flickr : http://www.flickr.com/photos/27620885@N02/2603601820/
Initiation Planning ExecutingMonitoring
& Controlling
Closing
Integration Management
Develop Project Charter
Develop Project Management Plan
Direct and Manage Project Work
Monitor and Control Project work !
Perform Integrated Change Control
Close Project or Phase
Traditional PM Agile PMプロジェクト管理プロセスを公式に文書化する（品質管理、コミュニケーション管理、リスク管理、等）。
チームが選択したアジャイル方法論のフレームワーク・ガイドラインで開始する。各イテレーションの終了時にふり返り・改善を実施する。
ステークホルダーとのコミュニケーションの仕方について公式文書化する。
アジャイル原則に従い、プロジェクトの情報は知りたい人すべてに常時公開され、調整はこれを持ち運ぶことで行う。
主要な管理レビューのタイミングを決定する。各イテレーションの終わりにレビューを実施。それ以外でも主要関係者がプロジェクトの情報を参照するのは大歓迎。
変更管理の追跡方法、統制方法を決定し、公式文書化する。
製品の変更はデモや計画ミーティングの際に発見され、バックログに記載される。プロセスの変更はレビューと振り返り時に発見され、非公式な文書として記載される。
構成管理の方法について決定し、公式文書化する。 構成管理はチーム規約の決定の中で決められ、非公式な文書として記載される。
Initiation Planning ExecutingMonitoring
& Controlling
Closing
Integration Management
Develop Project Charter
Develop Project Management Plan
Direct and Manage Project Work
Monitor and Control Project work !
Perform Integrated Change Control
Close Project or Phase
Traditional PM Agile PM実施を監督する。
リーダーシップを発揮して、自発的・協調的な意思決定を促す。
計画に従うことを確実にする。選択したアジャイル方法論に従い、変更への対応能力を確保する。
予定と実績を比較する。イテレーションレビューミーティングをファシリテートする。
修正のためのアクションを実施する。ふりかえりミーティングをファシリテートし、チームが適応アクションを決定する。
プロジェクトのデータを集め、状況を報告する。
効果的な情報発信器をチームが作れるように、空間と道具を用意する。デモとレビューミーティングをファシリテートする。必要に応じて、エクゼクティブサマリーを用意する。
Initiation Planning ExecutingMonitoring
& Controlling
Closing
Integration Management
Develop Project Charter
Develop Project Management Plan
Direct and Manage Project Work
Monitor and Control Project work !
Perform Integrated Change Control
Close Project or Phase
Traditional PM Agile PM
変更管理委員会を組織する。チームが変更管理委員会と見なされる。顧客が製品に関する変更の最終決定者であり、チームがプロセスに関する変更の最終決定者である。
変更要求を特定し、記録する。変更要求は製品デモの際のディスカッションから生まれる。
変更要求の解決方法を決定し、記録する。製品に関する変更は新たなプロダクトバックログとして記録される。プロセスに関する変更は助言やチーム規約、ふりかえりの際のアクションアイテムとして記録される。
変更要求の解決（したかどうか）を検証する。顧客が完了したバックログアイテムの承認責任を持つ。プロジェクトマネージャーはチームに対してプロセス変更をリマインドする。
変更要求がプロジェクト中の他の領域（スコープ、スケジュール、リスク等）にどのような影響を及ぼすかを特定し、記録する。
各イテレーションの最後にプランに立ち返り、必要なら修正を行う。
Initiation Planning ExecutingMonitoring
& Controlling
Closing
Integration Management
Develop Project Charter
Develop Project Management Plan
Direct and Manage Project Work
Monitor and Control Project work !
Perform Integrated Change Control
Close Project or Phase
Traditional PM Agile PM管理上の終結（製品の準備完了、最終受入、スタッフの開放）
管理上の終結（製品の準備完了、最終受入、スタッフの開放）
契約の終結（契約上の実施内容と成果物） 契約の終結（契約上の実施内容と成果物）
製品の最終リリースと引き渡し 製品の最終リリースと引き渡し
学んだこと（Lessons Learned） プロジェクトふりかえり
コメント
• 前回はP.7のようにマトリクスで整理していたのに、今回から1次元で整理している。プロジェクトレベルではなく、イテレーションレベルで比較するべきなのでは。
• 日本のSIでは、InitiationとClosingを営業に任せるケースが多いように思われる。
• Scrum Masterの役割はExecutingエリアなので、その他の領域は（アジャイルプロジェクトでも）Project Managerが必要？ → Part IIIに記載があるようだ。
• Information Radiatorをシステム化してしまうと、逆に見えているものが信じられないというケースが発生した。機械化するのはおすすめできない。
次回 Part II Chapter5: Scope Management