-
Notifications
You must be signed in to change notification settings - Fork 0
DNET_PMPPDUAgile
- 戻る
-
PMP：PDU
- PMセミナー
- PMプラクティス
- PMコンピテンシー
- アジャイル関連（本ページ）
- 組織的PM（OPM）
-
PMP：PDU
-
PMPで言う適応型のライフサイクル区分（
PMP：共通の該当節） -
採用プロジェクト比率が年々増加している...何故か？
-
ビジネス領域の変化
- ニーズの変化が早いビジネス領域
- ニーズの不確実性が高いビジネス領域
-
ITに対する期待の領域が広がってきている
（→ DX：企業がITを利用して事業の業績や対象範囲を根底から変化させる）。- 顧客獲得
- 売上の増加
- 満足度向上
-
システム開発の効率化、スピード化を推進
-
-
アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/manifesto.html -
アジャイル宣言の背後にある原則
http://agilemanifesto.org/iso/ja/principles.html
- ユーザのニーズ・要求からの乖離
- 完全なプロジェクトの失敗
- リリース（移行）の失敗
- 作業未習熟に起因する失敗
- 過剰な機能の盛り込み
Evo、DSDM、XP、FDD、Lean Software Development、
Crystal Clear、EssUp、Kanbanなどがあるが、
最もメジャーなアジャイル開発手法がScrum（58%）。
-
スクラム・チーム
-
プロダクト・オーナー(PO)：１人
開発の方向性を定め、プロダクトの価値を最大化することに責任を持つ。 -
スクラム・マスター：１人
- スクラムチームのリーダーでスクラムの進行役
- 開発チームが合意したプロセスを確実に実行するよう支援
-
開発チーム：３-８人
デザイナー、ライター、プログラマーなど作業を行う人々から成るチーム
-
-
一連の開発作業
-
プロダクト・バックログ
-
プロダクト・オーナーが作成・管理
PBIリストを優先順に並び替える。 -
プロダクト・バックログ・アイテム（PBI）
・実現したいこと
(1) 顧客として
(2) 達成したいこと
(3) その理由
・受け入れ条件
・成果物（ソース、ドキュメント）
・デモと手順
・非機能要件
・完成の度合
・プランニング・ポーカーによるPBIの見積り
・基準となるPBIのポイントを決める。
・各PBIのポイントを基準から相対的に決める。
-
-
スプリント
10営業日（二週間）に4つのスクラム・イベントが定義されている。-
スプリント計画ミーティング（初日）
・チームのタイムボックス、ベロシティ（処理能力的な）の設定。
・PBIからスプリント・バックログ（SBL）を仮決め。
・SBLの実現に必要なタスク（とその時間）をタスクボードに並べる。 -
デイリー・スクラム（朝会）
・タスクボードのToDo、Doing、問題などの説明。
・バーンダウン・チャートで予実（日毎に残タスクの作業量）を確認。 -
スプリント・レビュー（最終日の最初）
SBL（PBI）の現物デモとOK・NGの判断 -
スプリント・レトロスペクティブ（最終日の最後）
Keep・Problem・Try（KPT） → 優先順にActionを設定。 ・継続すること（Keep） ・解決すること（Problem） ・上記の双方を受けて、新規にチャレンジすること（Try） -
プロダクト・バックログ・リファインメント（最終日の最後）
プロダクト・バックログのPBIの追加、変更（優先順位、ポイント）、削除
-
-
-
The Scrum Guide
https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
-
スコープ、スケジュール、コスト、品質について、
-
ウォーターフォール開発は「コスト」変動、その他は固定
SoR開発案件を請負、準委任で契約する場合 -
アジャイル開発は「スコープ」変動、その他は固定
順次リリースするSoE開発案件を準委任、派遣で契約する場合（もしくは内製）
-
-
リスク検討チェックシートの活用
- カテゴリ
- 判断項目
- 重要度
- ウォーターフォールが適する
- アジャイルが適する。
見積・進捗・品質
-
ベロシティ（処理能力的な）が見積・進捗に影響。
- 故にベロシティに幅を持たせておく。
- 80％ ～ 100％ ～ 120％のパターン
-
見積
-
工数
- PBIのポイント
- チームのベロシティ
- バーンダウン・チャート
（ポイント・ベロシティの再見積）
-
スコープ
- 予算 / 単位スプリントあたりの費用 = 実行可能なスプリント回数
- 実行可能なスプリント回数で消化できるPBIがスコープ
-
-
進捗
- リリース・バーンダウン・チャート
予実（スプリント毎にプロダクト・バックログの残ポイント量）を確認。
- リリース・バーンダウン・チャート
-
品質
- ソーシャルコーディング や ペアプログラミング
- テスト自動化、CI / CD、DevOpsを可能な限り自動化
- リリース・スプリント（リリース専用スプリント）を設ける。
- テスタ（QAなど）によるテスト（探針テスト）を行う。
主に上司の介入
-
自己組織化の妨げ
- 上司が決定する
- 開発チームの決定を上司が覆す
-
上司に依る
- タスクの割り当て
- メンバの能力を定量化・可視化
※ アジャイルは上司の介入がなくてもワークする。
※ 従って、上司は進捗を妨げる障害を除去する方が良い。
※ （全体最適化しないため）個人ではなくチームとして評価。
※ どうしてもと言うならメンバとして上司が参画する（のはOK）。
-
PBIのINVEST
-
Independent
依存関係がなく独立している。 -
Negotiable
手段については交渉可能である。 -
Valuable
そもそも顧客にとって価値がある。 -
Estimatable
見積もり可能である。 -
Small (Size Right)
１スプリントで完了できるサイズ -
Testable
テストのチェック条件・確認項目が設定可能
-
-
インセプションデッキ
-
アジャイルにおけるプロジェクト憲章
-
以下の10個の質問についてチームで話し合う
- 我々はなぜここにいるのか
- エレベータピッチ
- パッケージデザイン
- やらないことリスト
- プロジェクトのコミュニティ
- 技術的な解決策の概要
- 夜も眠れなくなるような問題
- 期限を見極める
- トレードオフ・スライダー
- 初回リリースに必要なもの
-
リーン
-
カンバン
-
アジャイル
- DSDM
- XP
- FDD
- ASD
- スクラム
- スクラムバン
- クリスタル
参考：PMP > 歴史（PMP の該当節）
-
予測型
ウォーターフォール（PMP：共通の該当節） -
反復型、漸進型
スパイラル（PMP：共通の該当節） -
適応型
-
リーン
トヨタ生産方式を手本に７つの無駄を削除 -
カンバン
現場の可視化のためにカンバンを利用（以下のリスト）- ユーザー・ストーリー
- カンバン
・作業待
・作業中
・テスト中
・完了
-
DSDM
ステークホルダーに焦点を当てる方法 -
XP
- 変化を抱擁（顧客第一、変更の予定）
- 開発のベストプラクティス（ペアプロ、TDD等）
- 開発サイクルを反復（タイムボックス、イテレーション）
-
FDD
成果物をユーザ視点でモデル化する手法- 機能単位で開発（２週間単位の規模）
- Domain Object Modeling（DOM）の採用
-
スクラム
マネジメントのフレームワーク
-
-
新しいPMのリーダーシップ・スタイル、革命
-
革命（チェンジ：何を → どうやって → 何に）
- マーケティング、コミュニティ、問題領域の発見、しがみつく（？）
- 仲間を作る、成功させる、結果を宣伝する、チーム評価
- 上位マネジメント、中間管理職、PMO、施設、財務、調達
-
ビジネス・ケース作成
-
ポイント
- 専門家の知恵を借りる
- 投資効果の明確化
財務指標：ROI、NPV、PP、IRR
-
手順
- ビジョン記述 → ビジネス提案
- 財務的ビジネス・ケース（ROI、NPV、PP、IRR）
- 組織的影響（抵抗と克服、リスクの対応）
-
-
ポイント
- 手法の選択
- 小さくか、ビッグバンか
- 公にするかどうか
- トレーニング、コーチング
- リーダーシップ（サーバント・リーダーシップ）
- エンジニアリングの実務（現場の声）
-
大規模化
規模に関する４テーマ-
組織
- プロダクト・オーナー（PO）
- 複数チーム（専任/兼務、統合/分散、PMO）
- 経験と知識の共有（ナレッジ（KM,KB）、コミュニケーション）
-
プロダクト・バックログ
- 大きさ
プロダクト → エピック → フィーチャー → ユーザー・ストーリー → タスク - 作業分担
プロダクト → ユーザー・ストーリー → タスク（スプリント・バックログ）
- 大きさ
-
プロジェクト・マネジメント
協業のための、- 行動規範
- 横断的コーディネーション（調整業務）
- 報告内容の統一、共通言語＆用語
- 作業時間ルール（コミュニケーション、コーディネーション）
- スクラムのスクラム（SoS）、ベロシティ（処理能力的な）、チーム間依存関係
-
プロセス
- リリース（単位の？）のキックオフ（３ヶ月計画）
- イテレーション計画（POとチームで策定）
- タスク・ボード（カンバン）
- 総合テスト（リリース列車）
- プロダクト・レビュー
- レトロスペクティブ
-
発注側と受注側の契約
-
日本
- 発注側と受注側で評価基準が異なる。
- 請負、準委任、派遣などの形態。
-
形態
-
協業
- 成果物を顧客が評価
- 評価結果から計画策定
- 追加要求は次イテレーション
-
柔軟性
- 変更要求 ≒ フィーチャー
- スコープは可変（初期スコープ ～ 最終スコープ）
- 環境変化に依ってスケジューリングする
-
増分開発
- イテレーション毎の納品
- 増分（や変更）がなくなったらPJ終了
- （スコープの）コスト総額は事前に見積もれない。
-
-
異文化圏
契約をリスクと捉える。-
暗黙知を100%の形式知へ
-
見積もりには不確実性のコーンがある事を認識する。
- 見積もり前提条件の変化の可能性
- 発注のために低く見積もる傾向
- 受注のために高く見積もる傾向
- コンペでは低く見積もる傾向
-
コミュニケーション・リスク
- 送信者・受信者モデル（送信者・受信者の責任）
- 顧客の真の要求を引出し理解する。
-
-
フレームワーク
-
６つのプリンシプル
-
価値による優先順位
事業価値、狩野分析、ユーザ・ストーリーに疑似紙幣を分配 -
協業
明瞭、気付き、充当 -
タイムボックス
・スプリント計画
・スタンドアップ会議、スプリント
・レビュー、レトロスペクティブ -
反復開発
立ち上げ → スプリントｎ → リリース（増分開発） -
自己組織化
自律型チームの構成（オーナーシップ）
・リーダーシップ・スタイル（PMP：役割の該当節、サーバント・リーダーシップ）
・コンフリクト・マネジメント（PMP：共通の該当節）
・タックマン・モデル（PMP：チーム・マネジメントの該当節）
・マズローの欲求５段階説（PMP：チーム・マネジメントの該当節）
・マクレガーのXY理論（PMP：チーム・マネジメントの該当節） -
経験を積み重ねるプロセス管理
透明性、検査、適応（プロセス改善）
-
-
５つの視点
-
組織
・プロダクト・オーナー（プロダクト・バックログの定義）
・スクラム・マスター（サーバント・リーダーシップ）
・スクラム・チーム（プロジェクト成果物の作成） -
ビジネス正当性
・ビジネス・ケース
・アーンド・バリュー（EV）
・累積フロー図（CFD）
・その他の決定要素
・価値駆動型開発 -
品質
・定義（ビジネス価値、スコープ、性能、機能、バグ）
・受け入れ基準（ユーザ・ストーリー毎に妥当性確認）
・計画、実行、監視・制御
・PDCA → PDSA（CheckからStudyに） -
変更
・積極的対応（変更要求 ≒ フィーチャー、スプリントへ）
・柔軟性と安定性（スプリント・バックログを固定化）のバランス -
リスク
・脅威と好機（PMP：試験 - 計画の該当節）への継続的対応
（好機の重要度が高い）
・リスク態度（PMP：計画 - リスクの該当節、ステークホルダー分析）
・リスク・マネジメント
・通常のリスク・マネジメント（PMP：共通の該当節）
・プロダクト・バックログに入れ、
リスク・バーンダウン・チャートで管理
-
-
５フェーズ・１９プロセス
ココの内容は入門 > 手法（スクラム）に近い。-
立ち上げ
・プロジェクト・ビジョン作成
・スクラム・マスターとステークホルダー識別
・スクラム・チーム結成
・エピック開発（アプリから得られる体験的な）
・優先順位付きのプロダクト・バックログ作成
・リリース計画の主導 -
計画と見積
・ユーザー・ストーリー作成
・見積を承認し、ユーザー・ストーリーをコミット
・タスク作成
・タスク見積
・スプリント・バックログ作成 -
実行
・成果物の作成
・日次スタンドアップを主導（バーンダウン・チャート）
・優先順位付きプロダクト・バックログを遂行（グルーミング） -
レビューと振り返り
・スクラムチームのスクラムを招集
・スプリントをデモ
・スプリントを振り返る（KPT） -
リリース
・成果物を出荷する
・プロジェクトを振り返る
-
-
| ロール | スプリント計画ミーティング（初日） | デイリー・スクラム（朝会） | スプリント・レビュー（最終日の最初） | スプリント・レトロスペクティブ（最終日の最後） | プロダクト・バックログ・リファインメント（最終日の最後） |
|---|---|---|---|---|---|
| ステーク・ホルダー | △ | △ | ◯ | △ | △ |
| プロダクト・オーナー(PO) | ◎ | △ | ◎ | ◎ | ◯ |
| スクラム・マスター | ◎ | ◎ | ◎ | ◎ | ◎ |
| 開発チーム | ◎ | ◎ | ◎ | ◎ | ◎ |
着手可能な状態
- PO
- 価値・必要性の説明
- 受け入れ条件の説明
※ プロダクト・バックログ：ユーザー・ストーリー → タスク
「Ｘ」（誰）が「Ｙ」と言う理由で「Ｚ」したい。
-
スクラムマスタ
- 必要なリソース類の準備
-
開発者
- 見積もり
- ストーリー・ポイントを決定
-
= ストーリー・ポイント / スプリント
-
初期ベロシティ
- 過去実績
- １回やる
- 予想する
-
PMBOK 7版の変更点（
PMP：変更点の該当節）
- SCRUM BOOT CAMP THE BOOK
- エッセンシャル スクラム
移行メモ
- 元 Wiki で見出しそのものが他ページ・同ページ内へのリンクになっていた箇所は、 GitHub Wiki では見出しからアンカが生成されるため、 見出しをプレーン・テキストとし、リンクは直下の本文に置いた。
- PukiWiki のページ内アンカ（
#xxxxxxxx）は GitHub Wiki では再現できないため、 同一ページ内のアンカは見出しから生成されるアンカに張り替え、 他ページのアンカを指すリンクは「〜（ページ名の該当節を参照）」の形に置き換えた。- 元 Wiki の赤字強調は太字にした。
- KPT の表は元 Wiki ではセル結合（
~）を使っていたが、GitHub Wiki では セル結合を再現できないため、箇条書きに展開した。 スクラムのイベント参加者の表は、末尾の見出しセルが 「プロダクト・バックログ・リファインメント（最終日」で切れていたため、 本文の記載に合わせて「（最終日の最後）」と補った。- 元 Wiki の「Redyな状態」→「Readyな状態」、「優先慎位付き」→「優先順位付き」、 「チーム感依存関係」→「チーム間依存関係」、「リクスの対応」→「リスクの対応」、 「価値駆動形開発」→「価値駆動型開発」に正した。 財務指標の「NPN」は「NPV（正味現在価値）」の誤記と判断し修正した。
Tags: 移行, 資格, PMP, PDU, アジャイル, スクラム, プロダクト・バックログ, スプリント, INVEST, カンバン, リーン
このWikiは「Open棟梁Project」,「OSSコンソーシアム 開発基盤部会」によって運営されています。