ユーザーストーリーの意図的な過大評価を防ぐ方法は？
私はこれを純粋に仮説的な観点から求めています。
スクラムガイドのスプリント計画会議のセクションによると、「スプリントの製品バックログから選択されるアイテムの数は、開発チーム次第です。開発チームだけが、次のスプリントに対して達成できることを評価できます。」
質問：
- 開発チームがユーザーストーリーを完成させるのにかかる時間を意図的に過大評価するのを防ぐにはどうすればよいですか？
- 製品の所有者および開発チームとの長期的な接触がある場合、これは契約で何らかの違反または契約違反として定義されるべきですか？
- そのような違反を発見する責任があるのは誰ですか？
- 製品の所有者は、そのような違反が発生していることをどのように証明できますか？
読んでくれてありがとう。
Velocity とユーザーストーリーの見積もりの重要なポイントは、開発者がスプリント中に何を終えることができるかの相対的な測定として機能することです。速度 使用しないでください 他のチームと比較します。したがって、開発者がユーザーストーリーを過大評価すると、速度が上がり、 強制されます 次のスプリントでさらに作業を行うか、再度過大評価します。
これは、アジャイル開発者が知っておくべきことです。このシステムに意識的に反対する開発者がいる場合は、アジャイル開発に意識的に反対する人々がいるので、それらの人々は適切に処理する必要があります。
また、製品の所有者IS開発チームの一部です。彼は外部の誰かではありません。彼はチームの一部であり、すべての重要なチーム会議に出席する必要があります。
開発チームがユーザーストーリーを完成させるのにかかる時間を意図的に過大評価するのを防ぐにはどうすればよいですか？
誇りとプロ意識を感じます。真の専門家を雇えば、心配する必要はありません。開発の取り組みを意図的に覆そうとしている人がいる場合、見積もりの問題よりも大きな問題が発生します。
ソフトウェア見積もりの履歴は、過小評価の履歴であり、過大評価の履歴ではありません。私の経験では、開発者が見積もりを埋めていると思っていても、通常はまだ 過度に楽観的 です。現実の半分未満の見積もりを持つプロジェクトは珍しいことではありません。
過小評価よりも、過小評価のリスクが大幅に高くなります。過小評価されたプロジェクトは、コーナーの削減、絶え間ない状況の会議、再計画および再スコープ化によるバグ修正などの「追いつき活動」が指数関数的に増加するため、過大評価された同じプロジェクトよりも時間がかかる可能性があります。マイルストーンのずれも下流に影響を及ぼし、他のチームや顧客のタイムラインに影響を与えます。彼らは、チームの提供能力に対するパートナーの信頼を完全に破壊します。
本質的に、チームが過大評価について心配しているときはいつでも、はるかに大きなリスクは過小評価であることを強調しておきます。これと他の見積もり関連のトピックの素晴らしいレビューのために、私は本が大好きですソフトウェア見積もり：ブラックアートの謎を解く。
アジャイル開発の本質的な原則は、完全な開放性です。したがって、理論的には、少なくとも、スクラムチームがあなたを盲目にするのを止めるものは何もありません。それは、すぐに明らかになるという事実以外にはありません。それと、チームがこの開放性を約束することから始めたという事実、そして人々は基本的に正直であるという事実。
だから（私はこれを純粋に仮説的に尋ねています）：何を止めるのですかあなた地元の菓子屋から盗むのをやめますか？
やや控えめに：チームの見積もりは、スプリントの最後に現実と照合されます。彼らは毎日取締役会に立ち、何に取り組むことを期待しているのかを述べ、翌日、そのコミットメントに対する進捗状況について回答します。これ以上何が欲しいですか？