勉強会での経験から1日スプリントを業務に取り入れてみた話

本記事は、 DDD-Community-Jp Advent Calendar 2020の18日目です。

はじめに

今回は勉強会から業務へ派生した話を書こうと思います。

モデリング会では、隔週2〜3時間モブでモデリングやコーディングをしていきますが、 その中で議論が白熱して空中戦になってくると「あれ、今日は何をしたんだっけ」となりやすいところが問題でした。

最近では30分のタイムボックスを意識し、そこでドライバーを交代したり、そこで一旦ふりかえってみて、軌道修正をするタイミングを作るようにしています。

モデリング会の進め方については、こちらの記事をご参照ください。

qiita.com

この勉強会でのタイムボックスを意識したことを社内で話したときに、リーダーが関心を示して下さり、程なくして「1週間から1日スプリントにしてみませんか」といった話になりました。

そのとき、どんな課題があって導入してみたか。

その結果どうなったのか、といった話を書いてみます。

業務での課題

いまのチームでは、既存のレガシーシステムでのデータを、新しいデータベースへお引越しする作業をしています。

件数も多く、中に入っているデータは正規化されていない状態なので、かなり手探り状態です(そもそもガッツリDB設計するプロジェクトが今まで無かったってのもあります)

そんな中で1週間のスプリントで動いていましたが、「プランニングをしたいけど、プランニングするための情報が足りない」といった状況にまで陥っていました。

では、1週間分のプランニングが出来ないのであれば、1日分のプランニングならどうだろう? といった形で、冒頭のリーダーからの話に繋がっていきます。

具体的にどんなふうにやるか

以下のような感じで進めることにしました。

  • 12:15-12:30 スプリントレビュー&ふりかえり
  • 14:00-14:30 スプリントプランニング

スプリントレビューは、実質通常のデイリーとほぼ一緒の感覚です。

昨日までに実施したタスクの実行結果(成果物)をみんなで見て、認識が合っている合ってないを確認。問題がなければ、タスクボードを整理していきます。

その結果を踏まえて、午後から今日1日のプランニングを行っていきます。

1日スプリントに期待すること、不安なことを出し合う

とりあえず、やることになりましたが、各メンバーが1日スプリントに対して、どういう気持ちで臨むのかはハッキリさせて方が良いと思い、

期待することと不安なことを出すことにしました。

これを元に、実際にやってみた後のふりかえりと合わせて確認することによって、客観的に良かったか悪かったかの評価ができることを期待しました。

その中で出たものは以下の通りです。

期待すること

  • 毎日レビューしてプランニングしていくので、方向転換がしやすくなること
  • 1日なので、終わった or 終わってない の確認がしやすくなるのではないか

不安なこと

  • 普段のデイリーと大差が無いのではないか
  • タスクが中途半端な状態にならないか
  • 1日ごとにプランニング、レビューとなるので、ミクロな視点に陥りがちではないか
  • あまり1週間→1日にするメリットが思いつかない

期待よりかは、不安要素の方が強めでした。

ぶっちゃけた話、1週間→1日にしただけで何か違うの? という印象が多かったです。

実際にやってみた結果

2週間ごとに、1日スプリントどう? といったテーマでふりかえりをしてみました。

ふりかえり1回目

  • すごい効果がでたか、というと、そうでもなかった、という意見が多めだった
  • プランニングするタイムボックスを縮めていったので、精度は上がっている感覚
  • 特に期待していた、「方向転換のしやすさ」に効果がでていない(タイミングがなかったかもしれない)
  • プランニングが30分で終わらない問題

ふりかえり2回目

  • 1日スプリントは以下の点では良かった
    • 有休や研修で月〜水を空けることになったメンバーが木曜日から、スプリントレビュー&プランニングですぐに合流ができるのが良かった。
  • プランニング自体がうまくなった気がする

    • 最初は30分に収まらなかったけど、だんだん早く終わるように
  • レビューする時間があんまり取れてない問題

    • プランニングの問題とも言える
  • スプリントレビューが、デイリーをただ伸ばしたというか、強化デイリーに近い

ミクロ視点になりがち問題について

途中で大まかなロードマップを引いたことにより、ある程度解消ができました。

  • 1段階目は、既存の画面に合わせたテーブルを作っていく
  • 2段階目は、それに対してデータ移行用のスクリプトを作る
  • 3段階目は、正規化するための材料として、業務部門とデータモデリングをしていく

みたいな形です。

マイルストーンに近い感じかもしれません。

そこからプランニングで、1日分のタスクへと分解していくようにします。

もちろん、スプリントレビューをしていく中で、何か方向性を変える必要があれば、これらのマイルストーンも変えていきます(今の所その状況はなさそうですが)

結果

1ヶ月ほど経ちましたが、いまのところ1日スプリントは継続をしています。

積極的な反対意見が無かったというのと、メンバーが休む、研修などでいなかったりしたときの合流のしやすさは、良さげな印象を持っています。

特に手探り状態な状況では、スプリントの期間を短めにして、レビューとプランニングのサイクルを短めにするのは1つ有効だと感じています。