-1

私は、アジャイルなアプローチで一貫してかなり成功しているチームで働いています。これは、製品を段階的に構築するための最初の作業である現在のプロジェクトでうまく機能しています。

私たちは現在、これの次の段階に進んでおり、経営陣は、実際の顧客にこれをデモして販売できるようになるまでに、具体的な期限を自分たちで設定することを切望しています。 .

含めたい機能の要素ごとに、かなりよく整理された大きなバックログがあり、これらの個々の機能の優先順位を適切に把握しています。

単純な解決策は、デモ可能な製品を提供するストーリーの最小リストを取得し、それらすべてを個別に見積もり、それらを合計してベロシティと組み合わせて日付を取得し、それからデモを行うことを発表することです。とはいえ、それでは余裕がなく、締め切り時間に近づくと非常に危機的な状況に陥る可能性が高いように思われます。

改善として、進行状況に応じて、偶発的またはボーナスの改善として機能するオプションのストーリーの比率を追加したいと思いますが、どの比率が賢明であるか、またはこれが適切かどうかはわかりません。標準的なアプローチ。

また、バックログ全体を一度に見積もる必要があることも懸念しています。これには非常に時間がかかり、その話にたどり着くまでの数か月でより多くの情報が明らかになる可能性が高いためです。これは見積もりに影響します。

アジャイルな開発プロセスを可能にする期限の設定に対処するための推奨されるアプローチはありますか? 私が見た情報のほとんどは、代わりに期限が決まったときに状況を処理することに関するものです。また、この問題を扱っている関連文献や興味深いブログ投稿にも興味があります。

4

3 に答える 3

2

文献に関して: ソフトウェアの推定に関して私が知っている最良の本は、Steve McConnel 著の「Software Estimation: Demystifying the Black Art」です。それはあなたのケースをカバーします。さらに、見積もりとコミットメント(つまり、設定された期限)の違いについて説明し、最初から 2 番目を確実に導き出す方法を説明します。

于 2014-01-10T06:12:38.780 に答える
1

単純な解決策は、デモ可能な製品を提供するストーリーの最小リストを取得し、それらすべてを個別に見積もり、それらを合計してベロシティと組み合わせて日付を取得し、それからデモを行うことを発表することです。とはいえ、それでは余裕がなく、締め切り時間に近づくと非常に危機的な状況になる可能性が高いようです。これはどうしても避けたいことです。

これは私が過去に使用したソリューションです。最初の見積もりは少しずれるので、リリース日を設定する前に、いくつかの追加のスプリントを使用して余裕を持たせてください。遅れてしまった場合は、たるみで補うことができます。そうでない場合、製品バックログは、必要に応じてリリースに含めることができる追加機能を提供します。ただし、これはチームのベロシティ メトリックに依存します。このメトリクスが現在のチームに対してどれだけ正確であるかに基づいて、スラックを調整してください。ターゲット リリースを取得したら、そのリリースに影響を与える可能性のある既知のリソースの制約があるかどうかを確認するために戻って確認できます。

于 2014-01-09T13:52:47.017 に答える
0

あなたが説明するアプローチはおそらく正しいでしょう。望ましいすべての機能を見積もり、UI 要素に優先順位を付けることができます (投資家と顧客は基本的に光沢のある UI を見るだけなので)。次に、見積もりをスケーリングするという形で、たるみを追加します。現在の生産性と最悪の期間の比率を使用して、悲観的な見積もりを作成します。同じ比率を使用して、より短い見積もりをスケーリングできます (たとえば、見積もりを最小機能セットに合わせるため)。

于 2014-01-09T13:59:35.973 に答える