ご存知のように、ソフトウェア開発は長いプロセスであり、人々は主にこのプロセスのさまざまな部分に関与しています。
人々はネットワークプランニングプラクティスの助けを借りてプロセスを計画および説明する方法を長い間学びましたが、その代表的なものがガントチャートです。 多くのソフトウェアツールが開発およびテストされており、誰でも簡単にアクセスできます。
説明されたプロセスが広く分布し、比較的便利に視覚化されているため、これらの図はソフトウェア開発の計画段階でよく使用されます。 しかし、これらの図は、ソフトウェア開発において非常に便利で必要ですか？
チャートを構築する主な目的は、必要なリソースの数、完了する必要のあるタスク、これらのタスクが完了する期限を予測すること、および作業のコストを理解することです。 目標は、タスクのリスト、必要なリソースの決定、タスク間の依存関係の決定、効果的な使用のためのリソースの使用の平準化、リスクを考慮して達成されます。
ソフトウェア開発の古典的なアナロジー、つまり家を建てることを使用します。 このコンテキストでは、それが最も適切です。 家を建てると同時に、最低限のお金を費やし、必要な時間を満たすために、次のことを理解する必要があります：必要なリソース（レンガ、セメント、コンクリート、労働者など）、必要な時期、作業を実行する順序、および技術に耐える家を建てるよく知られた、かなり透明なプロセスの実装のための標準。 この場合のガントチャートの使用は、この問題の解決策に有機的に適合します。
開発を知らない人が家を建てるという例えをよく使うとき、私はいつも始めます。彼らにとって、問題のいくつかは目に見えませんが、それらは重要です。 ソフトウェア開発プロセスと家を建てるプロセスの違いは何ですか？
資源
開発において、主な、そして唯一のリソースは人です。だから彼はしばしば皮肉を嫌います。これはスケジューリングの本質に内在しています。人はリソースではなく、愛され尊敬されたいのです。 計画を立ててそれを最新の状態に保つには多くの時間がかかり、最終的な目標を達成することができます。 特定の開発者、テスター、またはアナリストは純粋なリソースではありません。特定のアーティストを置き換えるのは難しく、費用がかかるからです。システムの特定の部分をよく知っていて、特定の経験とスキルを持っているからです。 人間はこのチェーン全体の極めて非線形な要素です。つまり、人間の興味、忠誠心、アクセシビリティに100％頼ることはできません。
プロジェクト範囲
開発者が実行する必要があるタスクのリストは、将来の製品の本質を十分に理解していても明らかではありません。 自動テストを使用することはできますが、使用することはできません。分析、テスト、または文書化フェーズの一部のステップをスキップすることができます。逆に、一部の領域では、より注意を払う必要があります。 プロセスのすべての微妙な複雑さが非常に複雑であるため、タスクのリストを表面的にしかカバーできず、それらの多くはプロジェクトの後の段階で公開されます。 最後に、プロセスの期間は、製品に対する顧客またはユーザーの要件の変更速度と矛盾します。
タイミング
開発プロセスははるかに柔軟なものであるため、顧客はプロジェクトの範囲、関連するリソース、作業コストを自由に操作できます。 コンクリートスクリードが3日間乾燥し、顧客が理解するよりも少なくないという事実が、アクセス制御のサブシステムが1か月間書かれているという事実は、理解がはるかに複雑であることがわかります。 三角形に変更を加えると、計画が大幅に改訂されます。これには多くの時間がかかり、たとえばプロジェクトマネージャーなどの専任者が必要です。
依存関係
比較的複雑なシステムの実装で満たさなければならないタスクのもつれ全体を理解して実現することは、実際には不可能であり、したがって、タスク間の依存関係を決定します。 プロセスの変更はリソースの使用の再計画を必要とするため、効果的な計画を作成してコストを最小化することは事実上不可能です。
反復性
大部分のプロジェクトでは反復プロセスモデルを使用していますが、線形カレンダースケジュールではこの特異性をまったく考慮していません。 製品のライフサイクルは複数の段階（リリース）で構成され、各段階には繰り返しの部分があります。 実装された機能のライフサイクルは、分析、設計、開発、テストなどの既知のフェーズで構成されます。 どの機能にもそのようなライフサイクルがあります。 ガントチャートでは、各機能の特定のフェーズのタスクをペイントする必要があり、これは非常に退屈なタスクですが、そうでない場合、計画は価値がありません。
結論
ガントダイアグラムは、大部分の線形リソースを使用する決定論的でほぼ静的なプロセスを説明するためによく使用されます。線形リソースの技術サイクルはよく知られており、解決されています。
これらの図を編集して維持するのに時間を浪費することは意味がないと自分で決めました。参加者間のコミュニケーション、プロジェクトへの真の支援、参加者の忠誠心の向上にこの時間と労力を費やす方が良いです。
ただし、これは、範囲、時間、コスト、およびリソースを考慮して計画する必要がないことを意味するものではなく、必要ですが、他のプラクティスを使用するだけです。
継続
ガントチャートはソフトウェア開発に便利ですか？
All Articles