運用環境または継続的な環境で段階的に製品を開発するプロジェクト

比較的類似した規模または作業範囲のプロジェクト

サイズや範囲に応じてタスクをグループ化できるプロジェクト

これは、アジャイル開発モデルで要件をアジャイルにする重要な手段です。

独立した、議論可能な、価値のある、推定可能な、小規模な、テスト可能な

ソフトウェア開発プロセスにおける要件を記述する形式として使用され、役割（誰がこの機能を必要とするか）、機能（どのような機能が必要か）、および価値（なぜこの機能が必要なのか、この機能がどのような価値を提供できるのか）を記述することに重点を置いています。持ってくる）

ユーザーがドキュメントを編集したい場合、ユーザーが 15 分以内にドキュメントを保存しない場合、データの損失を避けるためにドキュメントは自動的に保存されます。

範囲がどのように定義および開発されるかを説明し、スケ​​ジュールを作成する方法に関する情報を提供する

スケジュール方法、見積もり手法、スケジュール ツール、およびスケジュールの制御に使用される手法の定義に役立ちます。

参加者には、プロジェクト マネージャー、プロジェクト スポンサー、プロジェクト チーム メンバー、選択された利害関係者、スケジュールまたは実行のリーダー、およびその他の必要な担当者が含まれる場合があります。

これはプロジェクト管理計画の不可欠な部分であり、プロジェクトの進行の準備、監督、管理のための基準と明確な活動要件を確立します。

公式でも非公式でも、非常に詳細なものでも非常に一般的なものでも構いません

1. プロジェクトスケジュールモデル

2. リリースとイテレーションのスケジュールの長さ

3. 正確さ

4. 測定の単位

5. 作業分解構造 (WBS)

6. プロジェクトスケジュールモデルのメンテナンス

7. 制御閾値

8. パフォーマンス測定ルール

9. レポート形式

スケジュールのアプローチ、ローリング計画の期間、作業の管理に必要な詳細レベルを定義します。

アクティビティを定義するときは、プロジェクトの WBS、成果物、制約、スコープ ベースラインの前提条件を明示的に考慮します。

プロジェクトの範囲とプロジェクトの成果物を、より小さく管理しやすいコンポーネントに段階的に分割する手法

最小の成果物である WBS 出力 (分解) 作業パッケージを作成します。

より高いレベルで将来の作業を大まかに計画しながら、近い将来に実行する作業を詳細に計画する反復計画手法

これは、作業パッケージや計画パッケージに適した、進歩的で詳細な計画方法です。

プロジェクト チームのメンバーが何を完了する必要があるかを把握できるように、各アクティビティの識別と作業範囲の詳細な説明を含む、プロジェクトに必要な進捗アクティビティが含まれます。

ローリング プランニングまたはアジャイル手法を使用するプロジェクトの場合、アクティビティ リストは プロジェクトの進行に合わせて定期的に最新情報を入手する

各アクティビティの複数の属性を指します。アクティビティの説明を拡張するために使用されます。アクティビティ属性は、プロジェクトの進行とともに進化および更新されます。

アクティビティ属性には、一意のアクティビティ ID (ID)、WBS ID、アクティビティ ラベルまたは名前が含まれます。

アクティビティ属性には、アクティビティの説明、先行アクティビティ、後続アクティビティ、論理関係、リードとラグ、リソース要件、必須の日付、制約、および仮定が含まれる場合があります。

1. 作業が行われる場所を特定する

2. 活動および関連する活動タイプを実行するためのプロジェクト カレンダーを準備する

3. 進捗計画の準備

4. スケジュールアクティビティは、アクティビティ属性に基づいてさまざまな方法でレポート内で選択、並べ替え、分類できます。

意味

1 つの重要な時点またはイベントのみを表すため、期間はゼロになります。

すべてのプロジェクトのマイルストーンをリストし、各マイルストーンが必須（契約で義務付けられているなど）なのか、オプション（履歴情報に基づいて決定されているなど）なのかを示します。

プロジェクト全体を通じて、作業パッケージは徐々にアクティビティに洗練されます。このプロセス中に、もともとプロジェクトのベースラインの一部ではなかった作業を追加する必要があることが判明し、納期やその他の重要なスケジュールのマイルストーンを変更する必要があることが判明する場合があります。

スケジュールアクティビティの変更が承認された後、コストベースラインにも対応する変更を加える必要があります。

シーケンスアクティビティの方法と精度、および必要なその他の基準を指定します。

アクティビティの順序を決めるときは、プロジェクトの WBS、成果物、制約、ベンチマークの前提条件を明示的に考慮する必要があります。

仮説ログ

アクティビティのプロパティ

アクティビティリスト

マイルストーンリスト

進捗モデルを作成するためのテクニックです

シングルコードネットワーク図

1. フィニッシュからスタート (FS)

2. 完了から完了まで(FF)

3. スタートトゥスタート(SS)

4. 開始から終了まで (SF)

当面の活動

フォローアップ活動

各アクティビティには一意のアクティビティ番号があり、各アクティビティには推定期間 (アクティビティの継続時間) があります。

時間タイプ

アクティブ オン ザ アロー (AOA) としても知られています。

アクティビティを表すには矢印を使用し、イベントを表すにはノードを使用します。ノードと矢印の両方に番号を付ける必要があります。

1. ネットワーク ダイアグラム内の各アクティビティとイベントには一意のコード名が必要です。つまり、ネットワーク ダイアグラム内に同じコード名は存在せず、コード番号は小さいものから大きいものまで示されます (例: 1 は 2 を指し、C は C を指します)。 Dを指しています）

2. 任意の 2 つのアクティビティの前のイベントと後続のイベントのコードの少なくとも一方が異なり、ノード コードは矢印に沿ってどんどん大きくなります。

3. 同じノードに流入する (または流出する) アクティビティには、共通の後続アクティビティ (または先行アクティビティ) があります。

意味

時間やリソースを消費せず、アクティビティの依存関係を表現する際のアロー ダイアグラムの欠点を補うだけです。

仮想アクティビティを使用すると、アクティビティ間の関係をより適切かつ明確に表現できるようになります。

1. 必須の依存関係

2. 選択的な依存関係

3. 外部依存関係

4. 内部依存関係

これは、後続アクティビティを先行アクティビティと比較して進めることができる時間であり、通常は負の値で表されます。

例: 新しいオフィスビルの建設プロジェクトでは、造園部門は最終作業リストが完成する 2 週間前に開始できます。 造園部門の開始時間 = 最終作業リスト作成の終了時間 - 2 週間

これは、後続アクティビティを先行アクティビティと比較して延期する必要がある時間であり、通常は正の値で表されます。

例: 大規模な技術文書の場合、執筆チームは執筆作業の開始から 15 日後にドラフト文書の編集を開始できます。 原稿執筆開始時刻 = 原稿執筆開始時刻 15 日

プロジェクトのスケジュールアクティビティ間の論理関係（依存関係）を表すグラフです。

収束と分岐のあるアクティビティは複数のアクティビティに影響を受ける、または影響を与える可能性があるため、より大きなリスクが生じます。

これは、イベント間の必然的な順序や決定された即時またはその後の関係、および進み量と遅れ量とアクティビティの間の定義された論理関係を記述する場合があります。

アクティビティを順序付けする場合、アクティビティ リストはプロジェクトのアクティビティ関係の変更によって影響を受ける可能性があります

アクティビティの順序、関係の特定、進みと遅れの量によっては、仮定ログ内の仮定と制約を更新する必要があり、プロジェクトのスケジュールに影響を与えるリスクが生じる可能性があります。

アクティビティの順序を決定する場合、特定のマイルストーンの計画達成日は、プロジェクトのアクティビティの関係の変化によって影響を受ける可能性があります。

他の要素を一定に保ち、出力単位あたりに必要な入力を決定するために使用される要素 (リソースなど) を追加すると、最終的に臨界点に達し、その後、要素が追加されるにつれて出力または出力が増加します。

リソースの数を増やしても、たとえばリソースを 2 倍にしても、必ずしも作業を完了する時間が半分に短縮されるわけではありません。リソースの投資により追加のリスクが追加される可能性があるためです。

アクティビティ リソースを追加しすぎると、知識の伝達、学習曲線、追加のコラボレーション、およびその他の関連要因により、時間が長くなる可能性があります。

技術進歩の要因は、期間の推定値を決定する際に重要な役割を果たす可能性があります。たとえば、製造施設は最新のテクノロジーを調達することで生産量を増やすことができ、それが期間やリソース要件に影響を与える可能性があります。

先延ばし

パーキンソンの法則

アクティビティの継続時間を推定するために使用される方法と精度、およびその他の必要な基準を指定します。

WBS と WBS 辞書が含まれており、後者には作業量と期間の見積もりに影響を与える可能性のある技術的な詳細が含まれています。

仮説ログ

教訓登録

アクティビティのプロパティ

アクティビティリスト

マイルストーンリスト

リスクレジスター

リソース要件

リソースの内訳構造

リソースカレンダー

プロジェクト チームが作業指示書を発送します

類似の活動またはプロジェクトの履歴データを使用して、現在の活動またはプロジェクトの期間またはコストを見積もる手法

プロジェクトの複雑さの既知の違いに合わせて調整する必要がある大まかな見積もり方法。プロジェクトの詳細が不十分な場合、プロジェクトの期間を見積もるためによく使用されます。

他の推定手法と比較して、アナログ推定手法は一般に安価で時間もかかりませんが、精度も低くなります。

アルゴリズムを使用して、履歴データとプロジェクト パラメーターに基づいてコストまたは期間を計算する見積もり手法。

パラメトリック モデルの成熟度と基礎となるデータの信頼性に依存します

1. オプティミスティックタイム (TO)

2. 最も可能性の高い時間 (TM)

3. 悲観的時間 (TP)

3 つの推定値が三角分布に従う場合

3 つの推定値がベータ分布に従う場合

結果は切り上げられます。例: 8.5 日、結果は 9 日に切り上げられます。

WBS コンポーネントからの見積もりを下から上にレイヤーごとに集計することによって、プロジェクトの期間またはコストを見積もる方法。

さまざまなリソースの機能やスキル レベルの比較、圧縮手法、さまざまなツール (手動および自動) のスケジュール、およびリソースの作成、リース、購入に関する決定に使用されます。

緊急時準備金

管理予備金

アジャイルプロジェクトに適した挙手投票方式を導き出した

アクティビティ、フェーズ、またはプロジェクトを完了するために必要な作業時間数の定量的評価。遅延は含まれませんが、変動の範囲を示す場合があります。

期間の見積もりに必要なサポート情報

期間の見積もりがどのようにして得られたのかについて、明確かつ完全な説明を提供します。

1. 見積もりの​​根拠の文書化 (例: 見積もりの​​作成方法)

2. すべての仮定の文書化

3. 既知の制約に関するドキュメント

4. 予想される期間がどこに該当するかを示す推定間隔の説明 (例: 「±10%」)

5. 最終推定値の信頼レベルの説明

6. 見積り等に影響を与える個別プロジェクトのリスクに関する文書化

このプロセスによって出力されるアクティビティ所要時間の推定値は、アクティビティのプロパティに記録されます。

仮定ログを更新するときは、スケジュール方法やスケジュール ツールによって課される制約に加えて、期間を見積もるために作成された仮定を含めます。

工数や期間を効果的かつ効率的に見積もる技術の追加が可能

プロジェクト管理チームは、クリティカル パスやアジャイル手法などのスケジュール方法を選択します。

プロジェクト管理チームは、プロジェクト固有のデータ (アクティビティ、計画日、期間、リソース、依存関係、制約など) をスケジュール ツールに入力して、プロジェクト スケジュール モデルを作成します。

ソート可能

1. プロジェクトのマイルストーンを定義し、アクティビティを特定して順序付けし、期間を見積もり、アクティビティの開始日と終了日を決定します。

2. 各アクティビティに割り当てられたプロジェクト担当者による、割り当てられたアクティビティのレビュー

3. プロジェクト スタッフは、開始日と終了日がリソース カレンダーや他のプロジェクトやタスクと競合しないことを確認することで、計画日の妥当性を確認します。

4. スケジュールを分析して、スケジュールを承認してベースラインとして使用する前に、論理関係の矛盾があるかどうか、リソースのバランスをとる必要があるかどうかを判断し、同時にプロジェクトのスケジュール モデルを修正して維持し、プロジェクト期間を通じてスケジュールが常に実行可能であることを確認します。

スケジュールの作成方法とスケジュールの作成に使用するツール、およびスケジュールを導出する方法を指定します。

スコープステートメント、WBS、および WBS ディクショナリには、プロジェクトの成果物に関する詳細情報が含まれており、スケジュール モデルを作成する際の参考として使用されます。

仮説ログ

教訓登録

アクティビティのプロパティ

アクティビティリスト

マイルストーンリスト

プロジェクト進捗ネットワーク図

推定根拠

期間の見積もり

プロジェクト チームが作業指示書を発送します

リソースカレンダー

リソース要件

リスクレジスター

複数のパスが同じ時点で収束または分岐する場合に、スケジュールに遅れが生じる可能性を減らすために進捗リザーブを集約する必要性を評価します。

ネットワークをレビューして、クリティカル パス上に高リスクのアクティビティやリードタイムの​​長いアクティビティが存在するかどうか、またクリティカル パスのリスクを軽減するためにスケジュールの予備を使用するかリスク対応計画を実施する必要があるかどうかを確認します。

プロジェクトの最小期間を見積もり、論理ネットワーク パスのスケジュールの柔軟性を決定します。

アクティビティの最早開始時刻 (ES) は、このアクティビティを直接指す最早終了時刻 (EF) の最も遅い時刻と同じか、それ以降である必要があります。

アクティビティの最新の終了時刻 (LF) は、それが直接指すすべてのアクティビティの最新の開始時刻 (LS) と同じか、それより前である必要があります。

前進演算（前押しの方が大きい）

ステップ

逆算（逆算して小さい方を求める）

ステップ

これはプロジェクト内で最も長い一連のアクティビティであり、可能な限り最短のプロジェクト期間を決定します。

通常、合計フロートはゼロです

意味

この期間内であれば、プロジェクトの期間に影響を与えることなく活動を遅らせることができます。

計算方法

意味

この期間内であれば、後続のアクティビティに影響を与えることなく、アクティビティを遅らせることができます。

計算方法

クリティカル パス (プロジェクト内の最も長い一連のアクティビティ、通常は合計浮動小数点が 0): A-B-F-G-H 1. E の最も早い開始時間 = D の最も早い終了時間 (30) 2. E の最も早い終了時間 = E の最も早い開始時間 (30) E の継続時間 (15) = 45 3. E の最も遅い完了時刻 = H の最も遅い開始時刻 (200) 4. E の最も遅い開始時間 = E の最も遅い終了時間 (200) – E の継続時間 (15) = 185 5. E の合計フロート時間 = E の最も遅い完了時間 (200) - E の最も早い完了時間 (45) = 155 6. C のフリーフロート = F の最も早い開始時間 (20) – C の最も早い終了時間 (15) = 5 7. 複数の先行アクティビティが存在する場合、アクティビティの最も早い開始時刻を計算します。 F の最も早い開始時間は、F のすべての先行アクティビティ (B、C) の最も早い完了時間の最大値、つまり B の最も早い完了時間です。 8. 複数のフォローアップ アクティビティが存在する場合、アクティビティの最新の完了時間を計算します。 B の最も遅い完了時刻は、B の後続のすべてのアクティビティ (D、F) の最も遅い開始時刻の最小値、つまり F の最も遅い開始時刻です。 9. フォローアップアクティビティが複数存在する場合、アクティビティのフリーフローティング時間 = フォローアップアクティビティの最も早い開始時間の最小値 - 現在のアクティビティの最も早い完了時間

リソースの需要と供給に基づいてスケジュールモデルを調整する技術です。

アクティビティの開始日と終了日を調整して、計画されたリソースの使用量が利用可能なリソース以下になるように調整することで、リソース負荷の問題を解決します。

リソースバランシング

リソースの平滑化

さまざまなシナリオを評価し、プロジェクト目標に対するその影響 (プラスまたはマイナス) を予測します。

What-If シナリオ分析の結果に基づいて、さまざまな条件下でのプロジェクト スケジュールの実現可能性を評価し、予期せぬ事態の影響に対処するためのスケジュールの予備と対応計画を作成します。

個々のプロジェクトのリスクとその他の不確実性源をモデル化し、プロジェクト目標に対する潜在的な影響を評価する方法

含む

一般的なテクニック

ネットワーク分析において、後続のアクティビティの開始時間を調整することで現実的なスケジュールを作成する調整手法です。

条件が許せば早期にフォローアップ活動を開始するために使用されます。

特定の制約の下で、先行アクティビティと後続アクティビティの間に、作業やリソースを必要としない自然時間を追加します (延期)

プロジェクトの範囲を縮小することなく、スケジュールの制約、必須の日付、またはその他のスケジュール目標を達成するために、スケジュール期間を短縮または加速します。

急ぎの仕事

素早いフォローアップ

各プロジェクト活動の完了時間は、3 つの異なるシナリオに従って推定されます。

プロジェクト全体の完了時間は各アクティビティの完了時間の合計であり、正規分布に従います。

入力

自動出力

スケジュールの準備プロセスをスピードアップできる

承認されたスケジュールモデルは、正式な変更管理プロセスを通じてのみ変更可能であり、実際の結果との比較の基礎として使用されます。

スケジュールは常に更新され (徐々に改善され)、複数のバージョンを持つことができます。

進捗ベースラインは、進捗計画の承認済みバージョンです。

これはスケジュール モデルの出力であり、相互に関連する各アクティビティに計画日、期間、マイルストーン、必要なリソースなどのラベルが付けられます。

納期を強調表示する

リスト

グラフィックス

真ん中の点線：チェックポイント 点線の左側の部分は青で塗りつぶされ、成都でのアクティビティが完了したことを示します 点線の右側の部分は色で塗りつぶされておらず、アクティビティの未完了部分を示しています

スケジュールを記述および制御するために使用される情報の集合です。

少なくとも含めてください

詳細

スケジュール管理計画を更新して、スケジュールの作成および管理方法の変更を反映します。

範囲、リソース、またはコスト見積もりの​​変更が承認された後、コスト ベースラインに対応する変更を加える必要があります。場合によっては、コストの逸脱が非常に大きいため、パフォーマンス測定の現実的な基準を提供するためにコスト ベースラインを修正する必要があることがあります。

スケジュールの作成に起因するリソース要件およびその他の関連コンテンツへの変更を反映します。

期間、リソースの使用状況、シーケンス、またはスケジュール モデルの作成時に検出されたその他の情報に関する仮定の変更を反映します。

リソースの量と可用性、およびアクティビティの依存関係により、所要時間の見積もりが変更される場合があります。

分析プロセス中にリソース要件が変更された場合は、それに応じてリソース要件を更新する必要があります。

スケジュールが予定より遅れてコストが超過する場合は、急いで作業すると確実にコストが増加するため、2-6 だけを書きます。

プログレスの更新頻度、プログレス保留の使い方、プログレスの制御方法について説明します。

進行状況のベースラインと実際の結果を比較して、変更や是正措置、予防措置が必要かどうかを判断します。

スケジュール ベースラインを監視するときは、プロジェクトの WBS、成果物、制約、スコープ ベースラインの前提条件を明示的に考慮します。

達成額分析を使用すると、パフォーマンス測定のベースラインが実際の結果と比較され、変更、是正措置、または予防措置が必要かどうかが判断されます。

教訓登録

プロジェクトスケジュール

進捗データ

プロジェクトカレンダー

リソースカレンダー

試験では計算問題をマスターする必要がある

スケジュール パフォーマンス測定値 (スケジュール差異 - SV やスケジュール パフォーマンス指数 - SPI など) は、初期スケジュール ベースラインからの逸脱を評価するために使用されます。

新しいコンセプト

イテレーションの未完了項目でまだ完了していない作業を追跡し、理想的なバーンダウン チャートからの逸脱を分析するために使用されます。

予測傾向線を使用して、反復の終了時に起こり得る逸脱や、反復中に取るべき合理的なアクションを予測できます。

スケジュールのベースライン（実際の開始日と終了日、完了率、現在の作業の残り期間など）に対するスケジュールのパフォーマンスを測定、比較、分析することを指します。

プロジェクトのパフォーマンスを長期的に調査して、パフォーマンスが向上しているか低下しているかを判断します。

計画からの実際の開始日と終了日の偏差、計画からの実際の期間の偏差、およびフロートの偏差に焦点を当てます。

プロジェクト リスク管理プロセスの出力に基づいてさまざまなシナリオを評価し、スケジュール モデルをプロジェクト管理計画および承認されたベースラインと一致させます。

プロジェクトの範囲、活動リソース、または活動期間の見積もりの​​変更を承認するには、スケジュールのベースラインの変更が必要になる場合があります

スケジュール圧縮技術やパフォーマンスの問題により変更が発生した場合にも、スケジュール ベースラインを更新する必要がある場合があります。

範囲、リソース、またはコスト見積もりの​​変更が承認された後、コストのベースラインにも対応する変更を加える必要があります。

範囲、スケジュールパフォーマンス、またはコスト見積もりの​​変更が承認された後、パフォーマンス測定ベースラインへの対応する変更が必要になります。

スケジュールのパフォーマンスにより、期間の見積もり方法を修正する必要があることが示される場合があります

更新されたスケジュール データをスケジュール モデルに置き換えて更新されたプロジェクト スケジュールを生成し、スケジュールの変更を反映してプロジェクトを効果的に管理します。

リソース カレンダーを更新して、リソースの最適化、スケジュールの圧縮、修正または予防措置によるリソース カレンダーの変更を反映します。

承認された残りの期間と承認されたスケジュールの変更を反映するために、プロジェクト スケジュール ネットワーク図の再描画が必要になる場合があります。

スケジュールのパフォーマンスは、アクティビティの順序、期間、生産性に関する前提を修正する必要があることを示している可能性があります。

スケジュール圧縮技術を使用すると、リスク登録とその中のリスク対応計画の更新が必要となるリスクが生じる可能性があります。

メンテナンスの進捗状況、逸脱の原因とスケジュールの逸脱に対応するための修正措置を記録するための効果的な手法