マインドマップギャラリー PMP アジャイル管理モデルのナレッジ ポイント
アジャイル モデルの知識ポイントを整理し、PMP 試験のアジャイル テスト ポイントを整理することを目的としており、誰もが忙しいスケジュールから解放され、半分の労力で 2 倍の結果を達成できます。
2022-10-26 19:15:34 に編集されましたアジャイルモデルのナレッジポイント
1. 重要性
PMP試験が42%を占める
2. アジャイルナレッジポイントピラミッド
考え
アジャイルの中核となるアイデアと原則
人員
アジャイルな組織構築
プロセス
テクノロジー、プロセス、ツール
主なテストポイント
組織変革
アジャイルな変革と継続的な改善
3. アジャイルの概念
4 つのプロジェクトのライフサイクル
予測する
一度納品すると、最終的なやり直しのリスクが大きくなる
需要は頻繁に変化せず、納期も固定されません。
反復する
顧客の変化に適応し、一度だけ納品
インクリメント
市場を獲得するには迅速にオンライン化しますが、多くのやり直しが必要になる場合があります
アジャイル
別名適応型ライフサイクル
インクリメンタリティとイテレーションの利点を組み合わせる
顧客の変化する環境に適応し、小さな反復で顧客のフィードバックを収集できる
小規模な反復を開始できる
変化に素早く適応し、迅速に市場投入します
アジャイルマニフェストの4つの価値観
プロセスやツールよりも個人と相互作用の方が重要です
完全なドキュメントよりも実際に動作するソフトウェアの方が重要です
協力交渉よりも顧客との協力が重要
計画を遵守することよりも変化に対応することが重要です
アジャイル管理コア
人間指向
価値を提供する
変化を受け入れる
改善し続ける
12の原則
原則 1: 当社の最大の目標は、価値のあるソフトウェアを早期かつ継続的に提供することで顧客のニーズを満たすことです
原則 2: ソフトウェアが稼働していることが進歩の最初の指標である
原則 3: 使用可能なソフトウェアを数週間から数か月の間、頻繁に提供しますが、短いほど良いです
原則 4: テクノロジーを洗練し、設計を改善すると俊敏性が向上します
原則 5: シンプルさ、つまり不必要な作業をできる限り最小限に抑えることは芸術です
価値を提供する
原則 6: アジャイル プロセスは持続可能な開発を促進します。プロジェクトのスポンサー、開発者、ユーザーは常に安定したペースを維持できます
原則 7: ビジネス担当者と開発者は、プロジェクトの実施中常に協力しなければなりません
原則 8: プロジェクト担当者のやる気を引き出すのが上手で、彼らに必要な環境とサポートを与え、彼らがタスクを完了できると信じる
原則 9: 開発チームに対してであっても、チーム内であっても、情報を伝える最も効果的な方法は対面での会話です
原則 10: 最良のアーキテクチャ、要件、設計は自己組織化されたチームから生まれる
人間指向
原則 11: プロジェクト開発の後半であっても、要件の変更は歓迎されます。アジャイル プロセスは、顧客が競争上の優位性を獲得できるように、要件の変化を上手に活用する必要があります。
変化を受け入れる
原則 12: チームは、どうすればより効果的になれるかを定期的に振り返り、それに応じて行動を調整する必要がある
改善し続ける
4. アジャイルな役割
プロダクトオーナー (PO)
経営戦略: 製品ロードマップの作成
ニーズの決定: ビジネス価値に応じてユーザー ストーリーを追加、調整し、並べ替えます。
承認: プロジェクト結果のレビューとフィードバック
スクラムマスター(チームリーダー)
保護: チームを中断から保護します。
保証: 障害物を取り除く
維持: プロジェクトとチームの憲章を通じてプロジェクト ビジョンの継続的なガイダンスを維持します。
ナニー: チームにサポートを提供する
チーム
仮想チーム: コミュニケーション計画が最も重要です。信頼関係を築き、コラボレーションする方法を学び、金魚鉢ウィンドウやリモート ペアリングを使用してコミュニケーションを改善するために、チーム メンバーを定期的に集めることを検討してください。
作業エリア: プライベートエリアとパブリックエリア
浸透圧コミュニケーション: 連携して作業するチームメンバー間で無意識に情報が共有される
フルタイム、ゼネラリスト、部門横断型、自己組織化チーム、3 ~ 9 人のチーム
チームの主な特徴: タスクの切り替えの回避、知識の共有、機能チーム、プロアクティブな作業、チームの意思決定、チームの問題解決
5. スクラム管理フレームワークの要素
製品バックログ
目的: 要件を記録する
ユーザー ストーリー セットとも呼ばれ、各要件はユーザー ストーリーです。
ユーザーストーリー
ユーザーとして、その時・場所で、何をしたいのか、何の目的・商品価値があるのか?
それで、どうすればいいですか/どのように操作すればよいですか
結局どうやって確認するのか
製品バックログの機能
作業を開始する前に、プロジェクト全体のすべてのストーリーを作成する必要はなく、最初のリリース計画のメイン コンテンツだけを作成する必要があります。
To Do リストは常に変更および改善されており、いつでも更新、追加、削除、修正、優先順位の変更などを行うことができます。
要件が変更された場合、変更プロセスを経る必要はなく、To-Do リストに直接追加できます。
巨大なユーザー ストーリー (エピック ストーリーとも呼ばれる) は、バックログの最後に書き込まれます。
完了したユーザー ストーリーの定義: 0/1 合法、完了または未完了
要件をどこから始めればよいかわからない場合は、インパクト マップをバックログへの効果的な入力として使用できます。
製品バックログ検討会議
内容: 現在の製品要件リストを整理し、優先順位付けや適度な粒度のストーリー カードへの分割などを行います。
グルーミング ミーティングの時間: 2 週間のスプリントで 1 時間のタイムボックス ディスカッション
グルーミング会議とスプリント計画会議の関係: スプリント計画会議は、プロダクト バックログのグルーミング会議が完了したときにのみ開始できます。
特性
従来のモデル: 範囲は固定、時間とコストは可変
アジャイル モデル: 時間とコストは固定、範囲は可変
アーティファクト
製品バックログ
スプリントバックログ
インクリメント
タスクフロー
a. ユーザーストーリーコレクション
b. 各ユーザーストーリーのサイズを見積もる
ストーリー ポイントの推定値は、チームによって推定された複数の推定値です。
c. ユーザーストーリーの優先順位を評価する
d. チームのベロシティを推定する
チームベロシティ: チームが単位時間当たりに完了する作業量
スプリントごとに完了した平均ストーリー ポイント
見積もり
ストーリーポイントを使用したユーザーストーリーの推定
ストーリー ポイントは、ユーザー ストーリーの期間ではなく、ユーザー ストーリーのサイズと複雑さを測定する方法です。
従来の期間推定の問題点
従来のプロジェクト計画は時間、日、週単位で測定されます
現実: 不正確な見積もりや過剰な約束を避けるために、見積もりツールは最終的に期限を提示します。
ストーリーポイント推定の利点
見積もりの精度を心配する必要はありません。早く仕事に取り掛かりましょう
チームは見積もりと約束を混同しない
見積もり = 適切な推測。コミットメント = 最悪のシナリオの戦略。
推定方法
ポーカーの見積もり
フィボナッチ数列
チームメンバーはストーリーポイントに基づいてストーリーを推測します
Tシャツ見積もり
見積りポーカーよりも大まかな見積りであり、見積りポーカーよりも合意が容易です。カード6枚
アフィニティサイズの推定
ストーリーを比較するのは正確な倍数ではありません。ポーカーで評価するよりも合意に達するのが簡単です。
ユーザーストーリーの優先順位付け
モスクワ法 (MoSCoW)
母:やらなきゃいけない
S: やるべきだ
C: できるかもしれない
女性:それはしません
狩野モデル
基本的なニーズ: 必須 (優先開発)
パフォーマンスのニーズ: 多ければ多いほど良い (可能な限り多くのことを達成する)
快楽ニーズ:高い満足度
100点法
それぞれ 100 ポイントに分割され、これらのポイントを使用して最も必要なニーズに投票できます。
相対的な大きさ
お客様の判断に基づき、製品価値を最大化する見積りを行います
プロジェクトスケジュール
製品ビジョン
製品ロードマップ (2 ~ 5 年)
発売予定(6月~12月)
スプリント計画 (1 ~ 4 週間)
毎日のスタンドアップミーティング
6. アジャイル活動
スプリント計画会議
前半: チームは PO に製品バックログの内容、目的、意味、意図について質問します。
後半: チームはこのスプリントのスケジュールを計画します
ユーザーストーリーをアクティビティに分割し続ける
チームメンバーが活動の分担を決める
毎日のスタンドアップミーティング
毎日のチームミーティング (通常は 15 分)
コンテンツ
前回のスタンドアップの後、私は何をしましたか?
このスタンドアップミーティングの後は何をすればよいでしょうか?
仕事でどのような障害、リスク、問題に遭遇しましたか?
問題が発見されたら、駐車場に追加し、別の会議を作成し、スタンドアップの直後に開催し、その会議で問題を解決します。
プロジェクト マネージャーやリーダーではなく、チーム メンバーに会議を主導するよう奨励します。
チームとして自主的に組織化され、相互にコミットする会議
道具
Srcumタスクボード
タスク ウォールには、スプリント中に完了する必要があるすべてのタスクが表示されます。チームはタスクボードを通じて問題を適時に発見し、迅速なフィードバックを提供できるため、作業を完了する際の自信も高まります。
バーンダウンチャート
x: タイムライン、y: 残りのストーリー ポイント
点火チャート
x: 反復 1、反復 2...、y: 完了したストーリー ポイント
リスクバーンダウンチャート
x: 時間軸、y: リスクエクスポージャ値
リスクエクスポージャ値 = リスク発生確率 % * リスク影響 (日)
リスク対応計画をToDoリストに書き込み、活動を一元管理できる
カンバン
ビジュアルワークフロー
仕掛り量を制限(仕掛品制限)してプル生産を実現し、生産効率を向上
ToDo、研究開発(進行中、完了)、テスト(進行中、完了)、完了
サイクルタイムを短縮したい場合は、進行中の作業量を減らす必要があります
累積フローグラフ
カンバンボードとタスクボード
共通点: ビジュアルワークフロー
違い: リーン理論では、カンバンは効率を向上させ、より大きな利益を得ることができます。
スプリントレビューミーティング
スプリント レビューは、このスプリントで開発された製品機能を PO にデモンストレーションするために使用されます。
PO はこの段階で会議を開催し、関係者に参加を呼びかけます。
会議内容
チームはスプリント中に完成した機能をデモンストレーションします
チームメンバー全員が参加する必要があります
誰でも参加できるように招待できます
PO はストーリーを承認または拒否する責任があります
一般的なガイドラインは、少なくとも 2 週間に 1 回、チームの成果物を発表することです。ほとんどのチームにとって、この頻度は、チーム メンバーが間違った方向に進まないようにフィードバックを得るのに十分な頻度です。
スプリント振り返りミーティング
目的: 良い経験を共有し、改善点を発見してチームの継続的な進歩を促進します。通常、ミーティングは各スプリントの後に開催されますが、チームの意思決定によって重要な瞬間に振り返りが開催される場合があります
会議内容
このスプリントで何がうまくいきましたか?
このスプリントでさらに改善できることは何でしょうか?
次のスプリントではどの領域を改善できるでしょうか?
会議の手順
定性的 (人々の感情) および定量的 (指標) データを見つける
このデータを使用して根本原因を見つけます
対策の立案と実行計画の策定
スプリント振り返りミーティングからの重要なポイント
ミーティングの目的: これは責任ではありません。レビューはチームが継続的に改善できるようにするためのものです。
焦点: チームは優先順位を一緒に話し合い、最も必要な部分に重点的に取り組みます (いくつかの改善点に焦点を当てるだけで十分です)
会議の結論は閉ループで追跡する必要があります。結論は製品バックログに入れ、各改善の測定結果を決定し、各改善が成功したかどうかを検証できます。
スプリント
7. アジャイルなプロジェクト実施方法
XPの技術的実装
継続的インテグレーション
作業を全体に頻繁に統合する
さまざまなレベルのテスト
エンドツーエンドの情報には、システムレベルのテスト、つまりシステム全体のテストが使用されます。
構成要素の単体テストを使用する: ソフトウェア内のテスト可能な最小単位を検査して検証します。
システム統合テスト: 単体テストに基づいて、すべてのモジュールが設計要件に従ってサブシステムまたはシステムに組み立てられます。
スモーク テスト: ソフトウェア開発プロセス中のソフトウェア バージョン パッケージの迅速な基本機能テストおよび検証戦略
回帰テスト: 古いコードを変更した後、再テストして、変更によって新たなエラーが発生したり、他のコードでエラーが生成されたりしていないことを確認します。
自動テスト: ソフトウェアテストの自動化
受け入れテスト駆動開発 (ATDD)
チームは作業成果物の受け入れ基準について一緒に話し合います
チームは標準要件を満たす自動テストを作成します
テスト駆動開発 (TDD) と動作駆動開発 (BDD)
TDD: 関数コードを開発する前に、最初に単体テスト ケース コードを作成します。テスト コードによって、どの製品コードを作成するかが決まります。
BDD: 自然言語または自然に似た言語を使用して、ユーザー ストーリーまたはユーザー ユース ケースを作成することにより、機能ユーザーの観点からテスト ケースを説明および作成します。
探る/探る
システム、テクノロジー、アプリケーション分野における未知の状況を検出
学習に役立ち、チームがいくつかの重要な技術的または機能的要素を学ぶ必要がある場合に使用されます。
技術的負債の解決
技術的負債は、チームが短期的なプロジェクトの利益のために故意に技術的意思決定を誤ることによって引き起こされます。
解決策はリファクタリングとアジャイル モデリングです
ペアプログラミング
2 人のプログラマーがコンピューター上で協力し、1 人がコードを入力し、もう 1 人が入力したコードの各行をレビューします。コードを入力する人はドライバーと呼ばれ、コードをレビューする人はオブザーバー (またはナビゲーター) と呼ばれます。 2 人のプログラマーは役割を交代することがよくあります
コードは集合的に所有されています
すべてのチームメンバーにはコードを変更する権限があり、チーム全体の所有権と説明責任があります。
その他のアジャイル手法
結晶
プロジェクトのサイズとプロジェクトの重要性の 2 つの側面に基づいて、さまざまなアジャイル手法のオプションが提供されます。例: C6、D6
関数駆動開発 (FDD)
機能リストを確立し、機能に基づいてスケールと設計を行う
動的システム開発 (DSDM)
最初からコスト、品質、イベントを設定し、正式な範囲の優先順位付けを活用してこれらの制約を満たす
アジャイル統合プロセス (AUP)
アーキテクチャを核にデータベース設計を中心に、ユーザーとのコミュニケーションを重視
スクラムオブスクラム (SoS)
1 つの大規模なスクラム チームではなく、2 つ以上のスクラム チームで使用される手法。チームには 3 ~ 9 人のメンバーが含まれ、作業を調整します。
スケーリングされたアジャイル フレームワーク (SAFe)
ポートフォリオ、プロジェクト、チームレベルでの実践、役割、活動の詳細に焦点を当てます。顧客に継続的な価値の流れを提供することに重点を置いてビジネスを組織することに重点を置く
大規模なアジャイル開発 (LeSS)
20、100、さらには数千人で構成され、全員が特定の共有製品で協力するアジャイル チームに適用できるマルチチーム スクラム フレームワーク
エンタープライズスクラム
個々の製品開発レイヤーではなく、より全体的な組織を通じてスクラム方法論を適用するように設計されたフレームワーク
規律あるアジャイル (DA)
複数のアジャイルのベストプラクティスを包括的なモデルに統合したプロセス意思決定フレームワーク
8. 組織変革
アジャイルへの組織変革の原則
変更管理
変化に影響を与える要因
文化の創造
アジャイルな組織文化を作る方法
組織主導型
アジャイルPMO
サプライヤー
アジャイルな変化に影響を与える要因
アジャイルな変化の原動力
迅速かつ確実な配送
すでにアジャイルな特性を備えたチーム
組織構造が機敏な変化に与える影響
地理上の位置
機能構造
プロジェクト成果物の成功規模
プロジェクトの人員配置
購買を重視する組織
アジャイルな変化への準備
変化への対応力の特徴: 経営者の意欲、従業員の意識、人材の能力など。
変化に残された障害の特徴
アジャイルな文化の構築
ステップ 1: 安全な環境を作成する
ステップ 2: 文化を評価する
パート 3: プロジェクト リーダーがアジャイル文化の出現を加速する方法
積極的かつ明確な経営サポート
変更管理の経験を活用して推進する
プロジェクトごとにアジャイル実践を推進
段階的な導入
アジャイルの技術と実践を実証し、指導する
アジャイル プロジェクト管理オフィス (PMO)
価値主導型
プロジェクトの価値提供を実現する
イノベーション志向
革新的なアイデアや視点を考え、実践することで、顧客が価値を迅速かつ効率的に実現できるよう支援します。
多分野性
さまざまなプロジェクトサポートのニーズに対応するために、プロジェクト管理自体を超えた知識に精通する
アジャイル契約
多層構造
価値の提供を重視
合計価格の増分
決まった時間と材料
進行時間と材料
予定を早めにキャンセルする
ダイナミックレンジ方式
チームの拡大
あらゆるサプライヤーをサポート
範囲調整可能