ガントチャートのポイントは何ですか？それは私を助けますか？
私の（技術者ではない）同僚が、現在計画している新しいプロジェクトのガントチャートで私を脅しました。これは私たちに何を提供する可能性が高く、それは役に立つツールでしょうか？
ウィキペディアが言うように ガントチャート は、プロジェクトの計画に役立つ棒グラフ（多くの場合、「線種」）の一種です。それはしばしばそのフォーマットで簡単に修正されるので、大きな（本当に大きな）紙の壁に手動で描かれます。
これは非常に単純なタイプの計画ツールです。 Excelまたは同等のもので作成できます。プロジェクトの特定のフェーズに必要な時間がおおよそ見積もることができる限り、かなり効果的です。遅延がある場合-問題ありません-1行が長くなり、他の行は同じままで、新しいプロジェクト終了日があります。
あるフェーズの開始の依存関係が別のフェーズの終わりに依存しているのと同じくらい簡単に、重複するフェーズ（時間的に）が簡単に見られます。
本当にすべてです。
もちろん、Gannt（または、世界の私の部分で通常呼び出される「タイムチャート」）の問題は、プロジェクトの最初に、すべてが壁にうまく描かれ、熱狂的に感じられることです。そしてハッピー、...その後、1つの遅延が発生し、チャート上でそれを変更しても、まだハッピーになっています...その後、別の遅延が発生し、再びそれを作成し、それでもかなり良い感じです。 。100倍の遅延が発生します... _______（検閲）のような感じです。
つまり、実際にこれらの小さな締め切りに固執している場合にのみ、これは優れたプロジェクト計画ツールです。 だから、ここで時間を無駄にせずに仕事に取り掛かってください！
適切に作成および保守されたガントチャートは、優れたツールです。主なメリットは、どのタスクが他のタスクに依存しているかを示し、プロジェクトが遅延によってどのように影響を受けるかを予測し、他の何かを待っていたために浪費された時間を強調することです。
私は過去にソフトウェアプロジェクト管理にガントチャートを使用して成功しました。私は人々が欲求不満でそれらを放棄するのを見ました。
プロジェクト管理ツールは、誰かが実際に尋ねている質問に答える場合にのみ役立ちます。私の場合、私は2つの質問を絶えず求められましたが、ガントチャートで答えることができました。
- マネージャー：ソフトウェアはいつ出荷可能になりますか？
- 開発者：割り当てられたタスクを完了しました。今私にどんな仕事を割り当てていますか？
では、ガントチャートを使用するにはどのような要素が必要ですか。
複数のチームメンバー
それは明白なはずです。チームメンバーが1人だけの場合、必要なのは1列のタスクのリストだけです。あなたはそれらを次々に行うだけです。
タスクについての知識
これはもう1つの明白なステートメントのように見えますが、タスクに分割できるほど十分に定義されていないソフトウェアプロジェクトがいくつあるかは驚くでしょう。実際には、事前の仕様とある程度の事前の設計が必要です。一部のアジャイル/極端な方法論では、ガントチャートを使用できません。これは、後続の3週間の反復でどのタスクが行われるかがわからないためです。
チャートを維持するための時間と動機
誰かが物事を維持するために時間を費やす必要があります。多くの場合、誰かが詳細なガントチャートの作成に何日も費やし、それを無視します。おそらく彼は1か月後にそれを発表し、神経質に笑い、それを捨て、二度とそれについて話さないでしょう。
タスクと最適な見積もりを取得したら、それらをチャートに配置します。そして、最初のタスクが完了したら、それをチャートにマークし、他のすべてのタスクを揺らして、見積もりが間違っていたという事実を補正する必要があります。そして二日後、あなたは再びそれをします。そして再び、2日後。そしてもちろん、何かを忘れた場合や欠陥が表示された場合は、新しいタスクをチャートに追加する必要があります。
それは重要な継続的な時間のコミットメントのように聞こえるかもしれません、そしてあなたは正しいです。これを行う動機はどこから来たのですか？
誰かが実際に結果を気にします
私がガントチャートをうまく使用したのは、毎週プロジェクト管理会議があったときでした。マネージャーは部屋を回って、各チームリーダーにプロジェクトがいつ配信されるかを説明するよう依頼します。プロジェクトが遅れて実行されている場合、リソースは再割り当てされます。最初の2つの会議では、いつ配信されるのか本当にわからなかったので、「3か月で」あいまいになってしまいました。これが恥ずかしかったので、自分の戦略を変更し、各会議の前に最新かつ正確なガントチャートがあることを確認しました。
副作用として、これによりプロジェクトがより効率的に整理され、チームメンバーのモチベーションが高まりました。
現在のようにプロジェクト計画を不人気にするために、ガント追跡よりも多くの信用に値する発明は1つもありません。ガントの追跡は有害であると見なされるだけでなく、悪であると見なされる必要があります。これが理由です。
理由＃1：彼らの動機
ガントチャートを使用すると、計画の各ステップについて、実行にかかる時間と実際にかかる時間を確認できます。毎日、ステータスミーティングで、フェーズXは3月までに開始されるはずでしたが、明らかに5月まで開始されません。驚くばかり。最初の計画を行ったとき、プロジェクトの進行に伴って計画を変更する必要があることはすでにご存じでした。新しい情報が明らかになります。人やリソースは予測不可能などです。では、すべてのステータスミーティングで、初期の予測が実際の生活でどれほど不十分であるかを常に思い出させることが重要なのはなぜですか。
理由＃2：彼らはあなたに元の計画に固執することを強制します
プロジェクトのガントチャートを追跡するというまさにそのアイデアは、新しい情報に基づいて作業計画を絶えず適応させることに焦点を合わせるのではなく、古い計画に固執することを選択するということです。プロジェクトの初期の計画段階に伴う膨大な量の不確実性の避けられない結果。結局のところ、計画の根本的な変更を許可すると、ガントを追跡できなくなります。同じ一般的な形状を持ち、同じステップで構成されている必要があります。それ以外の場合は何も追跡する必要はありません...計画に固執するこだわりが、最近「ウォーターフォール」が実際に軽蔑的な用語と見なされる最大の理由です。先の計画は、元の計画を守ることと混同されます。
理由＃3：彼らはあなたに何も教えない
計画しているプロジェクトが予想どおりに類似していて反復的でない限り、このプロジェクトの遅延が実際に次のプロジェクトの計画方法を変えることになるわけではありません。結局、それはガントが最初に使用されたものです-工場の生産ラインでの計画作業、タスクは非常に明確に定義されており、その期間は非常に予測可能です。
トラッキングによってソフトウェア開発のガントチャートに追加される値はゼロです。間違いなくゼロ未満です。過去の見積もりが新しいプロジェクトに無関係であるだけでなく、過去に遡って見積もり能力を実際に改善できるという幻想は危険です。確かに、CSの学生は、統合が実際の生活に多くの時間を要することを本当に知らないかもしれません。しかし、生涯で2つ以上のプロジェクトに関与している人は誰でも、プロジェクトの遅延の通常の容疑者をすでによく知っています。プロジェクトが遅れる本当の理由は、一般的に見積もりに適用する必要がある数学的なエラー要因ではありません。それは、何かを初めて実行する際に生じる固有の不確実性であり、どのように展開するか正確に知らないためです。
実際には、この誤った方向から問題に対処しようとするプロジェクト管理システムがあります。予測と実際のパフォーマンスを比較し、統計分析を使用して全体の見積もりを修正しようとします。 「ダニーは常に14.3％ですべてを過小評価している」かのようです。ダニーは愚かではありません、そして彼の予測の誤りが予測可能であると仮定することは確かにばかげています。それは原始的な「治癒」-見積もりに要素を追加すること-を問題の原因と混同します。 「正しい」係数を掛けていないため、見積もりは不正確ではありません。あなたの計画は単に不完全です。そして、すべての計画は独自の方法で不完全です。
理由＃4：彼らはあなたの注意を間違ったものに集中させます
時間どおりに提供するために何を行う必要があるかに焦点を当てるのではなく、不正確な予測を正当化することに焦点を当てています。より詳細な計画に焦点を当て、計画を新しい情報に適合させる代わりに、古い計画を作り直しています。作業計画の部分が誤って見積もられたため、プロジェクトが遅れることはほとんどありません。物事のがらくたが単純に元の計画から除外されたので、それらは遅れています。ガントを追跡すると、これがさらに悪化します。すべてのステータスミーティングですべてが不十分な見積もりとして強調表示されるだけの場合、プランにどのような動機を追加する必要があるのですか？ガントチャートでは、追跡可能な大量の作業に固執します。適応に集中して正しい方向に進む代わりに、利用できる情報が少ないときに行われた無関係な決定を再検討することができます。
十分に手の込んだ計画を管理するのに十分なツールがないという問題もあります。道に沿って頻繁に無視されているすべてのステップをツールで公開できる場合は、適切な初期計画（および見積もり）を構築できる可能性が非常に高くなります。従来のガントとは、開発者がプロジェクト管理の現実の似顔絵として正しく見ている低解像度の獣です。必要なのは、できるだけ早い段階でできるだけ多くの情報を作業計画に追加し、不確実性の霧がプロジェクトから徐々に消えていくのと同じくらい簡単に計画を適応させることができるツールです。あなたが必要とする最後のものは、あなたの不正確な過去の予測の絶え間ない低解像度のリマインダーです。ガントの追跡は、指を向けたり、ろばを覆ったりするのに適しています。
ガントチャートソフトウェアを使用すると、複雑な相互依存関係を分析し、オーバーランと遅延の影響を予測できます。
ただし、ほとんどのソフトウェアプロジェクトでは、相互依存関係と外部入力がほとんどないため、予測の鍵は、ソフトウェアチームが3週間かかると言うときに使用する適切な乗数を知ることです。
プロジェクトがソフトウェア開発プロジェクトである場合、ガントチャートはあまり役に立たず、ほとんどの場合時間の無駄になります。つまり、ソフトウェア開発の流動性を考慮して設計されていません。
- タスクは通常、順序に依存しません。これらは任意の順序で実行できます。
- タスクの順序によって、タスクの完了に必要な時間が変わる可能性があります。
- タスクは他のタスク、例えばバグを生み出すことができます
結局のところ、作業を行うよりも計画を更新することに多くの時間を費やすことになります。
要件を管理するだけで、他のすべてが自動的に処理されます。
YMMV
他の人がガントチャート（一般に非公式にプロジェクト計画と呼ばれる）は、タスクとそれらのタスク間の相互依存性をマッピングする方法であり、プロジェクトの最小合計経過時間を確立することを目的としています。
管理の観点から、重要な出力はクリティカルパスの識別、つまりタスクが遅れるとプロジェクトが遅れるタスクのリストです。
非常に単純な例-2人のプログラマーが3つのタスクでプロジェクトに取り組んでいるとします（コードモジュールAが1人のプログラマーに10日かかり、コードモジュールBが1人のプログラマーに5日かかり、aとbを統合して両方のプログラマーに2日かかります）。最初の2つのタスク（モジュールAとBのコーディング）は並行して行われ、3つのタスクをすべて完了し、12日ですべてをプロジェクトすることが目標です。
この場合のクリティカルパスは、モジュールAをコーディングしてから統合テストを行うことです。モジュールBのコーディングは、実際には5日遅れて（または5日オーバーランして）開始できますが、時間どおりに完了したとしても、コーディングモジュールAはそれだけ長くかかります。一方、コーディングモジュールAまたは統合テストがいつでもずれると、プロジェクト全体がずれます。
この種のことを知ることは、リソースをデプロイする方法と、特定のタスクの遅延がプロジェクト全体に影響を与える可能性があるかどうかを理解するのに役立ちます。
それらは役に立ちますか？明らかにそうですが、重要な注意点が1つあります。それらに含まれる情報が適切である限りのみです。つまり、
- タスクリストが完成しました
- 見積もりは正確です
- タスク間の依存関係は包括的であり、
- チームを代表し、タスクに正しくマッピングされたリソース。
そして、そこからチームはチャートに取り組み、正しい順序でタスクを実行する必要があります（割り当てられたタスクよりも興味深い何かを行うと、何かが遅れる可能性があります。
それをすべて行う場合、はい、それは本当にあなたを助けることができますが、正確で現実的なものであることを確実にするために作業を前に置く必要があります。
私はガントチャートが大好きです。Macがガントチャートを作成するためのより良いソフトウェアの選択肢がある場合、私はそれらを常に使用します。
依存関係を確認することは非常に大きなものです。 「プロジェクトのデータの埋め戻し部分が完了しないと、whatsit拡張機能の構築を開始できません。」