日スプリントについて話します。スクラムやってますか私たちのチームではスクラムを外部の協力ももらいながらガッツリ行なっています。日からなので、かれこれ半年ほどスクラムを行なっています。スクラムはいいところも悪いところもあるように感じますが、フレームワークなので適宜適した形でチームに適用していくことが大事だと最近は考えるようになりました。日スプリントについて、導入された経緯と所感などをざつに書いていきたいと思います。サイクルのことを指します。サイクルとしています。月で設定れることが多く、短くすればするほどサイクルの中でスクラムイベントの占める比重が増えていき、チーム全体の作業時間を奪っていきます。ヒットすることでしょう。日を採用しており、製造業とは思えないほどの早さで開発が行われています。日の開発サイクルが実現されるためにあらゆる効率化が行われています。会議を減らすことや、パーツの接続部分の規格を統一する等の...。日の開発サイクルは恐ろしい効率化の上になりったているわけです。日スプリントともなるとより多大な労力が必要になるわけですが、なぜそれが導入されるに至ったかを見ていきましょう。週間スプリントのスプリントゴールの達成に連続して失敗してたことから始まります。スクラムにおいてスプリントゴールが失敗することは基本的に起こり得ないことなのですが、それが連続で起こってしまい、チーム内に「なんだかやばいな・・・」という意識が蔓延していたと思います。チームのふりかえりを通して以下のような課題があがりました。見積もりができていない・見積もり時に想定したタスクを越えた作業をしているチーム内で完成の定義も定めていなかったため人によっては想定しているタスクが大きく違う問題がありました。さんが取り掛かるときに見積もりがずれてしまうわけです。日からでしたが、それまでの間はスプリントの作業中により良い実装が思いついた場合は見積もりを越えて実装のコストが増える場合でも、そちらを優先していました。スプリントに関係ないタスクを優先することがありました。つのタスクをどのぐらいで終えるかの共通化がされていませんでした。行うにしてもどの程度をカバーするのか、既存の部分への影響はどうするのかの意識が共通化されていませんでした。他にも細かい課題は山積されており、これらを解決するいい手段が思いつきませんでした。日スプリントにすることで強制的に小さいゴールを設定して見積もりを小さくしようという魂胆です。スプリントゴールが達成されない場合に達成確率を上げることを考えてしまうと、スプリントに入れるタスクを小さくしたり、スプリントの期間自体を長くしようとしてしまいそうですが、時には逆を行ってみたり、極端にやってみることも問題の解決の糸口になるとこともあります。日スプリントは結果として、見積もりのサイズを小さく正確にし、ゴールの達成に関係ない作業に取り組むことをなくし、テストの粒度を揃えることにつながりました。週間のスプリントに戻っています。日スプリントはゴールの達成率とベロシティの改善を同時に実現しました。日スプリントですが、大変なところあります。スクラムイベントに忙殺されるスケジュール調整が難しい長期的なタスクが難しくなる当然ですが、スクラムイベントに割かれる時間は莫大なものとなり開発する時間を奪います。チームは殺気立ち忙しくなり、それこそラグビーのスクラムのような状態となります。日の中でスクラムイベントを行うことになるので、ステークホルダーにスプリントレビューに参加してもらうのも一苦労です。これは、チーム全体の懸念点で長期的なことやタスクが考えられなくなる傾向がありました。私たちのチームではやってみて良かったと言えますが、みなさんのチームでは状況を見て導入することをお勧めします。