周期的なプロジェクト管理の方法 #
上記の問題のために、プロジェクト管理のさまざまな代替技術が近年開発されてきました。 これらの手法は、情報技術開発イニシアチブに特に適しています。
循環的なプロジェクト管理は、一連の短い連続したサイクルを介してプロジェクトの目的を達成する方法です。 各サイクルは短く、理想的には1か月未満続きます。 各サイクルでプロジェクトの一部が完了します。 各サイクルには、分析、設計、実装、およびテストが含まれます。 これは、これらの各タスクが独自の異なるフェーズで発生するウォーターフォールアプローチとは大きく異なります。 さらに、ウォーターフォールアプローチでは、概念、設計、実装、およびテストのために、限られた数の明確な瞬間を指定します。 これは、循環的アプローチで連続して何度も発生します。
理解プロジェクト管理ソフトウェアサイクル #
さまざまなソフトウェアコンポーネントがサイクル全体に実装されているため、自己完結型です。 各サイクルは、完了後に評価されます。 理解を深めた結果、プロジェクトの新しいニーズまたは代替のニーズが発生した場合、将来のサイクルのアクティビティはそれらを含むように調整されます。
サイクルは、スケジュールの確立または変更から始まります。 その後、サイクルの出力ニーズが評価されます。 設計が開発され、コード化され、検証されます。 その後、評価が行われ、場合によっては新しいプログラムが実施されます。 次に、プロジェクトの後続のコンポーネントを完了するために、次のサイクルが開始される場合があります。 （循環技術とその区別の詳細については、たとえば、Kroll、2004、Chromatic、2003、Stapleton、2002を参照してください。）
循環方式を使用する主な利点は次のとおりです。
- 製品の品質と機能の実装の改善。
- 製品の品質と機能の実装の改善。
- より現実的な時間とコストの見積もり。
- プロジェクトチームへの負担が軽減されます。
- より高い品質。
前の章では、プロジェクトの初期段階で必要な機能を適切に定義することがいかに難しいか、または不可能であるかを示しています。 循環技術は、一連の短いサイクルで必要な機能を実装します。 各サイクルは、調査するだけでなく、必要な機能のごく一部を設計、実装、およびテストします。 設計、実行、およびテストの迅速な連続は、品質向上にとって重要です。 その結果、チームは変更を加えることができます。 デザインが実際に機能しない場合は、サイクル全体で明らかになり、変更が可能になります。 さらに、この種の操作により、消費者は変更を要求できます。
品質の維持 #
周期的なプロジェクト管理によって品質が向上するもう1つの理由は、各サイクルでクライアント、設計者、およびプログラマー間の強力な協力が必要になるためです。 学際的なチームがソリューションを一緒に開発して実行します。 クライアントは主に最初、要件の開発に従事しています。次に、設計者が設計を作成し、最後にプログラマーがソフトウェアを作成します。 プロジェクトリーダーは、さまざまな関係者全員の間の連絡係として機能し、提供された情報が適切な受信者に確実に配信されるようにする責任があります。 実際には、多くのプログラマーやデザイナーは、ソフトウェア開発プロセス全体でのみ再表示されるクライアントに遭遇することはありません。
プロジェクト管理の循環的手法は、芸術的または研究的イニシアチブなど、最終目的を事前に明確に定義できないプロジェクトに特に適しています。 エンドユーザーを含む多様なチームとサイクルで作業することにより、チームはプロジェクトの真の目的とそれを達成するための最良の方法を決定できます。 各サイクルは、反省と修正の機会を提供します。
ウォーターフォールプロジェクトの目標は事前に定義されています。 最初の目的を反映する可能性は低くなります。 最初に形成された目的は（完全に）実現されることはなく、最初に考案された目標も実現された目標も、正確に意図されたものではない可能性があります。
最後に、クライアントが受け入れテストを実施するため、周期的なプロジェクト管理方法は優れた結果をもたらします。 さらに、最初から高性能機能の基準としてテストを含めることにより、品質が向上します。 したがって、プログラマーは、コードを作成する前に「失敗したテスト」（または単体テスト）を作成する必要があります。 失敗したテストに合格したコードのみが受け入れ可能と見なされます。
一貫したテスト #
テスト指向の作業では、プログラマーは、新しいコードを作成する前に、バグがないことを実証する必要があります。 彼らは、コーディングを開始する前に潜在的な欠陥を特定するテスト（失敗したテスト）を作成することによってこれを行います。 キャンディーマシンから受け取る適切な変更量を決定するためにソフトウェアを開発する必要がある場合を考えてみます。 まず、変化を引き起こす可能性のある機能の存在を確認する必要があります。 この機能は「変更を与える」と呼ばれることがあります。 簡単なテストを実行すると、「変更を与える」機能がまだ存在しないことがわかります。 プログラマーが関数を作成したが、まだ実体を提供していない場合、テストは合格します。
次のステップは、アイテムが購入されたときにマシンが正しい金額を返すかどうかを判断することです。 マシンに60セントを挿入し、50セントのアイテムを購入します。 関数が空のままであるため、テストは失敗します。 その後、プログラマーがコードを記述します。 彼は、「変更を与える」関数で、返される変更の量が、選択されたキャンディーのコストを差し引いた、マシンに投入された金額に等しいことを指定します。 これで、テストは正常に合格するはずです。 この手順は、プログラムのコンポーネントごとに繰り返す必要があります。
コードを技術的にテストする必要があるだけではありません。機能もテストする必要があります（つまり、受け入れテスト）。 コーディングを開始する前に、クライアントは、開発する機能を承認するための基準を確立します（たとえば、コンピューターが特定のユーザーアクションにどれだけ速く反応する必要があるか）。 それ以前は、追加機能が承認される基準を定義することは、非常に複雑で時間がかかることが証明されていました。 それにもかかわらず、テストへの消費者の積極的な関与は、プロジェクトの成功にとって重要です。
時間とお金の見積もり #
実行される機能を理解することは、循環プロジェクトの開始時に事前に決定されていません。 利用可能な時間が示されています。 プロジェクトの方向性について合意に達し、プロセス全体を通じて、作成するプログラムに関して本当に必要で、有益で、実行可能なものが確立されます。 実装される機能は目標が設定されていないため、周期的なプロジェクトは、必要な時間、したがってお金が制御不能になる危険性を最小限に抑えます。 このシナリオを回避するために、利用可能な時間が開始点として使用され、その時間内に予測するのが合理的なものがプロセス全体で確立されます。
さらに、周期的なプロジェクト管理手法は、プロジェクトチームにとってかなり口に合うものです。 チームは割り当てられた時間枠内でできる限りのことを行いますが、不当な期限を達成したり、不十分な予算内で運営したりするように迫られることはありません。
さらに、周期的な手法により、外国のプロバイダーの管理が簡素化されます。 ウォーターフォールアプローチでは、サプライヤのパフォーマンスに関係なく、プロジェクトが完了するまで、プロジェクトは単一のプロバイダに依存するようになる可能性があります。 理論的には、サイクルごとに、または各コンポーネントを循環作業技術の下で供給し、必要に応じてサプライヤーを変更するために、新たな契約を結ぶことが可能です。
