反復の終了時にダウンタイムを短縮するにはどうすればよいですか？

私が働いているところでは、3週間の反復でスクラム駆動のアジャイルを実践しています。はい、繰り返しが短くなればいいのですが、それを変更することは現時点では選択肢ではありません。

繰り返しの終わりに、私は通常、最終日が非常にゆっくりと進むことに気付きます。実際の作業はすでに完了し、受け入れられています。いくつかの会議（回顧と次の反復計画）がありますが、それ以外はあまり進行していません。

チームが最終日まで勢いを維持するためにどのようなテクニックを使用できますか？欠陥に対処する必要がありますか？とにかく次のイテレーションの作業を早期に開始しますか？他に何か？

私は最近、同じ質問に少し苦労しています。私たちは次のイテレーションから始めていますが、これによりイテレーションの満足度がなくなると感じています。

「会社に利益をもたらすことを意図している限り」という警告とともに、開発者に任せるオプションについて考えています。

例：

• 何かを学んで一日を過ごす
• イノベーションタイムプロジェクトに費やす
• あなたがリファクタリングに回ることのない迷惑なコードを片付けます
• UXを視野に入れてアプリを適切に実行します（それ以外の場合は時間を見つけられないようです）

プログラマーを動機付けるものは何でも、彼らにリリースを時間通りに提供するインセンティブを与えます。

休みます。あなたは成し遂げられるはずだった仕事をしたのに、なぜあなたはまだ働いているのですか？

プロセスの変更が可能な場合は、反復の削除、継続的なリリースを検討し、バックログからストーリーを引き出し続けるだけです。しかし、少しダウンタイムに値しませんか？

私は同じ問題に気づきました（さらに、2週間のスプリントを使用することもあり、それがさらに悪化します）。その日（スプリントのレビュー日とスプリントの計画日）に私がやろうとしていることは、やりたいことを知っているが、低優先度のバグ、磨き、またはツールの改善。これは、実際にはポジティブになることがあります。それは、そうでなければ時間を作るのが難しい重要でセクシーではない仕事をする良い時間を作るからです。

ユーザーストーリーがイテレーションの終わりまでにほぼ常に終了したとしても、既知のバグのリストと共に、「いいもの」の長いリストが常に最後にあります。だから、人々が自分の物語を終えるとき、常にすることがたくさんあります。

振り返り会議を行うことは重要だと思います。たとえほとんど同じ問題が提起されたとしても、間違いに気付いていない場合は、反復がどのように行われたか、どのように学べばよいかを熟考することが非常に重要ですそしてうまくいったこと。

すべてのバグが完了した場合、アクションポイントとともに、改善すべき事項の長いリストが作成されました。チームを大画面の前に集めて、ソフトウェアをいじってみるといいと思います。いくつかのビールと一緒にビルドされました。それほど生産的ではありませんが、実装されたものと実際にどのように機能するかについて話すのは良いことです。

あなたが日を持っているなら、私は学ぶために何か新しいものを見つけようとし、それで遊んでみようとします。おそらく次の大きなことです。しかし、もし何日かあれば、おそらくバックログにユーザーストーリーがあります

金曜日に土壇場の問題を修正できるように、木曜日にイテレーションを終了します。しかし、それらの金曜日（2週間に1回）はビール金曜日と一致するため、かなり冷静に取ろうとします。いくつかのマイナーなバグを修正し、コンテンツ（本、StackExchange、ブログなど）を読んで、一日の終わりにビールでリラックスしてください。そうしないと、完成や閉鎖の感覚に達することはなく、代わりにハムスターが車輪で止まらないように回転するような感覚になります。

あなたがいつも正確に時間通りに終わらせたいかどうかはわかりません。作業を少し早く完了させることで、将来のストーリー、機能、機能について考えることができます。仕事がうまくできた後、少し立ち止まることができます。これは、早期に立ち上げたり、より多くのストーリーにコミットして常に仕事を引き継ぐよりも、やりがいがあります。

Ken Schwaberは彼のブログhttp://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/で述べています。

「神は私たちを助けてくれます。人々は滝にたるみを持たせ、休息し、創造性を発揮する方法を見つけました。リーンとカンバンにより、隠れている場所は取り除かれました。

私のプロジェクトでは、反復計画の際に、いくつかの余分なタスクを常に選択し、反復のすべてが完了したときに作業する「ボーナスタスク」というラベルを付けます。実用的には、これらの「ボーナスタスク」は一般に次のイテレーションで最初に処理されるものですが、それらを「ボーナスタスク」と呼ぶのは心理学的にははるかにうまく機能し、常により多くの作業を計画してから完了できます。

学習時間やイノベーション時間など、その他のことについては、各開発者に通常の予想されることとして週に1日まで費やさせます。曜日はいつでも構いません（つまり、毎週の終わりにある必要はありません）。

私のチームのすべての開発者は、「Googleタイム」として、スプリントの終了に向けて自由時間を使用しています（すべてのスプリントタスクが完了している場合）。

これは、各開発者が会社に利益をもたらす限り、自分のアイデア/プロジェクトで作業する場所です。このようなシステムを導入することを強くお勧めします。これにより、チーム内の仕事の満足度が本当に向上しました。

3日早く早く終わらせている場合は、スプリントに十分なストーリーを計画していないことを示唆しています。

スクラムの目標の1つは、生産性を高めることです。各スプリントを撃っている場合は、これを行いません。

これを解決するには、これまでよりも多くのストーリーを計画します。前のベロシティにのみコミットしますが、それらのストーリーが終了したら、追加のストーリーで作業を開始します。さらに完了したら、次のスプリントに向けて速度を上げます。念のため、コミットするよりも少しだけ計画を立てるか、少なくともストーリーを並べてください。

これが、カンバンに切り替えた理由の1つです。プロジェクトを中断せずにスクラムのすべての利点。

私は休みを取るというトッドの答えが好きですが、朝にスプリントの計画と回顧を行い、昼食に間に合うように終わらせてから、チームとして長い昼食を取るという挑戦をします。昼食時には、スプリントについてのディスカッションを奨励して、無料で非公式の回顧展を開催してください。

その後、アフテヌーンを配ることができない場合（そして、午後に自分の目標を設定するのではなく、午後早く家に帰るという意味です）、それは開発者を何よりも落胆させるものであるため、技術的な負債に対処します（ソース：私の意見）技術的負債に対処し、人生を楽にする方法を彼らが正確に知っているとき、それらを回避しなければならない。

私は個人的に、回顧展は時間を費やす価値があまりないことを発見しました。通常、いくつかの一般的な繰り返しのテーマ（貧弱なユーザーストーリー、悪い評価など）があり、あなたはこれらを問題領域として受け入れて先に進みます。また、レトロスペクティブ（スクラムを採用する初期段階で行う傾向があった）を待つのではなく、問題が発生したとき/発生したときに対処しようとします。

現在、レトロスペクティブを使用する代わりに、開発者の各ペアは既存のレトロスペクティブバックログから傑出したアイテムを選択して作業します。

また、スプリントのボーナス項目として機能する進行中の技術的負債のバックログも保持しています（ビジネスが事前にバックログから何かを実装する準備ができていない場合）。

これはすでに非常に肯定的であることが証明されており、バブリングを続けるだけの小さなすべてのアイテムが各スプリントで1日分の注目を集めています。

ホワイトボードの設計セッションを行い、今後のスプリントに関する興味深いストーリーの実装アイデアを共有します。計画セッションとは別に、これを行います。計画セッションでは、ストーリーの詳細はまだ軽微であり、ストーリーポイントまたはTシャツのサイズの見積もりによって判断されます。セッションを非公式にして、創造性を奨励します。