スクラム開発（正確にはスクラムチックなアジャイル開発）で、粒度の荒い時代の課題を分割せずにそのまま対応した結果、課題の粒度が大きいことによる問題を実感できたので、それを備忘録として整理しておこうと思います。
開発内容としては、SaaS系のWebアプリケーションで、私はフロントエンドを担当しています。
粒度の大きい課題の定義
一般的には作業開始から2日以内に終わる程度の粒度が好ましいとされます。ベロシティを週次で管理しているのであれば、3日以上かかるとスプリントがずれてムラが大きくなるためです。
ここでは1回のスプリント内で終わらない課題を粒度の大きい課題として定義します。（1課題での対応範囲も最低限考慮してください）私もそこまで厳密に管理しているわけではないので一定雑です。
粒度の大きい課題の問題点
課題が途中で止まる
より優先な課題の差し込み、仕様やAPIの調整など、さまざまな問題が発生して何度も開発を中断する形となりました。
作業の中断が数日であればたいして問題ないですが、開発優先度が低くて数週間、数ヶ月放置することもあります。よほど不要な課題でなければ、なかなか良くないですね笑
課題が終わるまで数週間かかりベロシティがずれる
週次でのベロシティが少しずれるだけならいいですが、例えば月を跨いでしまうと前後の月のベロシティに影響を与えてしまいました。
開発側だけであれば事情は把握できるものの、ベロシティは開発に疎い方にも共有されることがあるため事情を細かに説明する必要性が生まれて大変そうです。（今のプロジェクトは自社プロダクトなので融通が効きますが、クライアントワークの場合はベロシティが開発進捗に対する一定の指標となるので、継続的に課題を消費できるようにすることが好ましいです。）
デイリーMTGで毎日同じ進捗報告となる
デイリーの進捗確認で課題進捗が全然動かない状態となります。内部にチェックリストを別途作成して進捗を見せることはできますが、1週間以上同じ課題に取り組んでいると気が滅入ります。
管理面の合理性だけでなく、精神衛生上も課題の粒度は小さくした方が良いです。
課題間の依存リスクが上がる
開発では、進行中の課題の中で必要な機能やコンポーネントが別の課題で重複していたり、仕様が若干変わって再度調整が必要になることもありました。
粒度が大きいと開発メンバー間の課題でどこに依存関係があるのかも分かりづらく、他の課題が終わっていく中で、コンフリクトや同様のコードが複数箇所に発生しました。本来必要な開発を超えたつらみが出てくる点も要注意です。
コードレビューが大変
粒度が大きいということは、その分変更量が多いということです。また、コードも多数の機能やコンポーネントに分散しているわけなのでコードレビュー時に見るべきポイントがわかりづらくなってしまいレビュワーに大きな負担をかける形になりました。
レビュワーの労力がなるべく書けない形でのコードはもちろん、課題管理から上手く調整していきたいですね。
課題範囲が広くなることで自分でも何をどこまで処理したか管理できず多重確認が発生する
地味に時間がかかったのは動作やコードをチェックしている中で、同じ差分を何度も見返してしまったことです。
適切にコミットで整理できてなかった問題も大きいかもですが、複雑な依存関係のあるコードは頭を整理するのに時間がかかります。そして時間が経つと人は忘れる生き物なので、再度頭を整理する時間が必要です。（多少時間は短縮されはする）
全体として開発効率が落ちる
粒度を大きくして開発効率が上がるなら場合によっては問題ないものの、基本的にはコードの品質と開発効率は落ちるはずです。
粒度を大きく切っているなら、なぜ粒度を大きくしているのかを振り返って、現状の開発組織にそれが適しているのかを改めて考えてみる必要がありそうです。
適切な粒度設計で気をつけていること
最近、適切な粒度設計にあたって個人的に気をつけていることは主に下記の3点です。
- 作業開始から2日以内を目処にPRを出せること
- 課題間の依存関係を考えて車輪を再発明しないこと（自分が開発しない領域も）
- レビューしやすいファイル変更量に収めること（20ファイル目安｜コード量も考慮）
今はリアーキまわりのプロジェクトに入っているので課題は小さ過ぎてもやりづらい部分があるため、ページやコンポーネント単位（モーダル等の機能は別課題）の粒度で切っています。また、BEとの細かな連携もあるため、課題完了にかかる時間は結構前後しますが、変更量的には2日以内でPRを出せるような粒度にしています。
そのため一般的なスクラムとは違ってユーザーストーリーは省略している、ファイルの変更量は多めでも多少許容していたりと、開発しやすさを優先している点には留意してください。なお、厳密なスクラムでは課題はなるべく小さく切ることが好ましいとされています。
その他
粒度を小さくしても課題完了まで数週間かかる場合
開発チームに加わったばかりである、開発経験が浅い場合、課題の粒度を小さくしていても1週間以上の時間を要する場合があるかもしれません。
これについては、全体のベロシティに影響をほぼほぼ与えることはなく、実状を表しているので問題ない認識です。ただ、一般的にはチームのエンジニアの平均的な技術力をベースにストーリーポイントを定めていくので、高度な技術を前提に課題の粒度が決まっているようであれば、一度設計を見直した方が良さげ。
最終、開発組織の中でルールを決める
一般的なスクラム開発の規律はあるものの、それらに厳格に従う必要はなく、それらは開発組織の中で柔軟に定義されるべきです。
スクラム開発が浸透する中で変動するルールもたくさん出てくるので、プロダクト同様改善を続けましょう。
粒度のルールが変更された時にベロシティに与える影響
課題の粒度を変えるとベロシティに影響を与える場合があります。より開発の現状に沿ったベロシティになるのであれば問題ないですが、粒度ルールを調整するタイミングは開発的にキリの良いところにすると良いかも。
とはいえ、開発が進む中で微妙な変化はあったりすると思うので、どう考えるか少し悩んでいるところではあります。
補足として、ベロシティは一定開発組織の進捗度合いやメンバーの評価に使われますが、数値に現れない工数も多いため、あくまで参考とすべきとされています。
最初から粒度を小さくするのは逆に無駄である
プロダクトバックログアイテムは順番に並んでいて、上位のものほど着手するのが早くなります。すなわち下位になればなるほど着手時期が遅くなったり、そもそも着手すらしなかったりします。 当面やらないことをわざわざ小さいサイズに分割してしまうと、プロダクトバックログアイテムの数が膨大になってしまって、並べ替えもできません。そもそも作らないので分割するだけ時間のムダです。
引用：プロダクトバックログアイテムの粒度の考え方
一応の補足として、課題の粒度は最初は大きく設定します。そもそも最初から細かい粒度で課題を設定できるわけではないのと、課題数が無駄に肥大化して管理が困難となるためです。
まとめ
課題の粒度に対する考えを整理する上で色んな記事を読んでいて、改めてスクラム開発の全体感を持って粒度設計の意義の理解が深まりました。
そろそろ開発内容が大きく変わるので粒度設計なども一新されそうですが、失敗を糧に良い開発ができたらと思います。
その他参考
Discussion