マインドマップギャラリー PMP アジャイル レビュー
PMP 試験の前に、アジャイル開発関連の知識とテスト ポイントがまとめられます。その内容には、プロジェクト ライフ サイクルの選択、アジャイル マニフェスト、12 の原則、スクラム フレームワーク、その他のアジャイルの概念、および 10 の主要な知識領域に基づくアジャイルの考察が含まれます。
2023-05-18 23:36:51 に編集されましたPMP アジャイル レビュー
プロジェクトのライフサイクルのオプション
予測的
伝統的なプロジェクト、成熟産業: 建設、製造、IT 産業など
アジャイル
反復する
インクリメント
ハイブリッド
企業は予測型からアジャイル型へ移行
アジャイル プロジェクトへの予測は、部分的には予測であり、部分的にはアジャイルです
質問に対する答えを選択の方向として使用する、予測または機敏性
アジャイルと予測を区別するための質問としてキーワードを使用します
組織の変化: 予測型からアジャイル型へ
まず、企業文化と変革が企業に与える影響を分析および評価します。
企業のあらゆるレベルの人々を巻き込んで、トップダウンで変化を起こし、変化の利点と不可欠性を理解する
それほど複雑ではないプロジェクトをパイロットとして選択して、迅速な成功を達成し、他のプロジェクトに自信をもたらすことができます。
アジャイルマニフェスト
人員
プロセスやツールよりも個別の対話が重要
顧客の協力が契約交渉よりも優先される
価値の提供
使いやすいソフトウェアは完全なアーカイブに勝ります
計画に従うよりも変化に対処する方が良い
12の原則
価値の提供
私たちの最も重要な目標は、価値のあるソフトウェアをタイムリーかつ一貫して提供することでお客様に満足していただくことです。
たとえ開発の後半であっても、要件の変化に直面する準備をしてください。アジャイルなプロセスで変化を制御し、顧客の競争力を高める
動作するソフトウェアを頻繁に、数週間または 1 ~ 2 か月の間隔で提供し、より短いサイクルを優先します
動作するソフトウェアは進歩の主な尺度です
人員
ビジネスマンと開発者は、プロジェクトの毎日において互いに協力しなければなりません
個の闘争心を刺激し、個を核としてプロジェクトを構築する。目標達成に向けて必要な環境とサポートを提供し、信頼に裏付けられる
チームの内外を問わず、情報を伝えるための最良かつ最も効率的な方法は、対面での会話です。
アジャイルなプロセスは持続可能な開発を促進します。所有者、開発者、ユーザーは協力して、安定した継続的なペースを維持できなければなりません
最高のアーキテクチャ、要件、設計は組織チームから生まれます
チームは定期的にパフォーマンスを向上させる方法を検討し、それに応じて行動を調整します。
プロセス
アジャイル能力は、卓越した技術と優れた設計を絶え間なく追求することによって強化されます。
技術的負債とリファクタリング
シンプルさをベースに、不必要な作業負荷を最小限に抑える技術です
スクラムフレームワーク
全体的な枠組み
全体的な枠組み
製品ビジョンと製品ロードマップ
最終製品を完成させるにはいくつのバージョンが必要ですか?
リリース計画
1 つのバージョンによって、リリースのイテレーションまたはスプリントの数が決まります
スプリント計画
要点
アジャイルプロジェクト憲章
なぜこのプロジェクトを行うのか?
プロジェクトのビジョン
誰がその恩恵を受けるのか
これはプロジェクトのビジョンやプロジェクトの目標の一部である可能性があります
このプロジェクトでは、どのような条件が満たされればプロジェクトは完了しますか?
プロジェクトのリリース基準
どのように協力していくのか
予想されるワークフロー
チーム憲章(チーム社会契約)
チームの価値観
持続可能な開発スピードやコア労働時間など
労働協約
たとえば、チームが仕事を受け入れるための前提条件である「準備状況」はどのように定義されますか。
たとえば、チームが一貫して完全性を判断できるように「完了」を定義する方法。
タイムボックス化を検討する
作業プロセスの制限を使用する
基本的なルール
たとえば、会議で発言する人に関するルール
チームの規範
たとえば、チームが会議時間をどのように扱うかなど
3355
3文字
プロダクトオーナー
開発チーム
スクラムマスター
3 つのアーティファクト
製品バックログ
スプリントバックログ
製品の増分
5つのイベント
スプリント
スプリント計画会議
毎日のスタンドアップミーティング
スプリントレビューミーティング
スプリント振り返りミーティング
5つの値
約束
集中
開ける
尊敬
勇気
3文字
プロダクトオーナーPO (顧客担当者、ビジネス専門家)
製品バックログの維持と更新
プロダクトオーナーは、プロダクトバックログの管理に責任を負う唯一の人物です
製品のバックログを維持し、優先順位を付ける
チームがプロダクト バックログを完全に理解できるように明確に説明および表現されている
製品の増分が完了したかどうかを判断して承認する
製品の増分が完了し、DOD の完了定義を満たしているかどうかを判断します。
よく訪れるテストセンター
PO はフルタイムで独立している必要があり、開発チームまたは SM が兼任することはできません。
競合中に新しい要件が変更された場合はどうすればよいですか?
一般的に、新しい要件は PB テーブルに掲載されており、PO によって優先順位が付けられます。この要件は通常、このスプリントでは実行されません。
この質問では、法的要件と非常に優先度の高い要件が強調されており、すぐに完了しないとプロジェクトの失敗につながります。通常、PO はチームとコミュニケーションをとり、完了するようにこのスプリントの目標を再調整する必要があります。できるだけ早くすることは、プロジェクトのニーズの死活に関係します。
開発チーム
自己組織化されたチーム
1 つの専門分野、複数の能力、部門を超えたチーム
開発チームのメンバーは肩書きで認識されるわけではなく、どのような仕事をしていても開発者であることに変わりはありません。
組織のサイロを克服するには、フルタイムのチームで 100% コミットすることが最善です
太陽を追跡する
共通試験のポイント
質問に要件、命令、またはチームに何かを強制するものがある場合、それらは直接削除されます。
ユーザーストーリーの見積もりや作業の割り当てなどは開発チームが決定し、責任を負います。
スクラムマスター アジャイルコーチ、チームファシリテーターとしても知られています。 スクラムマスター、プロジェクトマネージャー
アジャイルチーム全体と関係者がスクラムの理論、実践、ルールに確実に従うようにする
POの場合
PB テーブルの維持および更新方法を含む、PO の職務責任を理解していることを確認します。
開発チームにとって
毎日のスタンドアップミーティングなどの毎日のアジャイルイベントに従うことができ、透明なツールなどを使用できることを確認します。
プロジェクト外向け
たとえば、進捗状況を理解する必要がある場合は、情報の発信源を確認し、ユーザー ストーリーの優先順位を理解する必要がある場合は、PO と連絡を取ることができます。
サーバント リーダーシップ、サーバント リーダーシップ、チームの成長に重点を置き、チームが障害を取り除くのを支援する
内部障壁
開発チームが技術上、プロセス上、その他の問題に遭遇した場合、自分たちで解決するのではなく、解決を支援します。
外部障害物
SM は外部関係者と交渉し、通信します
共通試験のポイント
アジャイル環境では、SM は特定の作業の割り当て、作業の手配などについて責任を負いません。
一般に、SM はチームを妨げる外部要因や障害を排除する責任があります。
3 つのアーティファクト
製品バックログ 製品バックログ
ユーザーストーリー
コンセプト
<役割>としては、<価値>を実現するための<機能>が欲しい
投資の原則
独立した
交渉可能
貴重な
推定可能(評価可能)
小さい
テスト可能
ストーリーポイント
内部参照標準として、チーム内で使用されます。異なるチーム間でストーリー ポイントの数を比較することは無意味です
ユーザーストーリーポイントの見積もり
プランニング ポーカー (ブロードバンド Delphi)
アジャイル見積りポーカーを使用する利点
チームメンバー間のコミュニケーションを促進し、より多くの情報を共有して学習します。
チームによる推定結果の議論と評価により、推定結果がより現実的かつ客観的になり、多くの過度に恣意的な決定が回避されます。
特定のユーザー ストーリー、または反復で使用されるすべてのユーザー ストーリーに適用されます
親和性の推定
PB表全体に適用、全体の概算値
コンテンツが含まれています
将来のリリースで製品を変更するすべての機能、機能、要件、機能拡張、および修正をリストします。
高から低の優先順位に従って、高価値および高リスク > 高価値および低リスク > 低価値および低リスク
ランクの高い製品バックログ項目はより明確で具体的であり、DOR に準拠しており、早急な開発が必要です
継続的な動的な更新、進歩的な詳細
製品所有者には次の責任があります
スプリント バックログ スプリント バックログ
優先度の高いユーザー ストーリーを PB リストからスプリント バックログに移動する このスプリントでは、チームが実行するストーリーの数を決定し、ユーザー ストーリーを調整します。
探る/探る
主に、特定の要件が技術的に実現可能かどうかを知るための背景知識を取得するために、この方法は通常、ユーザー ストーリーを効果的に推定できない場合に使用されます。
前回の振り返りミーティングで特定された優先度の高いプロセス改善を少なくとも 1 つ含めます
開発チームが責任を負い、PO は質問に答える責任を負います。
製品の増分 製品の増分
DOD 標準の「完了」の定義に到達
製品が完成するかどうかは製品所有者が決定します。リリースされるかどうかに関係なく、増分は利用可能であり、継続的に統合される必要があります。
5つのイベント
スプリント
「スプリント」または「反復」と訳される
時間 2 ~ 4 週間 (固定時間ボックス)、5 ~ 9 人
予防
スプリント目標に有害な変更を加えることはできません
品質に妥協できない目標
スプリントをキャンセルできるのは製品所有者だけです。スプリントは非常に短いため、キャンセルはほとんど意味がありません。
スプリント計画会議
計画を立てる
次のスプリントで提供される増分には何を含めるべきですか?
増分を提供するために必要な作業を行う方法
予防
どれだけの製品バックログ項目を選択するかは開発チーム次第です
プロダクトオーナーは、選択したユーザーストーリーを説明し、トレードオフを行うのに役立ちます
参加者
通常、SM、開発チーム、PO が共同で参加しますが、重要なステークホルダーを招待することもできます。
毎日のスタンドアップミーティング
会議内容
昨日
開発チームがスプリント目標を達成できるようにするために私がしたこと
今日
開発チームがスプリント目標を達成できるようにするには、何をすればよいでしょうか?
私または開発チームがスプリント目標を達成するのを妨げている障害はありますか?
会議後、情報排出源(ボード、バーンダウンチャート、ガスチャートなど)と問題ボードを更新します。
予防
会議後は、問題について話し合うのではなく、記録するだけにしてください。専任の担当者が問題解決会議を開催できます。
SM は同じ時間と場所で開催する必要があり、通常はチーム メンバーが主催することが推奨されます。
共通試験のポイント
毎日のスタンドアップミーティングで進捗状況をすぐに追跡し、修正することができます
毎日のスタンドアップミーティングにより、異なるメンバーが同じ作業を繰り返すことを防ぐことができます
問題とリスクをタイムリーに検出し、会議後にタイムリーに改善してプロジェクトへのリスクの影響を最小限に抑える能力
参加者
開発チーム (SM、PO、必要に応じて重要な関係者)
SOSミーティング(スクラム・オブ・スクラム)
スプリントレビュー会議 レビュー会議
製品の増分を確認し、フィードバックを得る
開発チームは製品の増分をデモンストレーションし、PO は関係者に参加を呼びかけ、PO は製品の増分が完了したかどうかを判断します。
製品のバックログを調整する
次のスプリントに移行する可能性が高いプロダクト バックログ項目を明確にする
スプリント レビュー ミーティングの結果、改訂されたプロダクト バックログが作成されます。
参加者
クライアント
重要なパーティー
PO
SM
開発チーム
スプリント振り返りミーティング 振り返りミーティング
うまくいった点と改善が必要な点を振り返り、改善が必要な点を次のスプリントに反映してフォローアップする(継続的改善)
参加者
SM
開発チーム
PO (空き状況によります)
5つの値
約束
目標に取り組む意欲
集中
自分が取り組んだ仕事に自分の心と能力を注ぎ込む
開ける
スクラムでは、プロジェクト内のすべてがオープンになり、誰もが見ることができます
尊敬
誰もが独自の背景と経験を持っています
勇気
約束をし、それを履行し、他人の敬意を受け入れる勇気を持つ
その他のアジャイルコンセプト
かんばん管理
ビジュアルワークフロー
ホワイトボードやカードも作成可能
ボトルネックを解消する
進行中の作業に対する WIP (Work In Progress) の制限
共通試験のポイント
質問では、プロジェクトのワークフローが混乱しており、一部のプロセスがブロックされているため、この問題を効果的に解決できると述べられています。
質問では、他のプロセスや手順は非常に順調に進んでいるが、1 つのプロセスだけがボトルネックに遭遇し、プロセス全体の進行が遅れていると述べています。他のプロセスから部門を超えたチーム メンバーをボトルネック プロセス全体に割り当てることを検討できます。
MVP (実用最小限の製品)
製品の期待される機能を満たす最小限の機能セットを迅速に構築し、製品の展開要件を満たすのに十分な機能を含み、顧客と製品のやり取りに関する主要な前提条件を検証します。
初期のユーザーからフィードバックを得るために、最小限のリソースと最短の時間を試してください。
共通試験のポイント
顧客がニーズを明確に判断できない場合は、予備的な製品プロトタイプを作成し、その後のフィードバックと修正を通じて最終的に顧客のニーズを満たすことができます。
市場が不確実な場合、またはリスクが高い場合は、MVP 設計実験を使用して、製品または方向性が実現可能かどうかを迅速にテストします。
10 の主要な知識領域に基づいてアジャイルを考察する
統合する
特定の製品の計画と納品の管理をチームに委任します。チームメンバーが計画と統合の方法を決定する
プロジェクト マネージャーの焦点は、協調的な意思決定環境を構築し、チームの変化への対応能力を確保することです。
アジャイルには変更を受け入れるプロセスはありません。
範囲
アジャイル手法では、意図的にプロトタイプを構築およびレビューし、複数のリリースを通じて要件を明確にします。このようにして、プロジェクト全体にわたってスコープが定義および再定義されます。
各スプリントの前にスコープを定義する
スプリント計画ミーティングとスプリント バックログ
各スプリントの終了前に範囲を確認する
スプリントレビュー会議のレビューと製品増分の承認
スケジュール
製品ビジョン、リリース計画、イテレーション計画の関係
未完了の項目がある反復スケジュール
これは、適応的なライフサイクルに基づいたローリング計画です。このアプローチでは、要件をユーザー ストーリーに文書化する必要があります。その後、ユーザー ストーリーは構築前に優先順位付けおよび洗練され、最後に、定義されたタイムボックス内で製品機能が開発されます。このアプローチは通常、顧客との対話に増分価値を提供するため、または複数のチームが相互接続性の低い多数の機能を並行して開発するために使用されます。
オンデマンドのスケジュール
通常、制約理論とリーン生産からのプル スケジューリングの概念に基づいたカンバン システムで使用され、チームの実行能力に基づいてチームが実行する作業を制限します。オンデマンド スケジューリング アプローチは、製品開発や製品の増分に関して事前に指定されたスケジュールに依存せず、リソースが利用可能になるとすぐにバックログ項目や作業シーケンスから取得します。
進捗管理ツール
情報の発信源
バーンダウンチャート
点火チャート
料金
軽量な推定方法を使用する
詳細な見積りはジャストインタイムを使用した短期計画に適しています
品質
品質管理を計画する
国防総省の定義
品質の管理と制御
サイクルレビュー、品質プロセスの有効性を定期的にチェックし、問題の根本原因を特定し、新しい品質改善方法を導入します。
少量のバッチに重点を置き、頻繁に納品可能
テスト駆動開発 (TDD)、継続的インテグレーション
リソース
ジェネラリストを含む自己組織化チームなど、集中力とコラボレーションを最大化するチーム構造のメリットを得る
通信する
チームメンバーが情報を入手するためのチャネルを簡素化し、頻繁にチームチェックを実施し、チームメンバーが協力できるようにしてください。
集中オフィス
日常業務: 毎日のスタンドアップミーティング
プロジェクトの成果物は透明性の高い方法で公開され、関係者が定期的にプロジェクトの成果物をレビューするよう招待される必要があります。
日常業務: 情報発信源
報告とコミュニケーション: スプリントレビューミーティング
仮想チーム
水槽の窓
長期的なビデオ会議リンクを確立する
リモートペアリング
音声やビデオのリンクを含む仮想会議ツールを使用して画面を共有する
危険
反復を計画するときはリスクを考慮する必要があります
反復中にリスクを特定、分析、管理する必要がある
要件文書は、現在のリスクエクスポージャーの理解を深め、プロジェクトの進行に応じて作業の優先順位を再設定することに基づいて定期的に更新する必要があります。
購入
チームを拡大するには、特定の販売者との協力が必要になる場合があります。この協力関係により、買い手と売り手がプロジェクトのリスクとプロジェクトの報酬を共有するリスク共有調達モデルが生まれます。
柔軟な契約
多層構造
基本契約書
補足契約
利害関係者
高いレベルの透明性を促進する
たとえば、関係者間の不一致や依存関係、または刻々と変化するプロジェクトに関連するその他の問題をできるだけ早く表面化することを目的として、すべての関係者をプロジェクトの会議やレビューに参加するよう招待したり、プロジェクトの成果物を公共スペースに投稿したりします。 。
変化の激しいプロジェクトでは、プロジェクト関係者の効果的な対話と参加が必要です。タイムリーで陽気な議論と意思決定を可能にするために、適応型チームは複数の管理層を経由するのではなく、利害関係者と直接対話します。