ストーリーポイントまたはスクラムの他の何かを使用してタスクのコストを推測する方法はありますか？
私たちはウェブサイトやアプリを作るために一緒に働いているフリーランサーの集まりであり、最近スクラムを使い始めました。私たちはスクラムとその透明性を楽しんでいますが、方程式の予算面で問題に直面しています。
スクラムは予算を考慮していないように感じますが、私たちは新しすぎて確実に知ることはできません。
スクラムの予算とタスクコストを検討する方法はありますか、それともストーリーポイントを使用してスクラムが達成しようとしていることに反しますか？
スクラムは、予算や期限などを直接考慮しません。代わりに、予算と期限を誠実に管理するために必要な情報をプログラム管理者に提供しているようです。ストーリーポイントは優れた例です。ストーリーポイントは、それ自体で、タスクにかかる時間についてnothingと言います。彼らはタスクの複雑さについて話します。ただし、チームが実行している1週間あたりの平均ポイント数である「速度」を調べて、Xストーリーポイントshouldにかかる時間を決定することは合理的であると考えられます。 Velocityは、SCRUMで予算を立てるための非常に人気があり非常に強力なツールです。
この背後にある理論についての私の意見は、予算や期限を明示的に考慮するほとんどのシステムは、開発者が予算に合わせるために不十分な見積もりを出す傾向が強いということです。多くの場合、重要な情報は、チームがスケジュールからどれだけずれているかを示すため、スケルチされます。この問題に対するSCRUMの解決策は、最初に情報が適切に流れるようにすることに集中し、次に期限を検討することだと思います。
SCRUMはカスタマイズを奨励します。特定の会社のニーズに合わせてワークフローを調整できる場合があります。
ストーリーポイントは通常、実装の複雑さの尺度です。複雑さとコストの間には相関関係がありますが、ほとんどのシナリオでは、コストは他の多くの要因の影響を受けます。
したがって、ストーリーポイントから実装コストの概算が得られる場合がありますが、非常に大まかなため、実際にそれに依存するべきではありません。
SCRUM（およびその他の反復的またはアジャイルアプローチ）の主なポイントは、プロジェクトを「終了」するためにどのような作業が必要で、どれだけの作業が必要かがわからないことです。プロジェクト中の任意の時点で、顧客からのフィードバックに基づいて新しいタスクを追加、拡張、または削除できます。これが、SCRUMやその他のアジャイル手法が、[予算が費やされた]/[計画された時間が費やされた]メトリックのx％で、「従来の」ではなく、顧客に進歩の感覚を与えるために、反復ごとに動作するソフトウェアを作成することを選択する理由です。
これは、推定総コストや必要な時間など、あらゆる形式の予測メトリックにとって問題です。これは、実際に実行する必要のある作業の量が一瞬でわからないためです。推測する方法はいくつかありますが、プロジェクトが複雑で大きくなるほど、不確実性が増します。そして、あなたの顧客が1年±9ヶ月の見積もりと関連する総費用で大丈夫かどうかはわかりません。
本当に総コストと費やした時間を見積もる必要がある場合は、SCRUMを取り除き、プロジェクトを完了するために必要なすべてのタスクとそれらを完了するために必要な作業量を推測しようとする、より伝統的なアプローチを採用します。あなたは少なくともあなたの推測が正しいかもしれないという確実性のいくつかの類似点を得る。