PMP：PDU - アジャイル関連 のバックアップ(No.10)

[ トップ ]   [ 新規 | 一覧 | 単語検索 | 最終更新 | ヘルプ ]

• バックアップ一覧
• 差分 を表示
• 現在との差分 を表示
• ソース を表示
• PMP：PDU - アジャイル関連 へ行く。
  • 1 (2022-06-15 (水) 18:31:44)
  • 2 (2022-06-15 (水) 21:30:15)
  • 3 (2022-06-15 (水) 22:22:48)
  • 4 (2022-06-16 (木) 16:55:46)
  • 5 (2022-07-22 (金) 13:56:16)
  • 6 (2022-07-22 (金) 16:33:38)
  • 7 (2022-08-26 (金) 14:36:14)
  • 8 (2022-09-20 (火) 14:14:26)
  • 9 (2022-10-14 (金) 13:20:58)
  • 10 (2022-10-15 (土) 03:35:50)

---

「.NET 開発基盤部会 Wiki」は、「Open棟梁Project」,「OSSコンソーシアム .NET開発基盤部会」によって運営されています。

• 戻る
  • PMプラクティス
  • PMセミナー
  • PMコンピテンシー
  • アジャイル関連
  • 組織的PM（OPM）

目次 †

概要 †

• 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	新規にチャレンジすること（Try
  解決すること（Problem

• プロダクト・バックログ・リファインメント（最終日の最後）
  プロダクト・バックログの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個の質問についてチームで話し合う

    1. 我々はなぜここにいるのか
    2. エレベータピッチ
    3. パッケージデザイン
    4. やらないことリスト
    5. プロジェクトのコミュニティ
    6. 技術的な解決策の概要
    7. 夜も眠れなくなるような問題
    8. 期限を見極める
    9. トレードオフ・スライダー
    10. 初回リリースに必要なもの

効用 †

集合 †

リーン

• カンバン

• アジャイル
  • DSDM
  • XP
  • FDD
  • ASD
  • スクラム
  • スクラムバン
  • クリスタル

特徴 †

参考：PMP > 歴史

• 予測型
  ウォーターフォール

• 反復型、漸進型
  スパイラル

• 適応型

• リーン
  トヨタ生産方式を手本に７つの無駄を削除

• カンバン
  現場の可視化のためにカンバンを利用（以下のリスト
  • ユーザー・ストーリー
  • カンバン
    ・作業待
    ・作業中
    ・テスト中
    ・完了
    

• DSDM
  ステークホルダーに焦点を当てる方法

• XP
  • 変化を抱擁（顧客第一、変更の予定）
  • 開発のベストプラクティス（ペアプロ、TDD等）
  • 開発サイクルを反復（タイムボックス、イテレーション）

• FDD
  成果物をユーザ視点でモデル化する手法
  • 機能単位で開発（２週間単位の規模）
  • Domain Object Modeling（DOM）の採用

• スクラム
  マネジメントのフレームワーク

導入 †

• 新しいPMのリーダーシップ・スタイル、革命

• 革命（チェンジ：何を → どうやって → 何に）
  • マーケティング、コミュニティ、問題領域の発見、しがみつく（？)
  • 仲間を作る、成功させる、結果を宣伝する、チーム評価
  • 上位マネジメント、中間管理職、PMO、施設、財務、調達

• ビジネス・ケース作成

• ポイント
  • 専門家の知恵を借りる
  • 投資効果の明確化
    財務指標：ROI、NPN、PP、IRR

• 手順
  • ビジョン記述 → ビジネス提案
  • 財務的ビジネス・ケース（ROI、NPN、PP、IRR
  • 組織的影響（抵抗と克服、リクスの対応）

• ポイント
  • 手法の選択
  • 小さくか、ビッグバンか
  • 公にするかどうか
  • トレーニング、コーチング
  • リーダーシップ（サーバント・リーダーシップ
  • エンジニアリングの実務（現場の声）

• 大規模化
  規模に関する４テーマ

• 組織
  • プロダクト・オーナー（PO）
  • 複数チーム（専任/兼務、統合/分散、PMO）
  • 経験と知識の共有（ナレッジ（KM,KB）、コミュニケーション）

• プロダクト・バックログ
  • 大きさ
    プロダクト → エピック → フィーチャー → ユーザー・ストーリー → タスク
  • 作業分担
    プロダクト → ユーザー・ストーリー → タスク（スプリント・バックログ 　
• プロジェクト・マネジメント 協業のための、
  • 行動規範
  • 横断的コーディネーション（調整業務）
  • 報告内容の統一、共通言語＆用語
  • 作業時間ルール（コミュニケーション、コーディネーション）
  • スクラムのスクラム（SoS）、ベロシティ（処理能力的な）、チーム感依存関係

• プロセス
  • リリース（単位の？）のキックオフ（３ヶ月計画）
  • イテレーション計画（POとチームで策定）
  • タスク・ボード（カンバン）
  • 総合テスト（リリース列車）
  • プロダクト・レビュー
  • レトロスペクティブ

契約 †

発注側と受注側の契約

• 日本
  • 発注側と受注側で評価基準が異なる。
  • 請負、準委任、派遣などの形態。

• 形態

• 協業
  • 成果物を顧客が評価
  • 評価結果から計画策定
  • 追加要求は次イテレーション

• 柔軟性
  • 変更要求 ≒ フィーチャー
  • スコープは可変（初期スコープ ～ 最終スコープ）
  • 環境変化に依ってスケジューリングする

• 増分開発
  • イテレーション毎の納品
  • 増分（や変更）がなくなったらPJ終了
  • （スコープの）コスト総額は事前に見積もれない。

• 異文化圏
  契約をリスクと捉える。

• 暗黙知を100%の形式知へ

• 見積もりには不確実性のコーンがある事を認識する。
  • 見積もり前提条件の変化の可能性
  • 発注のために低く見積もる傾向
  • 受注のために高く見積もる傾向
  • コンペでは低く見積もる傾向

• コミュニケーション・リスク
  • 送信者・受信者モデル（送信者・受信者の責任）
  • 顧客の真の要求を引出し理解する。

プロセス †

• フレームワーク

• ６つのプリンシプル

• 価値による優先順位
  事業価値、狩野分析、ユーザ・ストーリーに疑似紙幣を分配

• 協業
  明瞭、気付き、充当

• タイムボックス
  ・スプリント計画
  ・スタンドアップ会議、スプリント
  ・レビュー、レトロスペクティブ

• 反復開発
  立ち上げ → スプリントｎ → リリース（増分開発）

• 自己組織化
  自律型チームの構成（オーナーシップ）
  ・リーダーシップ・スタイル（サーバント・リーダーシップ
  ・コンフリクト・マネジメント
  ・タックマン・モデル
  ・マズローの欲求５段階説
  ・マクレガーのXY理論

• 経験を積み重ねるプロセス管理
  透明性、検査、適応（プロセス改善）

• ５つの視点

• 組織
  ・プロダクト・オーナー（プロダクト・バックログの定義）
  ・スクラム・マスター（サーバント・リーダーシップ）
  ・スクラム・チーム（プロジェクト成果物の作成）

• ビジネス正当性
  ・ビジネス・ケース
  ・アーンド・バリュー（EV）
  ・累積フロー図（CFD）
  ・その他の決定要素
  ・価値駆動形開発

• 品質
  ・定義（ビジネス価値、スコープ、性能、機能、バグ）
  ・受け入れ基準（ユーザ・ストーリー毎に妥当性確認）
  ・計画、実行、監視・制御
  ・PDCA → PDSA（CheckからStudyに）

• 変更
  ・積極的対応（変更要求 ≒ フィーチャー、スプリントへ）
  ・柔軟性と安定性（スプリント・バックログを固定化）のバランス

• リスク
  ・脅威と好機への継続的対応（好機の重要度が高い）
  ・リスク態度（ステークホルダー分析）
  ・リスク・マネジメント
  　・通常のリスク・マネジメント
  　・プロダクト・バックログに入れ、
  　　リスク・バーンダウン・チャートで管理

• ５フェーズ・１９プロセス
  ココの内容は入門 > 手法（スクラム）に近い。

• 立ち上げ
  ・プロジェクト・ビジョン作成
  ・スクラム・マスターとステークホルダー識別
  ・スクラム・チーム結成
  ・エピック開発（アプリから得られる体験的な）
  ・優先慎位付きのプロダクト・バックログ作成
  ・リリース計画の主導

• 計画と見積
  ・ユーザー・ストーリー作成
  ・見積を承認し、ユーザー・ストーリーをコミット
  ・タスク作成
  ・タスク見積
  ・スプリント・バックログ作成

• 実行
  ・成果物の作成
  ・日次スタンドアップを主導（バーンダウン・チャート）
  ・優先順位付きプロダクト・バックログを遂行（グルーミング）

• レビューと振り返り
  ・スクラムチームのスクラムを招集
  ・スプリントをデモ
  ・スプリントを振り返る（KPT）

• リリース
  ・成果物を出荷する
  ・プロジェクトを振り返る

スクラム †

イベント参加者 †

Redyな状態 †

着手可能な状態

• PO
  • 価値・必要性の説明
  • 受け入れ条件の説明

※ プロダクト・バックログ：ユーザー・ストーリー → タスク
　「Ｘ」（誰）が「Ｙ」と言う理由で「Ｚ」したい。

• スクラムマスタ
  • 必要なリソース類の準備

• 開発者
  • 見積もり

プランニング・ポーカー †

• ストーリー・ポイントを決定

ベロシティ †

• = ストーリー・ポイント / スプリント

• 初期ベロシティ
  • 過去実績
  • １回やる
  • 予想する

PMBOK 7版の変更点 †

参考 †

書籍 †

• SCRUM BOOT CAMP THE BOOK
• エッセンシャル スクラム

     

Site admin: TechInfoOfMicrosoftTech

PukiWiki 1.4.7 Copyright © 2001-2006 PukiWiki Developers Team. License is GPL.
Based on "PukiWiki" 1.3 by yu-ji. Powered by PHP 5.3.3. HTML convert time: 0.058 sec.