MS Projectを使用してソフトウェア開発プロジェクトを管理する

MS Projectを使用してソフトウェア開発プロジェクトを管理した経験を共有したいと思います。 私はプロジェクト管理に10年間携わっており、

その結果、MS Projectを使用するための方法論を思い付きました。これにより、MS Projectから大きな利益を得ることができ、同時にその欠点に依存することが少なくなりました。

小さな紹介

方法論全体は、プロジェクトマネージャーの適用されたタスクを解決するためにMS Projectを使用するための簡単な方法と推奨事項のセットにすぎません。 方法論は普遍的であると主張せず、ナレーションの過程で言及する特定の制限の下でのみ適用可能であることをすぐに言わなければなりません。



はじめに、プロジェクトマネージャーに通常何が必要かを思い出してみましょう。 経験豊富なマネージャーにとっては、これは明らかですが、初心者（またはリーダーになろうとしている）がもう一度覚えておくと便利です。 そのため、ソフトウェア開発プロジェクトは独自の製品を作成しています。 プロジェクトのライフサイクルのさまざまな段階で、RPはさまざまな問題を解決するために必要です。

プロジェクトの開始前

プロジェクトを開始する前に、プロジェクトマネージャーは通常2つの質問に答える必要があります。

1. プロジェクトの所要時間
2. プロジェクトにかかる費用

「6か月後以降」という形式の回答に興味がある人はいないことを理解することが重要です。 ちょうど最高の見積もりが必要です。

ご注意 プロジェクトの明示的な金銭的見積もりに対処する必要はありませんでしたが、現在理解しているように、これは重大な省略です。 私が管理したすべてのプロジェクトは、会社の従業員によって実行されました。 プロジェクトチームはプロジェクトの全期間に渡って結成され、一部の専門家は一定の期間関与していました。 実際、必要なパフォーマーの数と彼らが関与するタイミングを見積もる必要があります。 これは、ソフトウェア開発に関わる企業にとって非常に典型的な状況であるように思えます。 最終的には、すべて人件費の評価に帰着し、経験式を使用して、プロジェクトのコストの見積もりになります。 ご覧のとおり、プロジェクトのコストとそのタイミングには直接的な関係があります。

プロジェクトの過程で

上記の制限の条件では、プロジェクトマネージャーの主なタスクは、宣言された期間内にプロジェクトを確実に実装することです。

その値に影響します。 プロジェクトに必ず伴う不測の状況は、条件の遅延につながる可能性があります。 厳密に言えば、プロジェクトのスケジュールは予想外に短縮される可能性がありますが、正直なところ、私はそのようなことを見たことはありません。 リーダーは、負の結果を減らすために、こうしたイベントにタイムリーに対応する必要があります。 この問題を解決する唯一の方法は、正確な計画、差し迫った問題の定期的な監視、および計画の調整です。

プロジェクトの完了時に

プロジェクトが完了すると、マネージャーは通常、プロジェクトを振り返って要約します。 ほとんどの場合、計画されたスケジュールからプロジェクトがどれだけ抜けたか、なぜこれが起こったのかを評価する必要があります。

MS Projectでできること

外部の複雑さにもかかわらず、MS Projectはアイデアの点では非常に単純です。 彼は、タスク、リソース、カレンダー、およびそれらの間の関係という3つのエンティティで動作します。 基本的に、これは、データベース、エンティティを作成および編集するためのユーザーインターフェイス、および最小限の非常に単純な自動化です（入力されたデータに応じてProject自体が行うこと）。



エンティティのプロパティを簡単に分析してみましょう。



タスクには、期間、ボリューム、割り当てられたリソース、および多くのさまざまなプロパティがあります。 十分な組み込みプロパティがない場合は、独自のプロパティを追加できます。これは後で使用します。 タスクは、さまざまな関係（先行者、フォロワーなど）によって相互接続できます。



リソースには多くの説明的なプロパティがありますが、最も重要なことは、次のことができることです。

一定期間の可用性を設定します。これにはカレンダーが使用されます。 リソースは

タスクに割り当てられます。



このデータに基づいて、Projectは以下を使用してさまざまな表現を作成できます。

フィルター、グループ化、並べ替えなど さらに、彼はいくつかのアルゴリズムに従ってできる

割り当てられたリソースの可用性を考慮して、タスクの開始日と終了日を計算します

タスク間の接続。 実際、彼ができることはそれだけです。

これからどのように利益を得ることができるか見てみましょう。

使い方

注：より明確にするために、プロジェクトの一般的なプロパティをいくつか明確にし、

一緒に働いた人。 だから、私たちはソフトウェア開発プロジェクトについて話している、

これはいくつかの段階で構成されています。 各段階の終わりに、いくつかを取得する必要があります

目に見える結果が顧客に提示されるため、評価することが重要です

プロジェクト全体の用語だけでなく、各段階の用語。 繰り返しますが、唯一のリソースです

必要なのは人であり、外部の専門家を雇うのではなく、

既存の従業員の能力。

計画の準備

そのため、私たちの前に技術的なタスクがあり、次の3つの質問に答える必要があります。

1. このプロジェクトにはどれくらい時間がかかりますか？
2. これには何人の（そして何人の）専門家が必要ですか？
3. このプロジェクトに必要な人件費はどれくらいですか？

このため、MS Projectでのプロジェクト実施計画の準備を進めています。 つまり 完了する必要があるタスクを順番に書き出すだけです。 参照条件を一連のタスクに変換する手法は別の話であり、ここでは詳しく説明しません。

計画の準備は、いくつかの段階で実行されます。

1. タスクのリストを準備しています
2. タスク間の依存関係を公開します
   
   （次の問題に進むにはどのような問題が必要ですか？）。
   
   
3. タスク実行者の割り当て
   
   
4. リソースのロードの調整
   
   
5. 何が起こったのバランス
   
   

一般的な推奨事項

計画を準備する際、次の推奨事項を順守します。

1. 分解にはサマリータスクを使用しません。
   
   すべてのタスクを1つの線形リストに入れます。 最初は不快に思えるかもしれませんが、
   
   しかし、それは将来の多くの問題から救います。 タスクの構造を管理するには
   
   カスタムフィールドを使用します（以下を参照）。
   
   
2. 多くの場合、タスクの依存関係を管理するためにドラッグアンドドロップが使用されます。 多くのタスクがあると、すぐに不快になります。 この場合、ドラッグアンドドロップを使用せずに、先行タスクの数を明示的に示すことをお勧めします。 これを行うには、「先行」列をテーブルに追加し、タスク番号を手動で入力します。
   
   
3. 各タスクの期間は2週間を超えないようにしてください。
   
   タスクの期間が1週間を超える場合-これは、その分解について考える機会です。 私は非常に単純な評価方法論に従いました：原始的なタスク-2日間、平均
   
   困難-1週間、難しいタスク-2週間。 この場合、多くの複雑なタスクはありません。 このアプローチにより、評価計画をかなり迅速に準備することができます。
   
   一方で、得られた推定値は、もちろん正確ではありませんが、一方で、どれが正確ですか？ 実務経験から私はそれを言うことができます
   
   大規模なプロジェクトでは、通常、個々のタスクの推定値の誤差は平準化され、小規模なプロジェクトでは、より正確な推定値を使用することが可能です（そして必要です！）。
4. 必ず、複数のパフォーマーがいるタスクを避けます。 各タスクに割り当てられる実行者は1人だけです。 2人の出演者を任命するのは理にかなっています
   
   それらが実際に連携している場合のみです（たとえば、ペアプログラミングを練習している場合）。 その他の場合、タスクを分解することをお勧めします。
5. パフォーマーを任命するとき、負荷の均一性を心配することなく、彼らの職業と資格に導かれます。
6. サマリータスクを使用して、タスクをステージに分けます。 ステージ間に依存関係を配置して、それらが順番に進むようにします。 ステージへの分割は、まだかなり近似しています。

タスクのステップバイステップリスト

プロジェクトバランス

この手法で最も重要なことは、正確にバランスを取ることです。 このプロセスの目的は、作業が全体的にパフォーマー間でほぼ均等に分割される計画を準備することです。



計画の最初の準備の後、通常はプロジェクトではなく、完全な不名誉が得られます。 したがって、整理し始めます。 整理整頓とは、パフォーマーとディビジョンのアポイントメントを手動で段階的にバランスさせることです。 これを行うには、 エグゼキューターによるタスクのグループ化を使用して、タスクがどのように分解されたかを確認します。 見やすくするために、開始日でタスクを並べ替えることをお勧めします。





実行者によるタスクのグループ化



ご注意 理論的には、グラフを使用して負荷を評価する必要があります。

ユーザーのダウンロード。 これらのチャートは、上司が（おそらく）良いときに

完成したプロジェクトを評価します。 しかし、彼らが示すように、彼らは計画を作成する段階では不適切です

すべてが悪いことですが、なぜそうなのか、何ができるのかについてはまったく情報を提供していません。



その後、バランスの魔法を開始します。 すべてのプロジェクト参加者にほぼ均一な負荷をかけることにより、各段階の期限を最小限に抑える必要があります。 これを行うには、次のアクションを実行します。

1. タスクエグゼキューターを変更します。
   
   
   
   あるアーティストのタスクの尾が大きい場合、これを行うのは理にかなっています。
   
   そしてもう一方には明らかな「穴」があり、彼はいくつかの仕事を引き受けることができます
   
   最初に。
2. タスクを別のステージに移動します。
   
   
   
   ステージの延長につながるが、必要ではないタスク
   
   ステージの結果を取得するには、後でステージに転送できます。 そしてその逆
   
   ステージでのアーティストのロードに「穴」があり、アーティストを変更する場合
   
   うまくいかない場合は、次の段階からタスクを実行してみてください。

残念ながら、これらすべてを手動で行う必要があり、各変更後のリソースのロードのバランスを取ります。 明らかな複雑さにもかかわらず、このプロセスには通常有限の時間がかかります。 4つのステージに分かれた8人の参加者による1年間のプロジェクトで、1時間以内に整理しました。



もう一度プロジェクトを注意深く見てみると、タスク間の接続が正しく配置されており、何も忘れられておらず、パフォーマーの任命は彼らの専門と資格に対応していると確信しています。

リスク会計

最後の最後は、リスク管理です。 正直なところ、私は深刻なリスク管理に従事していませんでしたが、特定の不可抗力（実行者の病気、忘れられた仕事など）の可能性を考慮しています。 これを行うために、各ステージに、各リソースの「その他の作業」と呼ばれる最小優先度の架空のタスクを追加します。 リソースを調整した後、これらのタスクはステージの最後にあります。 これらのタスクの期間は、発生の可能性とリスクの影響度に依存し、タスクの期間の推定値の決定方法、チームメンバーの健康状態、およびプロジェクトマネージャーの妄想の程度に依存します。 通常、「その他の作品」の期間は、ステージの長さの約3分の1から4分の1に設定します。



これらすべての操作の結果、プロジェクトの実装計画が得られ、それを使用して作業できます。



この計画では次のことができます。

1. プロジェクトの条件とそのステージに名前を付けます。 理性的で高い
   
   信頼性。
2. 推定プロジェクト労働力を推定する

ご注意 リードタイムが非常に長いことはよくあり、追加のパフォーマーを引き付けることでそれを短縮できるかどうかという合理的な疑問が生じます。 この質問に答えるために、同じタスクセットを使用して、実行者の構成を変更して、新しい計画のバランスを取りました。 すぐに答えは出ませんでしたが、それほど時間はかかりませんでした。

計画を立てる

プロジェクトが開始されると、評価に使用された元の計画を使用してプロジェクトの進行状況を追跡することもできます。 プロジェクトマネージャーは、次のアクションを定期的に実行する必要があります。

1. パフォーマーに課題を与える
2. 計画で完了したタスクをマークする
3. 大幅な逸脱がある場合に計画を調整する

実行者によるタスクの割り当ては、さまざまな方法で実行できます。 実行を短い反復に分割し、反復用のタスクのプールを形成し、反復の最後に結果をマークできます。 すぐに一連のタスクをラゼリにステージに伝え、ガントチャートのコピーを各自に渡し、定期的に進捗状況を尋ねることができます。 MS ProjectとTFSの統合を使用して、プロジェクトをTFSに直接アップロードできます。 ポイントは手段にありません。 主なものは、計画の定期的な更新です 。 私はこれを週に1〜2回行います。 これにより、問題のある領域をすばやく確認できます。

さまざまなグループを使用して、問題のある領域を特定するのが便利です-エグゼキューター、コンポーネントなどによって、プロジェクト全体が予定よりも進んでいることがしばしばわかりますが、たとえば、開発者の1人が予期せずに深刻なシステム問題に遭遇したなど、特定のコンテキストで遅れがあります偏差に。 平均メトリックのみを使用しても、この問題は表示されません。ステージの終わりにのみポップアップし、何もできないほど遅すぎます。





コンポーネントごとにグループ化してパフォーマンスを追跡する



ご注意 通常、カレンダーに従ってタスクを移動するのではなく、タスクの完了方法にのみ注意します。 現在の時点からのプロジェクト目標全体の偏差によって、計画からの偏差を追跡します。



別の戦略があります-タスクの期限を変更し、未処理のタスクを「プッシュ」します。 このアプローチでは、MS Projectの別の便利な機能である基本計画を使用して、計画からの逸脱を追跡できます。 基本計画は、単にタスクのステータスの保存されたスナップショットです。 プロジェクトの最初に行うことができます。 現在の計画をベースラインと比較するには、「追跡付きガントチャート」を開きます。 動的計画の場合、タスクの順序が頻繁に変更されると不便になる可能性があるため、重要なプロジェクト結果を反映するコントロールポイントをプロジェクトに挿入し、それらについてのみ基本計画からの逸脱を追跡します。





追跡付きガントチャート

カスタムフィールドを使用してタスク構造を管理する

機能の分解やタスクの分類にMS Projectのサマリータスクを使用しないことを強くお勧めします。 実際、MS Projectのタスクの階層は、そのシーケンスに強く結び付けられています。 また、構造全体が「崩れている」一方で、タスクを別の順序で見たいことがよくあります。 タスクの構造を管理するには、 カスタムフィールドを使用することをお勧めします。 MS Projectには、未定義の動作を事前に定義した一連のフィールドがあり、好きなように使用できます。 たとえば、タスクをコンポーネントに分解するには、 Text1テキストフィールドに基づいてコンポーネントフィールドを作成し、システムコンポーネントに対応する値のリストを設定する必要があります。





カスタムフィールドを作成する



その後、各タスクについて、それが属するコンポーネントを示し、コンポーネントごとのタスクのグループ化を使用して、物事の進行状況を監視する機会を得ます。





コンポーネントごとのタスクのグループ化

カスタムフィールドを使用すると、タスクをいくつかのカテゴリに分類できます。たとえば、タスクを作業の種類（開発、テスト、ドキュメント）で分割しました。

MS Projectでは、タスクのプロパティに基づいてダイアグラムを描画するためのルールを設定することもできます。 必要に応じて、異なるコンポーネントのタスクに異なる色を付けることができます。色はタスクのプロパティによってのみ決定され、タスクごとに手動で設定する必要はありません。 このような設定では、スクリプトを記述する必要はありませんが、ダイアグラムをセットアップする標準的な手段を使用して行われます。



カスタムフィールドの使用、およびMS Projectに統合されたタスクのフィルタリング、並べ替え、およびグループ化の機能により、プロジェクトマネージャーに関する多くの質問に対する回答を得ることができるさまざまなビューを取得できます。

プロジェクト完了

プロジェクトの最後に、すべてのタスクが完了する計画を取得します。 通常、少なくとも基本計画として、元の計画も維持しようとします。 正直なところ、この段階では、MS Projectはほとんど価値がありません。なぜなら、それは関心のある計画値ではなく、実際の値だからです。 この問題に対するいくつかのソリューションはMS Project Serverによって提供されます。実際の人件費を考慮する機会がありますが、これはすでにこの記事の範囲外です。

おわりに

私は、ソフトウェア開発プロジェクトを率いたときに目の前で生じたタスクの実用的な解決策として、MS Projectを使用した経験をまとめようとしました。 説明した手法は普遍的ではないふりをしていませんが、非常にシンプルで論理的であると同時に、プロジェクトマネージャーの実際的な問題を解決できるように思えます。

このアプローチを使用することで、複数のプロジェクトを予定通りに完了することができました。

確かに、失敗がありました。 原則として、これはプロジェクトの準備部分が不十分に実行されたときに起こりました。つまり、問題の声明です。 つまり プロジェクトの結果、それはまったく必要なものではありませんでしたが、この理解は遅すぎました。



きっと私は何かを逃しました。質問することをheしないでください。