スクラムを実装したいのですが、スプリントの長さを決めることができません。Ken Schwaber は 30 日間が事実上のものであると述べているようですが、方向転換や優先順位の再設定の可能性なしに 30 日間待つことは想像できません。
私たちのプロジェクトは通常、ウォーターフォール方式を使用して 1 ～ 3 か月しか続かないため、スクラムに移行すると微調整の機会が減る可能性があります。
1週間のスプリントを考えていましたが、これはスクラムのマイクロマネジメントのようです。
2 週間のスプリントが理想的ですが、他の人がこれをうまく実装できたかどうか知りたいです。欠点は何ですか？より短いスプリントでチームを管理するのは、より多くの仕事/より少ない仕事/同じ仕事ですか?
ところで... 3 週間のスプリントは奇妙に思えますが、3 週間のスプリントを行うのは誰ですか? なぜそれを4週間にしませんか。;)
私は、1 週間、2 週間、4 週間のスプリントを行うチームで働いてきました。それは本当にあなたの組織に依存しています。私は 1 週間または 2 週間のスプリントを好みます。私が運営している現在のチームは、12 の異なる製品の取り組みを調整しているため、4 週間のスプリントを行っています。すぐに 2 週間の反復に移行したいと考えています。
長さを定義する上で重要なことは、「完了、完了」することです。一部のチームにとって、これは本番環境を意味します。他の人にとっては、内部リリースを使用してニーズを満たすためにビジネスによって検証されることを意味する場合があります. まず、完了、完了を定義してから、それに基づいてスプリントを構成する方法を検討します。理想的には、スプリントの最後にすべてのストーリーが完了していることが理想です。スクラムフォールだけを行っているわけではありません。
私は1、2、3、4週間のスプリントに取り組みました。1週間のスプリントはチームのコミットメントを完了するには短すぎます。2週間のスプリントが理想的です。3週間または4週間のスプリントを実装しようとすると、QAチームを効果的に活用できません。（QAは最初の週により多くのスラックタイムがあります）
私は2週間が好きです。問題に妥当なタイムボックスを強制しますが、強化されたペースで結果を確認できます. 30日は永遠です。Web サイトのように動きの速い製品では、1 週間が適切なリズムである可能性があります。
1週間のスプリントを考えていましたが、これはスクラムのマイクロマネジメントのようです。
はい。ただし、これにより、より多くのスクラムを実行することになります。毎週、スプリント計画、イテレーション デモ、ふりかえりを行うことになります。マイナス面はオーバーヘッドですが、1 か月のイテレーションよりも 1 週間のイテレーションの方が、計画、デモ、および「再検討」に費やす時間が少なくなります。
反復が短いほど、チームはプロセスをより速く学習します。
さて、プロジェクトの種類によっては、1 週間の遅れで価値あるものを達成するのは難しいかもしれません。
忘れる前に、私は3週間の反復を行いません:o)
4 週間の反復を行う場合は、開始されていないタスクを、同じ時間で見積もられたタスクに置き換えることもできます。
プロダクト オーナーは常に、優先順位と方向性を変更する機会を与えられるべきです。SCRUM の目的の 1 つは、変更を受け入れ、製品の所有者に優先順位の責任を持たせることです。そのためには、ビジネス ニーズと時間通りの納品を担当する開発チームを検討します。
したがって、3 週間のスプリントがあるとしても、プロダクト オーナーが (おそらく) スプリントを破る何かを見つけた場合、3 週間待たなければならないという意味ではありません。
まれに、新しい情報や新しい優先順位のために、途中でスプリントを停止して新しいスプリントを作成する必要がある場合があります。
現在、私たちは 30 日間のスプリントを行っており、パイルを達成しています。30 日間のスプリントがうまく機能する理由の 1 つは、計画と見積もりに通常 2 日かかることです (バックログから高レベルのタスクを収集して決定し、高レベルのタスクを取得して分解し、分解されたタスクに見積もりを出します)。タスクを割り当ててから割り当てます)。また、バグ修正とテストのために 2 ～ 3 日を確保しています。
すでに 5 日が経過しているため、2 週間のスプリントを行うと、R&D に 5 日間しか残されません。これまでのところ、30日間は私たちにとって素晴らしいバランスです.
スプリントの長さはプロジェクトごとに異なる場合がありますが、同じプロジェクト全体で一定にする必要があります。最善の方法は、チームにとって最も快適なスプリントの長さを見つけることです。私はスクラムを 2 年間使用しており、現在は 20 日間のスプリントに落ち着いています。
私の経験によると、迅速な成果物と比較的単純なプログラミング (CRUD 操作、単純なグリッドとフォームなど) が必要なプロジェクトでは、2 週間などの短いスプリントに行く方が賢明です。より複雑なもの (フレームワークなど) については、おそらく 4 週間のスプリントなど、より長いスプリントに進む方がよいでしょう。私の現在のプロジェクトは、最後のオプションに傾いています。
しかし重要なのは、チームと製品所有者の両方にとって快適な長さを選択することです。
2 週間 (MF の場合は 10 営業日、MS の場合は 12 営業日) は半月です (通常、1 か月は約 20 営業日です。ギブまたはテイクします)。また、週は日よりもあいまいですが、月よりもあいまいではないため、よりアジャイルな (ギブ/テイクの多い) 開発プロジェクトでは、週の測定単位が適切になります。
しかし、私が最後にスクラムのようなことをしたのは、学校のプロジェクトであり、本当の意味でのスクラムではありませんでした。つまり、10 週間の四半期で 7 日間の週でした。その状況での 2 週間のブロックが本当に気に入りました。多くのことを成し遂げることができると感じましたが、タイムラインと計画を頻繁に調整することができました.