![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
「[[.NET 開発基盤部会 Wiki>http://dotnetdevelopmentinfrastructure.osscons.jp]]」は、「[[Open棟梁Project>https://github.com/OpenTouryoProject/]]」,「[[OSSコンソーシアム .NET開発基盤部会>https://www.osscons.jp/dotNetDevelopmentInfrastructure/]]」によって運営されています。 -[[戻る>PMP：PDU]] --[[PMセミナー>PMP：PDU - PMセミナー]] --[[PMプラクティス>PMP：PDU - PMプラクティス]] --[[PMセミナー>PMP：PDU - PMセミナー]] --[[PMコンピテンシー>PMP：PDU - コンピテンシー]] --アジャイル関連 --[[組織的PM（OPM）>PMP：共通 - 組織的プロジェクト・マネジメント（OPM）]] *目次 [#b8b042bc] #contents *概要 [#q149a690] -[[PMPで言う適応型のライフサイクル区分>PMP：共通#vceb805c]] -採用プロジェクト比率が年々増加している...何故か？ --ビジネス領域の変化 ---ニーズの変化が早いビジネス領域 ---ニーズの不確実性が高いビジネス領域 --ITに対する期待の領域が広がってきている~ （→ [[DX：企業がITを利用して事業の業績や対象範囲を根底から変化させる>DXのポイント]]）。 ---顧客獲得 ---売上の増加 ---満足度向上 --システム開発の効率化、スピード化を推進 *詳細 [#e22b4ee5] **入門 [#n025fe38] ***[[特徴・比較>#hfbb6689]] [#b89c4a44] ***宣言・原則 [#a4e8d477] -アジャイルソフトウェア開発宣言~ http://agilemanifesto.org/iso/ja/manifesto.html -アジャイル宣言の背後にある原則~ http://agilemanifesto.org/iso/ja/principles.html ***低減されるリスク [#t4d0131a] -ユーザのニーズ・要求からの乖離 -完全なプロジェクトの失敗 -リリース（移行）の失敗 -作業未習熟に起因する失敗 -過剰な機能の盛り込み ***手法（スクラム） [#pbea2606] 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 ***適用指針 [#b9bb906e] -スコープ、スケジュール、コスト、品質について、 --ウォーターフォール開発は「コスト」変動、その他は固定~ SoR開発案件を請負、準委任で契約する場合 --アジャイル開発は「スコープ」変動、その他は固定~ 順次リリースするSoE開発案件を準委任、派遣で契約する場合（もしくは内製 -リスク検討チェックシートの活用 --カテゴリ --判断項目 --重要度 --ウォーターフォールが適する --アジャイルが適する。 ***マネジメント [#i5a2ac90] 見積・進捗・品質 -ベロシティ（処理能力的な）が見積・進捗に影響。 --故にベロシティに幅を持たせておく。 --80％ ～ 100％ ～ 120％のパターン -見積 --工数 ---PBIのポイント ---チームのベロシティ ---バーンダウン・チャート~ （ポイント・ベロシティの再見積） --スコープ ---予算 / 単位スプリントあたりの費用 = 実行可能なスプリント回数 ---実行可能なスプリント回数で消化できるPBIがスコープ -進捗 --リリース・バーンダウン・チャート~ 予実（スプリント毎にプロダクト・バックログの残ポイント量）を確認。 -品質 --ソーシャルコーディング や ペアプログラミング --テスト自動化、CI / CD、DevOpsを可能な限り自動化 --リリース・スプリント（リリース専用スプリント）を設ける。 --テスタ（QAなど）によるテスト（探針テスト）を行う。 ***アンチパターン [#ab4d075b] 主に上司の介入 -自己組織化の妨げ --上司が決定する --開発チームの決定を上司が覆す -上司に依る --タスクの割り当て --メンバの能力を定量化・可視化 ※ アジャイルは上司の介入がなくてもワークする。~ ※ 従って、上司は進捗を妨げる障害を除去する方が良い。~ ※ （全体最適化しないため）個人ではなくチームとして評価。~ ※ どうしてもと言うならメンバとして上司が参画する（のはOK）。 ***プラクティス [#g5308351] -PBIのINVEST --Independent~ 依存関係がなく独立している。 --Negotiable~ 手段については交渉可能である。 --Valuable~ そもそも顧客にとって価値がある。 --Estimatable~ 見積もり可能である。 --Small (Size Right)~ １スプリントで完了できるサイズ --Testable~ テストのチェック条件・確認項目が設定可能 -インセプションデッキ --アジャイルにおけるプロジェクト憲章 --以下の10個の質問についてチームで話し合う > +我々はなぜここにいるのか +エレベータピッチ +パッケージデザイン +やらないことリスト +プロジェクトのコミュニティ +技術的な解決策の概要 +夜も眠れなくなるような問題 +期限を見極める +トレードオフ・スライダー +初回リリースに必要なもの **効用 [#zcd67744] ***集合 [#of75ff3f] リーン -カンバン -アジャイル --DSDM --XP --FDD --ASD --スクラム --スクラムバン --クリスタル ***特徴 [#hfbb6689] 参考：[[PMP > 歴史>PMP#ya4ab894]] -&color(red){予測型};~ [[ウォーターフォール>PMP：共通#vceb805c]] -&color(red){反復型、漸進型};~ [[スパイラル>PMP：共通#vceb805c]] -&color(red){適応型}; --リーン~ トヨタ生産方式を手本に７つの無駄を削除 --カンバン~ 現場の可視化のためにカンバンを利用（以下のリスト ---ユーザー・ストーリー ---カンバン~ ・作業待~ ・作業中~ ・テスト中~ ・完了~ --DSDM~ ステークホルダーに焦点を当てる方法 --XP ---変化を抱擁（顧客第一、変更の予定） ---開発のベストプラクティス（ペアプロ、TDD等） ---開発サイクルを反復（タイムボックス、イテレーション） --FDD~ 成果物をユーザ視点でモデル化する手法 ---機能単位で開発（２週間単位の規模） ---Domain Object Modeling（DOM）の採用 --スクラム~ [[マネジメントのフレームワーク>#zff5c214]] ***導入 [#d7e521a0] -新しいPMのリーダーシップ・スタイル、革命 -革命（チェンジ：何を → どうやって → 何に） --マーケティング、コミュニティ、問題領域の発見、しがみつく（？) --仲間を作る、成功させる、結果を宣伝する、チーム評価 --上位マネジメント、中間管理職、PMO、施設、財務、調達 -ビジネス・ケース作成 --ポイント ---専門家の知恵を借りる ---投資効果の明確化~ 財務指標：ROI、NPN、PP、IRR --手順 ---ビジョン記述 → ビジネス提案 ---財務的ビジネス・ケース（ROI、NPN、PP、IRR ---組織的影響（抵抗と克服、リクスの対応） -ポイント --手法の選択 --小さくか、ビッグバンか --公にするかどうか --トレーニング、コーチング --リーダーシップ（サーバント・リーダーシップ --エンジニアリングの実務（現場の声） -大規模化~ 規模に関する４テーマ --組織 ---プロダクト・オーナー（PO） ---複数チーム（専任/兼務、統合/分散、PMO） ---経験と知識の共有（ナレッジ（KM,KB）、コミュニケーション） --プロダクト・バックログ ---大きさ~ プロダクト → エピック → フィーチャー → ユーザー・ストーリー → タスク ---作業分担~ プロダクト → ユーザー・ストーリー → タスク（スプリント・バックログ --プロジェクト・マネジメント 協業のための、 ---行動規範 ---横断的コーディネーション（調整業務） ---報告内容の統一、共通言語＆用語 ---作業時間ルール（コミュニケーション、コーディネーション） ---スクラムのスクラム（SoS）、ベロシティ（処理能力的な）、チーム感依存関係 --プロセス ---リリース（単位の？）のキックオフ（３ヶ月計画） ---イテレーション計画（POとチームで策定） ---タスク・ボード（カンバン） ---総合テスト（リリース列車） ---プロダクト・レビュー ---レトロスペクティブ ***契約 [#w8f67087] 発注側と受注側の契約 -日本 --発注側と受注側で評価基準が異なる。 --請負、準委任、派遣などの形態。 -形態 --協業 ---成果物を顧客が評価 ---評価結果から計画策定 ---追加要求は次イテレーション --柔軟性 ---変更要求 ≒ フィーチャー ---スコープは可変（初期スコープ ～ 最終スコープ） ---環境変化に依ってスケジューリングする --増分開発 ---イテレーション毎の納品 ---増分（や変更）がなくなったらPJ終了 ---（スコープの）コスト総額は事前に見積もれない。 -異文化圏~ 契約をリスクと捉える。 --暗黙知を100%の形式知へ --見積もりには不確実性のコーンがある事を認識する。 ---見積もり前提条件の変化の可能性 ---発注のために低く見積もる傾向 ---受注のために高く見積もる傾向 ---コンペでは低く見積もる傾向 --コミュニケーション・リスク ---送信者・受信者モデル（送信者・受信者の責任） ---顧客の真の要求を引出し理解する。 ***プロセス [#zff5c214] -フレームワーク --６つのプリンシプル ---価値による優先順位~ 事業価値、狩野分析、ユーザ・ストーリーに疑似紙幣を分配 ---協業~ 明瞭、気付き、充当 ---タイムボックス~ ・スプリント計画~ ・スタンドアップ会議、スプリント~ ・レビュー、レトロスペクティブ ---反復開発~ 立ち上げ → スプリントｎ → リリース（増分開発） ---自己組織化~ 自律型チームの構成（オーナーシップ）~ ・[[リーダーシップ・スタイル>PMP：役割#ua0fd067]]（サーバント・リーダーシップ~ ・[[コンフリクト・マネジメント>PMP：共通#c2ddc44e]]~ ・[[タックマン・モデル>PMP：チーム・マネジメント#hb8d4c8d]]~ ・[[マズローの欲求５段階説>PMP：チーム・マネジメント#f8811438]]~ ・[[マクレガーのXY理論>PMP：チーム・マネジメント#a90d8896]] ---経験を積み重ねるプロセス管理~ 透明性、検査、適応（プロセス改善） --５つの視点 ---組織~ ・プロダクト・オーナー（プロダクト・バックログの定義）~ ・スクラム・マスター（サーバント・リーダーシップ）~ ・スクラム・チーム（プロジェクト成果物の作成） ---ビジネス正当性~ ・[[ビジネス・ケース>#d7e521a0]]~ ・[[アーンド・バリュー（EV）>PMP：アーンド・バリュー（EV）]]~ ・累積フロー図（CFD）~ ・その他の決定要素~ ・価値駆動形開発 ---品質~ ・定義（ビジネス価値、スコープ、性能、機能、バグ）~ ・受け入れ基準（ユーザ・ストーリー毎に妥当性確認）~ ・計画、実行、監視・制御~ ・PDCA → PDSA（CheckからStudyに） ---変更~ ・積極的対応（変更要求 ≒ フィーチャー、スプリントへ）~ ・柔軟性と安定性（スプリント・バックログを固定化）のバランス ---リスク~ ・[[脅威と好機>PMP：試験 - 計画#me30ce56]]への継続的対応（好機の重要度が高い）~ ・[[リスク態度>PMP：計画 - リスク#x008212b]]（ステークホルダー分析）~ ・リスク・マネジメント~ ・[[通常のリスク・マネジメント>PMP：共通#oa93a230]]~ ・プロダクト・バックログに入れ、~ リスク・バーンダウン・チャートで管理 --５フェーズ・１９プロセス~ ココの内容は[[入門 > 手法（スクラム）>#pbea2606]]に近い。 ---立ち上げ~ ・プロジェクト・ビジョン作成~ ・スクラム・マスターとステークホルダー識別~ ・スクラム・チーム結成~ ・エピック開発（アプリから得られる体験的な）~ ・優先慎位付きのプロダクト・バックログ作成~ ・リリース計画の主導 ---計画と見積~ ・ユーザー・ストーリー作成~ ・見積を承認し、ユーザー・ストーリーをコミット~ ・タスク作成~ ・タスク見積~ ・スプリント・バックログ作成 ---実行~ ・成果物の作成~ ・日次スタンドアップを主導（バーンダウン・チャート）~ ・優先順位付きプロダクト・バックログを遂行（グルーミング） ---レビューと振り返り~ ・スクラムチームのスクラムを招集~ ・スプリントをデモ~ ・スプリントを振り返る（KPT） ---リリース~ ・成果物を出荷する~ ・プロジェクトを振り返る **スクラム [#d6195644] ***イベント参加者 [#q55eac63] |ロール|スプリント計画ミーティング（初日）|デイリー・スクラム（朝会）|スプリント・レビュー（最終日の最初）|スプリント・レトロスペクティブ（最終日の最後）|プロダクト・バックログ・リファインメント（最終日|h |ステーク・ホルダー|△|△|◯|△|△| |プロダクト・オーナー(PO)|◎|△|◎|◎|◯| |スクラム・マスター|◎|◎|◎|◎|◎| |開発チーム|◎|◎|◎|◎|◎| ***Redyな状態 [#w5496070] 着手可能な状態 -PO --価値・必要性の説明 --受け入れ条件の説明 >※ プロダクト・バックログ：ユーザー・ストーリー → タスク~ 「Ｘ」（誰）が「Ｙ」と言う理由で「Ｚ」したい。 -スクラムマスタ --必要なリソース類の準備 -開発者 --見積もり ***プランニング・ポーカー [#u3c93df4] -ストーリー・ポイントを決定 ***ベロシティ [#w39a228e] - = ストーリー・ポイント / スプリント -初期ベロシティ --過去実績 --１回やる --予想する **[[PMBOK 7版の変更点>PMP：変更点#t2dab1cd]] [#m35e9e62] *参考 [#aec9a1a1] **書籍 [#i72d7beb] -SCRUM BOOT CAMP THE BOOK -エッセンシャル スクラム
