12.0ウォーターフォールと循環プロジェクト管理(パート5)–循環プロジェクトを管理するための条件

ユーザー/顧客は積極的に参加します #

周期的なプロジェクト管理の各サイクルには、要件の開発、設計、実行、およびテストが含まれます。 これは、サイクルの過程で多くの選択を行う必要があることを意味します。 プログラムがクライアントの要望を正確に表現することである場合、顧客はプロジェクトチームの積極的なメンバーである必要があります。

顧客は、可能な限りわかりやすくプログラマーや設計者に要件を伝える必要があります。 多くの場合、これにはプロジェクトチームへの毎週(または少なくとも隔週)の参加が伴います。

プロジェクト内で、消費者は必要な機能の定義とサイクル計画に貢献します。 彼らは受け入れテストに協力し、中間結果を承認または却下し、プロジェクトの全体的な方向性に貢献します。 さらに、ウォーターフォール方式を使用すると、顧客の積極的な関与により結果が改善されます。

チームには、選択を行う権限があります。 #

サイクル内で、プロジェクトチームは独自の決定を行う権限を与えられている必要があります。 プロジェクトチームにこの権限がない場合、プロジェクト管理のサイクリックモデルは機能しません。 サイクル全体を通して上司からの絶え間ない承認が必要な場合、これは停滞につながる可能性があります。 さらに、部外者はプロジェクトチームに積極的に関与していないため、何が起こっているのかを知らないことがよくあります。これは彼らが合理的な決定をすることを困難にします。

プロジェクトの出力(ソフトウェア)は、より小さなコンポーネントに分解できます。 #

循環プロジェクト管理は、プロジェクトの一部が一連のサイクルで完了するプロジェクトを管理する方法です。 これは、開発中のソフトウェアが多かれ少なかれ別個のコンポーネントに分解できる場合にのみ可能です。

プロジェクト管理ソフトウェアに対する管理者の要件は、主にグローバルです。管理者は、直接、具体的、または特定の要件を課しません。 周期的なプロジェクト管理の利点の1つは、顧客、設計者、プログラマー、およびサイクル中のテスター間の緊密なコラボレーションです。 プロジェクトの開始時に具体的で具体的な要件が確立されている場合、これにより、プロジェクトチームが設計を選択する際に最善の判断を下す能力が制限されます。 プロジェクトに関する多くの要件は、プロセス中に適応が必要であることが明らかにされているため、開始時に(あまりにも)しっかりと確立されるべきではありません。

お客様はその活動を理解しています。 #

お客様が理解しにくい重要な技術的作業がサイクル内で発生しなければならない場合、お客様がチームに効果的に貢献できなくなるリスクがあります。 このような状況では、顧客は、行わなければならない設計上の決定についてほとんど発言しません。

顧客が進捗状況に気付いていない場合にも、同様のリスクが存在します。 たとえば、作業の多くはコーディングに専念し、ユーザーインターフェイスにはほとんど注意を払わない場合があります。 傍観者に追いやられることを避けるために、顧客がサイクルの内容と進行について十分な洞察を持っていることが重要です。

自分の歩みをたどることができるはずです。 #

周期的なプロジェクト管理であっても、チームは時折、間違っていることが判明したパスを追求します。 このような場合、一歩後退することが可能であるはずです。 サイクル中に作成された新しいモジュールが不十分であることが判明した場合、前のモジュールでの作業を再開できる必要があります。 これにより、特にプロジェクト資料のアーカイブと文書化に要件が課せられます。 CVSとSubversionは、これらのタスクに役立つ2つのツールです(ツールの完全なリストについては、付録3を参照してください)。

プログラミングスキルに加えて、プログラマーは顧客と効果的に対話できる必要があり、その逆も同様です。 チームメンバーは知的思想家でなければなりません。 仕事を続けるには規律が必要です。

プロジェクトが実施される組織も、この運用モードに対して十分なサポートを提供する必要があります。 プロジェクトをサポートするには、時間追跡、アーカイブ、およびスケジューリングシステムが必要です。 これらの登録システムは、プロジェクトおよび期間全体でリソースの公平な割り当てを保証するために不可欠なオープン性を提供します。

優先順位付け #

プロジェクトには十分な重要性を与え、チームメンバーがプロジェクトに参加できるようにする必要があります。 チームメンバーに同時に多くのタスクに取り組むことを要求することは効果がありません。 組織がプロジェクトベースの作業に適切に適応していない場合、周期的なプロジェクト管理の柔軟性が混乱を招く可能性があります。 さらに、ウォーターフォール手法は、プロジェクト管理への組織化されたアプローチから恩恵を受けます(Wijnen、2004、p.111を参照)。

マネージャーよりも先見性のあるソフトウェア開発会社のディレクターは、ほぼ毎月素晴らしいアイデアを思いつき、会社で常に新しいイニシアチブを開始していました。 その結果、古いプロジェクトは完了せず、労働者は同時に5つのプロジェクトに取り組みました。 カリスマ的なディレクターは、Rapid Application Development(RAD)に関する本を読み終えたばかりで、特に「迅速な」要素に非常に興奮していました。 彼はRADの基本的なアイデアをコピー機にテープで貼り付け、誰もがこれらのアイデアを使い始めることを期待していました。 結局のところ、それは優れたテクニックでした。

周期的なプロジェクト管理のリスク #

周期的なプロジェクト管理手法では、必要な機能を実行するのに不十分な時間が残ることがあります。 プロジェクトの期間が固定されているため、当初の予想よりもほぼ確実に追加される機能が少なくなります。

これは正当な懸念事項ですが、ウォーターフォールアプローチにも固有のものです。 ウォーターフォールアプローチの定義ステップでは、要件の詳細な調査が必要です。 この分析により、時間管理が改善される可能性があります。 上記の理由により、これは実際には当てはまらないことがよくあります。

さらに、機能を開発するための資金が不足しているため、このアプローチでは機能が省略されています。

要件は、サイクルアプローチで実用的に処理されます。 たとえば、サイクルのニーズは、MoSCoW基準(Stapleton、2003)を使用して次のように分類できます。

  • 必須:システムクリティカルな要件
  • 持っているべき:ユーザーが本当に望んでいる重要なニーズ
  • 持つことができる:簡単に無視できる望ましいニーズ
  • 欲しい:今回は満たされない要件:後で待つことができる要件

特定の機能が利用できなくなったかどうかに関係なく、DANSプロジェクトマネージャーは、周期的な作業がウォーターフォールアプローチよりも高い顧客満足度をもたらすと考えています。 いずれにせよ、期待は定期的により効果的に管理され、プロジェクトは、当初の想定よりも複雑でなくても、日常的に機能する結果を生み出します。

潜在的な欠点を理解する #

XPの一般的に引用される欠点の1つは、かなりの力がプログラマーに伝達されることです。 この権限を悪用すると、顧客の技術的専門知識の欠如を悪用して利益を得る可能性があります。 このシナリオを回避するには、プログラマーと顧客の両方の利益に気を配ることができるプロジェクトリーダーが必要です。 これらのプロジェクトリーダーは、クライアントがサイクルを選択および計画し、選択の技術的基盤を理解できるようにし、管理とレポートを提供するのを支援します。

最後に、XPのもう1つの欠点は、メソッドの実装には、プログラマー、マネージャー、およびコンシューマーにとって高い学習曲線が必要になることです。