マインドマップギャラリー PMP アジャイルプロジェクト管理
PMP アジャイル プロジェクト管理の知識ポイントの概要と試験シラバスを組み合わせて、PMP 試験のアジャイル部分に関連する重要な知識ポイントを整理しました。すべての学生が情報交換や指導を行うことができます。
2023-02-27 11:45:24 に編集されましたPMP アジャイルプロジェクト管理
背景(VUCA時代の新たな挑戦)
1. ボラティリティ ボラティリティ
2. 不確かに 不確実に
3. 複雑さ 複雑さ
4. 曖昧さ 曖昧さ
基本知識
魂
アジャイルマニフェスト
1. プロセスとツールを介した個人と相互作用
2. 徹底したドキュメントを超えて動作するソフトウェア
3. 契約交渉よりも顧客の協力が優先されます
4. 計画に従うよりも変化にうまく対応する
アジャイル原則
1. 継続的デリバリ、スモールステップ、クイックステップ
反復する
2. 変化を受け入れて自分の強みを伸ばす
3. できるだけ早くフィードバックを提供し、価値に基づいてランク付けします
バックログの ToDo 項目
4. 結果を達成し、進捗状況を測定する
国防総省、AC、国防総省
5. 機敏性を強化するための継続的なアップデート
トレーニング
6. 製品を合理化し、無駄を排除する
MVP
7. チームワーク、日々の交流
スタンドアップミーティング
8. メンバーを信頼してサポートしてください
非公式に
9. 効率的かつ明確な対面コミュニケーション
面と向かって
10. 全党メンバー、安定したリズム
フルタイム、交代なし、スピード変更なし
11. 協力して自分自身を組織する
チーム憲章に基づいて自己組織化
12. チームの内省と継続的な改善
反省会・反省会
役割
チーム(部門横断型チーム)
1. 人数:3~9名
2. チームメンバーは部門横断的に構成されており、T 字型の人材が奨励されています
3. メンバーはフルタイムである必要があり、少なくとも反復内で自由に変更することはできません。
4. チーム憲章/イテレーションバックログの制約内であらゆる形式の意思決定を行う権限を持っています
5. 高い自己組織化能力
6. 製品の機能を Po にデモンストレーションする必要がある
7. チームは国防総省を定義する必要がある
Po (プロダクトオーナー)
1. 製品の特徴を決定する
2. 発売日を決める
3. ユーザーストーリーを優先する
4. 製品のROIに責任を負います
5. 各イテレーション/スプリントの前に、必要に応じて機能と優先順位を調整します。
6. 開発チームの作業を受け入れるか拒否するか
7. 顧客の代弁者として、さまざまなニーズやフィードバックを受け取り、To Do リストを常に整理する
チームファシリテーター
異なる組織内の役職
1. スクラムマスター
2. チームリーダー
3. プロジェクトマネージャー
チームのファシリテーター
1. サーバントリーダーシップを促進する
1. 自己認識を向上させる
2. 聞く
3. チームに貢献する
4. 他の人の成長を助ける
5. 指導と制御
6. 安全、敬意、信頼を促進する
7. 他者のエネルギーと知性を促進する
2. 決断を下すのではなくサポートを提供する監視員のようなもの
3. チームメンバーにタイムリーな支援を提供する
4. 適切なトレーニングと指導を提供する
5. 良好なコラボレーションを確保する
6. チーム開発の障害を解決する
7. チームメンバーに対する外部からの干渉に対処する
8. さまざまな会議を開催する
ガバナンスチーム
アジャイルPMO
目的
組織がビジネス価値を実現できるよう導く
タイプ
1. 価値主導型
2. イノベーション志向
3. 学際的な
責任
1. 標準の開発と実装
2. トレーニングと指導を通じて人材を育成する
3. 複数のプロジェクト管理
4. 組織的な学習を促進する
5. 利害関係者の管理
6. プロジェクトリーダーの採用、選別、評価
7. 特殊なプロジェクトタスクを実行する
方法
カンバン
1. 情報の発信源
2. 視覚化: プロジェクトのステータスと関係者全員の透明性のある情報を表示します。
3. ワークフローと価値の提供の継続性を確保する
4. 内容: これから行う作業、進行中の作業、完了した作業
5. 進行中の作業 (WIP) 制限を遵守する: 新しい作業を開始するよりも作業を完了することが重要です
エクストリームプログラミング
1. 軽量な開発プロセス
2. 顧客と開発者が対面で
3. 練習する
3.1. 継続的インテグレーション
3.2. ペアプログラミング
3.3. 受け入れテスト駆動開発
3.4. テスト駆動開発
3.5. 探査(プローブ)
スクラム
2 つの To Do アイテムのバックログ
1. 製品バックログ項目
2. 反復バックログ
カテゴリー3の職員
1. スクラム マスター (プロジェクト マネージャー): プロセスとタスクの保守を担当します。
2. プロダクトオーナー Po: ステークホルダーを代表します
3. 開発チーム: すべての開発者が含まれます
4回の会議
1. イテレーション計画会議
2. 毎日のスタンドアップミーティング
3. イテレーションレビューミーティング
4. イテレーションレビュー会議(反省会)
DSDM
タイムボックスタイムボックス
価値
1. パーキンソン病の法則に良い薬
2. 難しい意思決定やトレードオフを早期に促進する
3. より良いコントロール
4. 金メッキを防ぐ
運用ルール
1. 各タイムボックスプロセス中に人を追加しないでください
2. タイムボックスはパフォーマンス評価には使用されません
3. タイムボックス内での変更は許可されません
4. 毎日の同期
太陽を追いかけるモード
毎日の終わりに次の勤務ステーションに仕事を引き継ぎます。
水槽ウィンドウモード
1. 拠点間の長期的なビデオ会議リンクを確立する
2. 毎日の作業の開始時にリンクを開きます
3. 作業が終了したら接続を閉じます
リモートペアリングモード
2 人がペアになって同じ作業を行い、ツールを介して画面を共有します
結晶法
3 つの要素を使用して、プロジェクトに適切なアプローチを決定します
参加者数
プロジェクトの重要性
プロジェクトの優先順位
遷移
混合ライフサイクル アプリケーション シナリオ
1. 組織は完全に機敏になることはできない
2. アジャイル移行期間
3. 予測ライフサイクルの配信速度を加速する
4. チームメンバーの思考パターンを変える
アジャイル変革を成功させるための戦略
1. 学習を促進するために反復手法をさらに追加します
2. さらなるテクノロジーの追加により、スポンサーの投資収益率が加速します
3. 新しいテクノロジーは、リスクが低く、不確実性が低から中程度のプロジェクトで最初に試してください。
4. 組織全体でハイブリッド手法の使用に成功した後、より複雑なアジャイル プロジェクトを試す前に
全プロセスの実践
物事の方向性 - 製品ビジョン
エレベーターの試験方法
興味を引くために製品を 1 ~ 2 分で紹介します
ビジョンボックス
1. プロジェクトの機能とそれがもたらす利点を実証する
2. 名前もブランドもある
3. ハウツーガイドが含まれています
物事のペース -- 製品ロードマップ
人間の要件 -- アジャイル チーム憲章
1. サーバントリーダー、チームで決める
2. 目標は、チームメンバーが最大限の能力を発揮できるアジャイルな環境を構築することです。
3. メインコンテンツ
1. チームの価値観: 持続可能な開発スピードとコア労働時間
2. 労働協約
1. チームが仕事を受け入れる前の「準備状況」を定義する方法
2. チームが満場一致で完全性を判断できるように「完了」を定義する方法
3. タイムボックス化を検討する
4. 作業プロセスの制限を使用する
3. 基本的なルール
4. チームの規範
ユーザーストーリー
1. 粒度: ユーザーストーリー – 機能 – エピック
2. 標準文法: as、can、so that
3. 投資の原則
製品バックログ バックログ
コンテンツ
1. ソートされたリストです
2. PO はコンテンツ、可用性、優先度に責任を負います
3. 常に不完全
4. ダイナミックです
DEEP原則
1. 適切に詳細かつ簡潔に
2. 推定
3. ダイナミックな開発
4. 優先順位を付ける
PBL出力の原則
1. チームメンバーはまずデモを行うことを検討する必要があります
2. スプリント内では調整は行われません
3. このサイクルのバグは必ずしもこのサイクルで解決する必要はなく、バグの優先度によって異なりますので、PO に確認する必要があります。
4. 製品バックログは設計と要件を考慮します
5. スプリント バックログは計画と設計の両方を考慮します
毎日のスタンドアップミーティング(毎日のスクラムミーティング)
1. 毎日同じ時間、同じ場所
2. 通常15分
3. チームメンバーのみが発言できます
4. 他の人も参加できますが、見学のみ可能です
5. メンバー全員が順番に3つの質問に答えます
昨日達成されたこと
今日は何をしますか
仕事でどんな困難や障害に遭遇しましたか?
6. スクラムタスクボードを使用して進捗状況を実証できる
7. バーンダウン/発火チャートを表示可能
8. タスクが分割される可能性があります
9. 時間厳守の重視
10. ショーの問題解決にあまり時間を費やさないでください
イテレーションミーティング
イテレーション計画会議
パート1
1. PO は、全体的な製品計画と優先順位付けの方法をチームに導入します。
2. チームメンバーは可能な限り質問します
3. PO で受け入れ基準を確認する
4. ビジネス価値とその起源にもっと注意を払う
5. デザインの問題について考えすぎないでください
6. それが何であり、何がそうでないかを確認する
7. 異常シナリオの確認
パート2
1. ユーザーストーリーをタスクに分割し、スプリントバックログ項目を作成する
2. POはプロセス全体に参加しました
3. チームメンバーが共同で見積もる
4. 見積もりはあまり詳細にしないでください
5. タスクは人が実装する必要がある
6. PO は見積もりプロセス中の需要関連の問題に責任を負いますが、見積もり結果に干渉することはできません。
7. 文書タスクの管理も見積もる必要があります。
具体的な手順
1. 質問を確認する
ストーリーの優先度を確認する
期待値
料金
産業と技術
危険
MoSCoW の原則
リスクと価値の関係
まずは対処してください: 高リスク、高価値
2 番目の治療: 低リスク、高価値
最終治療: 低リスクかつ低価値
回避: 高リスク、低価値
2. スプリットストーリー
分割する時期
ストーリーは反復よりも大きい
多数のストーリーが複数回の反復に配置されているため、ストーリーを分割する必要がある
3. 見積もりの話
ストーリーポイント
1. サイズの相対的な尺度
2. 他のプロジェクトと比較することはできません
3. 部門横断的な推進に貢献
4. ストーリーポイントに有効期限はありません
5. 純粋なサイズの測定
6. 通常は速い
理想的な日
1. 実際の時間と理想的な時間の差
2. 説明しやすい
3. 簡単に始められる
4. 目標を確認し、スプリント バックログ項目を作成する
ポイント1
1. 優先順位の一貫性を確保するには、MoSCoW 原則を使用してください
2. チームメンバー全員が参加する必要があります
3. 各ユーザーストーリーをどのように実装するかを議論する
4. 開発タスクを特定する前に、完了の基準を明確に定義します
5. 完了する必要があるすべてのタスクを特定する
ポイント2
1. 事前に個人にタスクを割り当てないでください
2. スプリントのコミットメントを再検討する
3. あまり時間を使わないでください
4. 単純な開発プロジェクトの場合は、ストーリーを直接 SBL に入れることができます。
5. 複雑なプロジェクト開発はタスクに分割する必要がある
イテレーションレビューミーティング
1. チームは開発した製品の機能をPOにデモンストレーションします
2. PO が会議を企画し、関係者に参加を呼びかけます
3. ライブデモンストレーションを通じて
4. あまりフォーマルになる必要はありません
5. PPTは必ずしも必要ではありません
6. 通常2時間以内に制御される
7. 変数判定ではなく属性判定
8. ユーザー ストーリーが渡されない場合、PO は優先順位を決定し、どのスプリントで完了するかを決定します。
イテレーションレビューミーティング
1. 反省会とも言う
2. 目的は、さらなる問題解決を促進するために経験と教訓を要約することです。
3. 特性要因図とカード法が使用可能
4. ハンバーガーの原則: まず賞賛し、次に批判し、それから解決策を与える
5. 変化の評価: 変化した理由とそれを回避する方法を考える
6. 未完成のユーザーストーリーの評価: なぜ完成しなかったのか
7. たった一つのルール
アジャイルな作業プロセスにおけるアプリケーション
統合する
1. 反復的で機敏な手法により、チームメンバーは関連分野の専門家ペアとして統合管理に参加できます。
2. チームメンバーが独自の計画を決定する
3. プロジェクトマネージャーは、協力して意思決定を行う雰囲気を作り出すことに重点を置いています
4. T字型の才能
範囲
1. プロジェクト全体を通じて、それがますます明らかになりました
2. プロジェクト全体を通じて定義および再定義される
3. バックログに要件を追加する
スケジュール
1. 短いサイクルで作業する
2. 成果物の適合性について迅速なフィードバックを提供する
3. 小規模なプロジェクトと大規模な取り組みの両方が存在する可能性があります
4. ミックス
5. プロジェクト マネージャーの役割は変わりませんが、より多くのツールとテクニックを知る必要があります
料金
1. 高レベルと予測 - 軽量の推定
2. 短期計画 - 詳細な見積もり
品質
1. プロジェクト全体を通じて頻繁に品質とレビューのステップを実施
2. サイクルレビュー、車両品質プロセス効果の定期検査
3. 問題の根本原因を特定し、新しい品質改善方法の導入を推奨します。
4. 頻繁な増分デリバリーと小規模バッチ作業に重点を置く
5. 不一致や品質問題を早期に発見
リソース
1. ゼネラリストを擁する自己組織化チーム
2. 協力チーム
3. 迅速な供給と当事者 B との法的合意
通信する
1. より頻繁かつ迅速にコミュニケーションを取る
2. チームメンバーが情報を入手し、チームが協力できるようにチャネルを簡素化するように努めてください。
3. プロジェクトの作業を透明性のある方法で公開し、定期的に関係者を招待してプロジェクトの作業をレビューする
危険
1. 各イテレーションで取り組む内容を選択する際はリスクを考慮する
2. リスクイベントをToDo項目に入れる
3. リスク対応計画と要件をまとめて優先順位を付ける
購入
1. 買い手と売り手はプロジェクトのリスクとプロジェクトの報酬を共有します
2. 全体的な協力関係は主契約によって管理され、適応的な作業は付録または補足文書に書き込まれます。
利害関係者
1. 関係者と直接やり取りする
2. 組織内および組織間の透明性の高い情報共有
3. 関係者全員をプロジェクトの会議やレビューに招待する