イテレーション終了時のダウンタイムを削減するにはどうすればよいですか？
私が働いている場所では、3週間の反復でスクラム駆動のアジャイルを実践しています。はい、反復が短いといいのですが、現時点ではそれを変更することはできません。
イテレーションの終わりに、私は通常、最終日が非常にゆっくりと進むことに気づきます。実際の作業はすでに完了し、受け入れられています。会議は2回あります（回顧と次の反復計画）が、それ以外はあまり行われていません。
チームが最終日まで勢いを維持するためにどのようなテクニックを使用できますか？欠陥に対処すべきですか？とにかく、次のイテレーションの作業を早期に開始しますか？他に何か？
私は最近、同じ質問に少し苦労しています。次のイテレーションから始めていますが、これはよくできたイテレーションの満足感を取り除くものだと思います。
私はそれを開発者に任せるオプションについて考えています、そして「意図が会社に利益をもたらすことである限り」警告があります。
例：
- 何かを学ぶ一日を過ごす
- イノベーションタイムプロジェクトに費やす
- リファクタリングに慣れなかった煩わしいコードを片付けて費やす
- UXを視野に入れて、アプリを適切に実行します（他の方法を実行する時間が見つからないようです）。
プログラマを動機付けるものは何でも、リリースを予定どおりに配信するインセンティブを彼らに与えます。
休みます。あなたはあなたが成し遂げられるはずだった仕事をしたのに、なぜあなたはまだ働いているのですか？
プロセスの変更が可能である場合は、反復を削除し、継続的にリリースして、バックログからストーリーを引き出し続けることを検討してください。でも、少し休むだけの価値はありませんか？
私は同じ問題に気づきました（さらに、2週間のスプリントを使用することもあり、さらに悪化します）。当時（スプリントのレビュー日とスプリントの計画日）にやろうとしていることは、やりたいことはわかっているが、優先度の低いバグ、磨き、またはツールの改善。重要な、しかしセクシーでない仕事をするのに良い時間を作るので、これは実際にはポジティブになることがあります。
ほとんどの場合、ユーザーストーリーはイテレーションの終わりまでに終了しますが、既知のバグのリストとともに、「Nice-to-haves」の長いリストが常に最後にあります。だから人々が物語を終えるとき、いつもやることはたくさんあります。
遡及会議を行うことは王様だと思います。たとえ提起された問題とほとんど同じであるとしても、反復がどのように行われたか、あなたが間違いに気付かない場合、どのように学ぶかについて少し時間を費やすことが非常に重要ですそしてうまくいった事柄。
すべてのバグが修正され、改善すべき点の長いリストが実行され、アクションポイントも達成された場合は、チームを大画面の前に集めて、いくつかのビールと共に構築されました。それほど生産的ではありませんが、実装されているものと実際にどのように機能するかについて話すのはいいことです。
何日かあるなら、新しいことを見つけて、それをいじってみようと思います。それが次の大きなことかもしれません。ただし、日数がある場合は、バックログにユーザーストーリーがあるはずです。
金曜日に土壇場の問題を修正できるように、私たちの反復は木曜日に終了します。しかし、これらの金曜日（2週間に1回）は、私たちのビールの金曜日と一致するので、私たちはそれを非常に落ち着いて取ろうとします。いくつかのマイナーなバグを修正し、何か（本、StackExchange、ブログなど）を読んで、一日の終わりにビールでリラックスしてください。そうしないと、完了感や閉鎖感に到達せず、代わりにハムスターが車輪の中で止まらないように感じます。
私はあなたがいつも正確に時間通りに終了したいのかわかりません。少し早く作業を完了すると、将来のストーリー、機能、機能について考えることができます。それはあなたがよくやった仕事の後に少し休止を与えます、それは早く開始するか、より多くの物語にコミットして、常に仕事を引き継がせるよりもやりがいがあります。
ケンシュワーバーは自分のブログでこう述べています http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/
「神は私たちを助けてくれます。人々は滝を緩め、休息し、創造的になる方法を見つけました。リーンとカンバンにより、それらの隠れた場所は取り除かれました。
私のプロジェクトでは、反復計画時に常にいくつかの追加タスクを選択し、反復のすべてが完了した場合に作業する「ボーナスタスク」にラベルを付けています。実用的には、これらの「ボーナスタスク」は通常、とにかく次の反復で最初に処理されるものですが、心理学的に「ボーナスタスク」と呼ぶと、常により多くの作業が計画されていれば完了できるので、はるかにうまく機能します。
学習時間やイノベーション時間などの他のことについては、通常、各開発者が通常の予想どおりに、そのようなものに最大で週1日費やすことができます。週のどの曜日でもかまいません（つまり、毎週の終わりである必要はありません）。
常に3日早く終了している場合、スプリントに十分なストーリーを計画していないことを示唆しています。
スクラムの目標の1つは、生産性を向上させることです。各スプリントを撃っている場合、これを行うことはありません。
これを解決するには、これまでよりも多くのストーリーを計画してください。以前のベロシティにのみコミットしますが、これらのストーリーが終了したら、追加のストーリーの作業を開始します。さらに完了する場合は、次のスプリントに向けて速度を上げます。念のため、コミットする予定よりも少しだけ計画を立てるか、少なくともいくつかのストーリーを並べてください。
私のチームのすべての開発者は、（すべてのスプリントタスクが完了している場合）スプリントの終わりまでの空き時間を「Google時間」として使用します。
これは、各開発者が会社に利益をもたらす限り、自分のアイデア/プロジェクトに取り組む場所です。このようなシステムを導入することを強くお勧めします。これにより、チーム内の仕事の満足度レベルが本当に向上しました。
これが、かんばんに切り替えた理由の1つです。プロジェクトから離脱し続ける必要がないスクラムのすべての利点。
私はトッドの休みの答えが好きですが、午前中にスプリントの計画と回顧を試み、昼食に間に合うようにそれを達成し、それからチームとして長い昼食を取るという課題を設定します。昼食時にスプリントについての議論を促し、無料で非公式の回顧展を開催します。
その後、アフテヌーンを与えることができない場合（つまり、午後に帰宅するときのように、目的の午後をオフにするのではなく）、技術的な負債に対処します。 ：私の意見）技術的負債に対処し、生活を楽にする方法を正確に理解している場合、技術的負債を回避する必要がある。
私は個人的に回顧は時間を費やすだけの価値がないことに気づきます。通常、いくつかの一般的な繰り返しのテーマ（貧弱なユーザーストーリー、不適切な見積もりなど）があり、これらを問題領域として受け入れ、次に進みます。また、問題が発生したときに、問題が発生したときに対処します（スクラムを採用する初期の段階で傾向がありました）レトロスペクティブを待つのではありません。
今、レトロスペクティブを持つ代わりに、開発者の各ペアは、既存のレトロスペクティブバックログから傑出したアイテムを選び、それに取り組んでいます。
また、スプリントのボーナスアイテムとして機能する継続的な技術債務のバックログも保持します（ビジネスが事前にバックログから何かを実装する準備ができていない場合）。
これはすでに非常に好意的であることが証明されています。その理由は、泡立つだけの微妙な小さなアイテムはすべて、各スプリントに1日分の注目を集めるからです。