前の記事で、プログラム開発においてガント図がどれほど便利で必要かという問題を提起しました。 チャートの使用は非常に複雑になりますが、最も経験のある人ではないため、プロジェクトの計画にも悪影響を及ぼします。 プロジェクトの条件を評価することを可能にするのは、どのような方法論であり、悪化することはなく、さらに頻繁に改善されるでしょうか？同時に、現在のプロジェクト計画の準備と保守に関連するコストを大幅に削減できますか？
説明されている手法はアジャイルファミリから借用されており、通常の意味での計画を意味するものではなく、図を使用して構築されています。 方法論は2つの基本概念に基づいています。反復タイプ（昨日の天気の原則-天気が落ち着いた場合、明日は今日と同じ天気になります）とチームのスピードです。
方法論
この手法の本質は、各反復の出力でチームに作業成果物がある場合（それ自体が進行状況の尺度）、いくつかの反復でチームの速度の平均的でかなり正確な推定値が得られることです。 速度は、反復ごと、1日ごと、または一定期間に費やした時間ごとに実装された機能（ユーザーストーリー）の数で測定できます。これは2番目の質問です。
このシステムでは、チームの速度は1日あたりのチーム作業の量で測定されます。 これは主にチームの特性であり、個々の特性ではありません。 この指標は、開発フェーズ、タスク間の依存関係、リソースの読み込み、週末または参加者の計画外の不在、およびその他のリスク、一般的に、反復中にチームに発生したすべてをカプセル化します。 次の反復中に高い確率で、開発はほぼ同じペースで進みます。
実際、スケジュールはまったく必要ありません。つまり、プロジェクト参加者が作成するタスクツリー、実装する必要がある一連の機能、各機能の実装プロセスに関するチーム内の合意（TDDの使用、自動テストの使用など）が必要です。チームのパフォーマンスデータ。 それだけです 次に、これらの機能の実装のタイミングを高精度で決定します。
もう1つのポイントが残っています。すべての機能には、実装に異なる労力が必要です。 それらをクラスに分割できます：単純、普通、複雑。 別の方法で、1つのリクエストの複雑さ（機能またはユーザーストーリー）を評価しました。 ここでは、チームが願いの実現の微妙な点をすべて理解せずに理解することなく、事前に正確に評価することは難しいため、過小評価のエラーが発生します。 一方、チームは人々で構成されており、テスト結果から明らかになるように、最初は希望が満たされない場合があります。 そのため、別のインジケータが導入されています。エラーの割合です。
結果
したがって、チームによる特定の一連の要望（機能またはユーザーストーリー）の達成期限は、単純な公式に従って計算されます：総労働強度評価*過小評価エラー*エラーの割合/チーム速度。
この手法の大きな利点は、評価の透明性です。目標を達成するために何を変更する必要があるかがわかります。 開発プロセスのすべての複雑さと複雑さから抽象化し、複雑さを予測せずに、それを観察し、将来の反復のために補間します。 別の利点は、願いの複雑さを評価する方法の独立性です。 チームリーダーは複雑さを評価することができます。その後、彼は実装についてのみ考え、他のすべてのフェーズのコストは過小評価の誤りによって説明されます。 チームは複雑さを評価できます。そのため、過小評価のエラーは時間とともに1になる傾向があり、可能な限り最大の価値に対する評価に対するチームの責任です。
チーム全体のタスクをペイントしたり、特定の幹部を事前に指定したり、依存関係を設定したり、リソースを均等化したり、最も重要なのは、スコープ、時間、またはコストが変わったときにプロジェクト計画を書き直す必要がなくなったという事実です スコープまたはその変更のコストとタイミングについてすぐに知ることができます。
制限事項
もちろんマイナスについては少しですが、それらはここにありますが、アジャイルの原則に従うためにプロセスを完全に無視したり、わずかに調整したりできるほど重要ではありません。
方法論は、チームの構成が変更されないという前提と、参加者の能力に基づいています。 多くの場合、これは複数の反復で当てはまり、おそらくリリースです。 チームでプロジェクトを完了するには、十分にまとまりがあり、安定している必要があります。 チームが解散した場合、または参加者が変わった場合は、累積された指標を再計算する必要があります。 良いニュースは、2〜3回の反復後にかなり正確なメトリックを収集できることです。
すべての反復における作業の構造はほぼ同じであると想定されています。つまり、アナリストは特定の時間にわたって作業し、その後、各機能は開発、テスト、および文書化の同じ段階を経ます。 各反復の最後に、安定した製品が必要です。最初の反復では、2番目の開発、3番目のテストで分析を行います。
タスク間で発生する依存関係を独立して検出および解決できる効果的なチームが働いていると想定されています。彼らはマネージャーを必要とせず、チームはソフトウェア製品の製造プロセスを理解しています。
チームがストアのアクティビティを自動化するWebアプリケーションを開発し、C ++でトレーディングアプリケーションを開発することが提案されている場合、ほとんどの場合、チームのインジケーターを再構築する必要があります。 ただし、いずれにしても、これは非常にリスクの高い仕事です:)
期限を見積もる方法は？
All Articles