これは事実です:
試み:
何かご意見は?
最終的に実際の時間を概算するためにそれを煮詰める方法がないのに、なぜ見積りをする必要があるのか不思議です。私が考えることができる唯一の理由は、「それは大きすぎる」と言ってそれをさらに分解できることです。
とにかく、推定値を変換する最も一般的な方法は、過去数か月間の実際のパフォーマンスを測定することです。過去にラージを修正するために過去7営業日を平均すると、オッズは平均で7営業日になります。
エビデンスベースのスケジューリング グラフのような、空想を得て信頼グラフを作成することもできます。たとえば、「同じようなタスクの平均7営業日ですが、2週間かかる可能性は15%、1か月かかる可能性は1%です。」
あらゆる見積もりアプローチの最終的な目標は、見積もりを「実際の」用語に変換できるようにすることです。それ以外の場合、ポイントは何でしょうか? Tシャツのサイズを実際のタイムラインに変換できない場合、Tシャツのサイズの見積もりはどのように使用されますか?
相対推定手法が使用される理由は、人々が絶対的な用語で推定することは絶対にひどいためです。一方、人々は相対的な見積もりを提供することでかなり良いです。あるタスクを別のタスクと比較して、どちらに時間がかかるかを言います。
ほとんどの人が見落としているように見える部分は、以前の取り組みの結果を取り、それらから統計モデルを構築することになっているということです。各Tシャツのビンでタスクを完了するのにかかる平均日数と、標準偏差を単純なスタートとして計算できます。それは統計学者の基準に達していないかもしれませんが、それを使用して顧客の完了の90%の見積もりを作成できます。
重要なのは、これらをチームの実際のパフォーマンスに基づいているということです。 1〜2日と小さいと伝えた場合、ブタに小さな口紅を付けて、絶対的な推定に戻ります。明らかにこれには、いくらかの歴史が続くことが必要です。新しいチームから始める場合、少なくとも最初は、別の戦略が必要になるでしょう。
いずれにせよ、一方は挫折するでしょう。そして、「クライアントは常に正しい」と仮定すると、それは開発者になります。本当に、これを解決する唯一の方法は、政治をすることであり、絶対的な推定は意味がないことをクライアントに説明することです(何かがうまくいかない可能性が常にあるので)。または、どういうわけか、正確な見積もりを出すように開発者を「やる気にさせる」。
それらのどちらも満足のいくものではありません。そして、これがテクニカルフォーラムであることを考えると、実際にはテクニカルソリューションはありません。
多少余裕を持って見積もります。クライアントには制約があることを理解する必要があります。彼らは通常、期限があるために時間の見積もりを知りたい、または予算があるために作業の見積もりを知りたいと思っています。時々彼らは両方を持つでしょう。どれだけ速くそれができるか、どれだけのお金が節約できるかということではなく、彼らが利用できるリソースを扱うことです。あなたが彼らのために快適な何かと一致することができるなら、あなたは行ってもいいです。
シャツのサイズを扱うことは、ある程度の余裕があるため、実用的です。日/時間でそれと同等のものを与えるだけで、それらに大まかな見積もりを与えることができるでしょう。
別のアプローチは、Planning Pokerを使用することです( https://en.wikipedia.org/wiki/Planning_poker )。ここでの考え方は、正確な見積もりを与えることではなく、チームにとってどのような努力が意味されるかについて一貫性を保つことです。スプリントで作業を分割する場合、プランニングポーカーから得られる見積もりは反復ごとに強化され、最終的に同様のタスクが同様の値で見積もられるようになります。ここでの数字は、チームが望んでいる意味です(したがって、1は1日の作業または数時間になる可能性があります)。また、Tシャツのアプローチと同様に、クライアントやビジネスチームに情報を提供するときに、それらを大まかに工数に変換できます。
既存の回答を読んだとき、私は1つのポイントを逃しました、または少なくともそれは焦点を当てていませんでした。
通常、開発者がリアルタイムの見積もりを提供できない理由は1つあります。これは、ソフトウェア開発自体の複雑さです。実際に開発を開始する前に、見ることができなかった厄介な詳細にいつでも入ることができます。
この問題はかなり古く、F。ブルックスの有名な本「神話の男の月」で読むことができます。
この問題の解決策として、SCRUMのようなアジャイル手法が開発されました。これらの方法はすべて、ストーリーポイントやTシャツのサイズなど、複雑さに基づいた相対的な見積もりを使用しています。相対的な見積もりを与えることは問題ではなく、解決策です!
ここでやって来る唯一の方法は、顧客とのコミュニケーションを改善することです。たとえばSCRUMでは、各スプリントの後に迅速なフィードバックを提供できます。
速度(時間あたりのストーリーポイント)を測定することもできます。しかし、私の経験では、タスク間の違いが大きすぎるため、これはあまり役に立ちません。
この状況では、クライアントは、機能を完了するのにかかる時間に基づくコストの最良の見積もりに応じて、機能を必要とするかどうかを(かなり合理的に)決定したいと考えています。
工数での見積もりを拒否することができます。彼らは再び尋ねて戻ってきて、あなたをますますいらいらさせ、最終的にはあなたをその見積もりをしてくれる人に置き換えるかもしれません。
だからあなたがすべきこと:あなたの原則を忘れて、あなたができる最善の答えを与えてください。それを行う前に、みんなが見積もりが何であるかを理解しているかどうかを確認してください。良い見積もりでは、実際の時間は見積もりよりも多くまたは少なくなる可能性は50%です。彼らがこれを理解しているなら、あなたの最善の見積もりを与えてください。誰かを喜ばせるには低すぎる数ではありません。彼らはそれに基づいて決定を行うために正確な数を求めています。見積もりが約束または締め切りであると考える人のために働いている場合は、少なくとも今回は結果を出すことができると90%確信できる数値を与えます。
あなたが決定を下す必要があるビジネスをサポートすることができないなら、あなたは悪いビジネスに身を置きます。
OP:あなたは、その期間にそれが行われると90%確信している週数を私に与えることができませんか?あなたの最良の見積もりが2週間である場合、「4週間」とは言えませんか?本当に?そして、正確さについてまったく尋ねなかった簡単な英文を読むことができませんか?タイヤの製造に切り替えるべきではないと確信していますか?
私の経験から、Tシャツのサイズやストーリーポイントなどの見積もりは、具体的な時代に直接リンクすべきではありません。通常、それらの目的は、コスト効率の高い推定手段を提供するための努力に関連して推定できるタスクの複雑さに焦点を当てることです。
あなたの状況で、チームがtシャツのサイズで見積もりを出す理由は何ですか。時間の範囲として直接見積もりを出す場合にも、同じ利点を得られますか?この場合は、これを実行し、これらをTシャツのサイズにマッピングする必要はありません。そうでない場合は、Tシャツのサイズに固執し、その上で追加の考慮事項を実行する必要があります。
チームがTシャツのサイズで見積もりを出す場合でも、必要な労力または完了までの時間の見積もりを導き出すことが可能です。ただし、これは複雑さの見積もりとは別のプロセスである必要があります。見積もりプロセスの利点を軽減することなくチームに負担をかけることはできないためです。むしろ、特定のTシャツサイズで推定されたタスクが過去に完了するまでにかかった平均時間などの特定の経験値を考慮し、このデータに基づいて予測を提供する予測プロセスと見なされます。
主なポイントは、プロジェクト管理の考慮事項に影響されるのではなく、チームが相対的なサイズの真の理解にのみ基づいて見積もりを出す環境を提供することです。
この方法で分離した場合、見積もりも予測も本当に間違っていることはありません。もちろん、チームは相対的なサイズの見積もりに誤りがあるかもしれませんが、すべての見積もりアクティビティの性質にある見積もり時の知識が限られているため、これは予期されることです。タスクを完了するために実際に必要な労力または時間も予測と異なる場合がありますが、これも予測の性質と確率的な性質にあります。あなたが目指すことができる最高のものは、低い可能性ではなく高い可能性に到達することです。
顧客に伝えることができるのは、同様に複雑さが見積もられたタスクの過去の経験に基づいて、一定の労力がかかること、またはより正確には、一定の労力の範囲に入る可能性を提供する必要があることです。 。ここでは、さまざまな推定手法と統計手法を使用できます。
私の経験から、複雑さの推定の性質と現実的な期待を設定するための予測の努力を明確に伝えようとする困難さを経験することは価値があります。メッセージは、予測に共通の関心を持っているということであり、顧客が十分な情報に基づいて決定できるように努力が必要です。対立する当事者間で努力の見積もりが交渉される状況は避けられるべきです。