スクラムのスプリントの話で、バックログアイテムの進め方、特に並列作業についての話が良く出ると思います。 並列作業について、良い並列作業と悪い並列作業があるよね、という話を言語化しておきたい。
アンチパターンとしての「並列作業」
よく聞くアンチパターンは以下のような話。 SBIで並列作業を行うのは良くない、という話。
これは以下の理由からだと考えています。
- チームでスプリントで達成したい目標を設定した
- その目標を達成するためには、その足がかりとなるSBIを一つひとつ着実に完了させることが大切
- SBIを直列でなく並列作業で完了させようとすると、直列よりも管理が複雑になる
- 複雑になった結果、タスクが期間内に終わらないリスクが高まる
- なので、並列作業はなるべくやらないほうがいい
並列作業を避ける本質的な理由
大事なのは、目標達成の確率を上げるためには、シンプルなワークフローで進める方が確実性が高いから、という理由だと考えています。
許容できる並列作業パターン１：計画的な分業
同じチームであっても、複数人で並列作業を行うことはよくあると思いますが、それを認知した上で調整していれば問題はない。 バックエンドとフロントエンドで並列作業を行い、同スプリントで実装が結合できることが十分見込まれるなら、それは有効だと思っている。
許容できる並列作業パターン２：ゴール単位での直列
別パターンで、目標が複数ある場合は同一チームで並列作業を行うことはよくあると思います。 私のチームでは、「機能開発」と「基盤保守」といった性質の異なるタスクで並列作業が発生しています。 これによって大きな支障が出たことはありませんでした。 それは、チームで「機能開発」と「保守運用」とで目標が別であり、それぞれについては直列で動いているからだと考えられます。
チームとして見たときは並列作業が発生しているように見えますが、目標ベースでみたときには直列で動いている。 なので、集中して課題解決できるし、それぞれが影響を及ぼさない場合は、効率的にも良い。
まとめ：コンテキストの理解が重要
「並列作業は良くない」という話はよく聞きますが、なぜ良くないのかをきちんと考えれば、良いパターンと悪いパターンがあることがわかります。プラクティスを学ぶときは、その背景にあるコンテキストを認識したうえで理解することが大切だと感じました。
