9

私は、アジャイル開発プラクティスを採用する可能性を探っているチームで働いています。

私たちが直面している問題の 1 つは、イテレーション (スプリント) をいつ完了するかを決定することです。

機能のバックログを定義し、それらのストーリー ポイントの見積もりを作成し、最初の 30 日間のスプリントに機能 A、B、D、および F を含めることを決定したとします。スプリントの最後に到達し、A、D、および F を完了しましたが、B は 80% しか完了していません。次のことを行う必要があります。

  1. 時間通りにスプリントを完了するが、機能 B を除外する (残りの作業を将来のスプリントに延期する)

  2. 機能 B を完了するのに必要な時間だけスプリントを延長しますが、次のスプリントは開始しません。

  3. 機能 B を完了し、次のスプリントの作業を開始するのに必要な時間だけスプリントを延長します。

  4. スプリント全体を失敗させ、すべての作業をバンドルして将来のリリースの一部にします。

オプション 1 の問題点は、チームが約束したことを実行していないことです。場合によっては、リリース全体を役に立たなくする (または少なくとも実質的に価値を下げる) ことなく、機能 B を除外することができない場合があります。機能 B がないと、次のスプリントの方向性を導き出すのが難しくなる可能性があります。

オプション 2 の問題は、チームの一部のメンバーがかなりの時間アイドル状態になる可能性があることです。これにより、全体的な生産性が低下します。単体テストを追加したり、機能を磨いたりできるかもしれませんが、それに比例した価値はありません。また、チームのほとんどがアイドル状態である理由を経営陣に説明することは、政治的にも困難です。

オプション 3 は、アジャイルの精神に反しているように思われます。前のスプリントの結果が開発の次の反復を導くことを許可しないことで、次のスプリントを危険にさらすことになります。

オプション 4 は深刻なようで、オプション 1 と 3 とほとんど同じ問題があります。まず、コミットメントが完全に失われています。第 2 に、より多くの機能を後続のリリースにバンドルすると、顧客によるテストと検証が難しくなり、以前のフィードバックに基づいて将来の反復を導くことができなくなります。

4

6 に答える 6

16

もちろんオプション1。昨日の天気に基づいているため、次の反復の速度は遅くなり、次の反復では完了する可能性が高くなります。

スクラムでは、タイムボクシングを行っています。そして、機能する機能のみを提供します。

スプリント計画では、何を提供できるかを見積もっています。顧客は、見積もりの​​一定レベルの不確実性を受け入れるか、チームにリソースが多すぎることを覚悟する必要があります。

次の反復を再び逃した場合は、反復の長さを短くして、個々の特徴のサイズが小さいことを確認してください。

于 2010-01-18T18:24:01.603 に答える
2

通常はオプション1-スプリントを終了します。完了した作業を使用し、未完了の作業をプロジェクトの速度に反映させます。これにより、将来の計画では、経験した困難を考慮に入れることができます。

はい、オプション1は、コミットしたことを完了しなかったことを意味します。しかし、それが起こった場合は、それを認めて、次回はそれを隠すよりもうまく対処することを学ぶほうがよいでしょう。悪いことがすべての人に起こります-重要なことは、私たちが今いる場所からどのように改善するかです。

オプション2-スプリントを延長して未解決の作業を終了し続けることができます。これを行うのは、作業が顧客にとって非常に優先度が高く、顧客が明示的に行うことを選択した場合のみです。スプリントの長さを長くすると、長さが異なるため、スプリントを互いに比較するのが難しくなります。

絶対に、あるスプリントを次のスプリントにマージさせないでください。古いスプリントを拡張するか、完全に新しいスプリントを開始するかのどちらかです。2つのスプリントを互いにマージさせると、実際にはスプリントを実行しなくなり、計画が失敗します...

于 2010-01-22T13:26:28.760 に答える
2

「場合による」と答えてもいいですか？さらに、「定義完了」を投入したいと思います。

私たちはこのような状況に数回遭遇し、状況に応じて異なる方法で対処しました。

私が覚えている限りでは、2 つのケースでスプリントを失敗させました。それは実際には、デモ拒否された種類の失敗でした。機能自体はチームによって完全であると見なされていましたが、未解決の質問が多すぎ、未解決の問題があり、デモ中に出てきた詳細はほとんどありませんでした. すべてをまとめるには数日かかるため、スプリントを失敗させ、すべての未解決の項目を次のスプリントに移しました。新しいユーザー ストーリーの振り返りとスプリントの計画はまだありましたが、コード行の統合は行われず、スプリントは正式に失敗としてマークされました。

別のケースでは、土壇場で見つかったバグが 2 つだけで、さらにユーザー ストーリーからいくつかのバグがありました。総作業量を 3 日間と見積もって、スプリントを延長しました。バグを修正し、いくつかの変更を加え、約 3 日後に 2 回目のスプリント デモを行うには、これで十分でした。

したがって、それが要求されたとき、それはオプション 4 またはオプション 2 のいずれかでした。

ここで考慮すべき点がいくつかあります。まず第一に (ここではスクラムの用語について話している。私は慣れているので、それに最も適したものに置き換えてください)、スクラムマスター、プロダクト オーナー、およびチームを集めて、オプションについて率直に話し合います。進むべき道は一つではないと思います。純粋な方法論に固執することはできますが、実際には、それが常に最善の方法であるとは限りません。ルールを少し曲げることで大きな助けになり、誰にとっても生活が楽になることがあります。

うまく連携している場合は、関係者全員にとって有効なオプションが見つかるはずです。(それができない場合は、根本的な問題がある可能性があります。) 少なくともそれについて話し合ったり、少なくとも理由を説明したりせずに、何かをチームにドロップしないでください。

オプション 3 は、私には最も面倒に思えるので、除外します。

多くの人が、オプション 2 は基本的なアジャイル (またはスクラム) ルールに反すると主張していますが、私は同意しません。スクラムは、ストーリーを減らしたりリソースを追加したりできるのと同じように、必要に応じてスプリントを延長できると明示的に述べています。絶対に必要になるまでやるべきではありませんが、私が知る限り、厳密に本に反しているわけではありません. 私たちがそれを行ったときのベースでは、それは全員にとって最良の解決策でした。なぜなら、わずか 3 日後にスプリントを完了し、全員が結果に非常に満足していたからです。1 週間以上話し合っていた場合、オプション 2 は適切ではありません。

オプション 1 はあまり好きではありません。作業中の実装から中途半端なものを取り出すのは、非常に面倒です。完了したコードとの接触が失われ、率直に言って、統合は苦痛になる可能性があります。作業の仕方によって異なるかもしれませんが、私の経験から、コードラインからコードを取り出すことは、あなたがしたいことではありません。

オプション 4 については、かなり厳しいですが、正しく伝えられれば問題ありません。チームは通常、いつ問題が発生して配信できなくなるかを知っているため、チームにニュースを伝えているわけではありません.

そのため、考慮すべき点がいくつかあります。

  • それをやり遂げるのにどれくらいの時間が必要ですか？1 日か 2 日だけの場合は、スプリントを延長するのが最善の選択肢かもしれません。
  • すでに存在するコードを削除するには、どのくらいの労力が必要ですか? 面倒で時間がかかる場合は、オプション 2 または 4 に解決します。簡単な場合は、オプション 1 が最適です。
  • チームはどう思いますか？プロダクトオーナーはどう思いますか？他の人はどう思いますか？スプリングの失敗はチームの士気に影響を与えるかもしれませんが、そうではないかもしれません.
于 2010-01-26T22:01:19.653 に答える
1

アジャイル プロジェクトでは、「完了の定義」を持つことが重要です。これは、何かを完全なものとして分類するために行う必要があることの小さなチェックリストです。さまざまなレベルの完了があることは珍しいことではありません。

  • ユーザー ストーリー - これには、米国に関連するすべてのタスクを完了する必要がある、すべてのコードがチェックインされ、単体テストに合格して正常にビルドされている、受け入れテストが完了している、などが含まれます。

  • スプリント - これには、スプリントのすべてのストーリーが「完了」したことが含まれる場合があります (上記参照、ふりかえりが開催された、製品所有者が機能のデモンストレーションを見たなど)。

  • リリース スプリント - 以前の一連のスプリントの開発が正常に統合され、回帰テストが行​​われ、機能がライブ環境にリリースされました。

4つのオプションに関しては、それほど明確ではありません。スプリントの失敗、スプリントの延長、および何らかの機能の除外に関して、何をすべきか、何をすべきでないかについて、多くのことが言われ、書かれています。アジャイル プロジェクトでは、特に最初の数スプリントでは、多くの実用主義が必要であることがわかりました。

重要なことは、それを引っ掛けないことです。そこから学び、適応し、先に進みましょう。

于 2010-01-21T22:41:37.373 に答える
0

まず、規則: 反復は固定長のタイム ボックスであり、タイム ボックスの最後で完了します。したがって、これによりオプション 2 とオプション 3 が削除されます。オプション 4 に関しては、反復の異常終了は非常に特殊な状況 (目標を達成できないという確実性、外部イベントによって目標が無効になるなど) で発生する可能性がありますが、これは例外的なイベントのままにしておく必要があります。そして、中止する前に、一般的に他のオプションがあります。そして、これにより、当然の選択肢であるオプション 1 が残ります。

オプション 1 の問題点は、チームが約束したことを実行していないことです。場合によっては、リリース全体を役に立たなくする (または少なくとも実質的に価値を下げる) ことなく、機能 B を除外することができない場合があります。機能 B がないと、次のスプリントの方向性を導き出すのが難しくなる可能性があります。

これが正しい場合、B が A、D、F よりも重要であり、最も重要な項目に最初に取り組まなかったのは間違っています。それは起こるべきではありません。または、A、D、F は実際には非常に重要です。この場合、あなたの仮定は実際には真実ではなく、Bを延期することは大きな問題ではありません。したがって、それが完了しないことに気付いたらすぐに実行し、より小さなアイテムに置き換えることができるかどうかを確認してください.

于 2010-01-22T14:18:57.320 に答える
0

オプション 1 のバリエーションを採用します。機能 B を完了済みのものと完了していないものに分けることができれば、次のスプリントでそれを完了するための改訂された一連のタスクにつながるはずです。出来上がったものは納品されますが、完璧ではありませんが、最善を尽くしてから、優先順位に従って次の作業に取り掛かる必要があります。

スプリントを延長することは、私の心の中で災害のレシピです。機能を完成させるということは、その機能のすべてのバグも解決するということですか? バグがゼロのソフトウェアを見たことがありますか?

スプリントに失敗すると、完璧主義になりすぎます。99% 行われたことは価値がありませんか? 私はそうは思いませんが、非常に高い基準を持ち、かなり要求の厳しい人もいます。

編集: スプリントの過程で明確になる漠然とした要件で最初に機能が提供されることがあります。たとえば、「ユーザーとして注文したい」という機能要求は、スプリントの計画の一環として、またはスプリント中にさらに細分化することができます。どちらの場合でも、機能を含むいくつかのストーリーが行われている場合は、デモが行われている場合にそれらを提示できますし、提示する必要があります。「ここまでです。これを終わらせるための優先順位はどれくらいですか？」と言えるようになることがポイントです。以前は緊急だったかもしれないことが、スプリントの終わりにはそうではないかもしれません。

于 2010-01-18T18:35:54.537 に答える