現在進行形ではありますが、タスクに関しての試行錯誤を書いていこうと思います。
タスクってなんだろう
scrum開発におけるタスクはスプリントバックログを実現するためのものです。スプリントプランニングのときにタスクを設定してスプリントで消化していきます。
というのはわかるのですが、どういったタスクが良いタスクなのかがよくわかりませんでした。
なので、気づいたときにはタスクに囚われていたとおもいます。タスクを順番に消化していけばスプリントバックログが消化できること、順序性はなるべく無くして並列に処理できるようにすることなど、厳密に定義していました。特に気になったのが、「この作業はどうするか」に対して「このタスクでやることにしよう」というような会話が多くなって来たことです。なんだか日本語の言葉遊びをしているように感じました。
タスクを見直す
まずは良いタスクについて考えました。タスクを全て消化するとスプリントバックログが消化できることは良いことのように思えましたが、消化するという感覚が少し気になりました。スプリントバックログが消化できるように作業をタスクとして表現するには、行うべき作業が全て見えていることが理想になります。これは不確実性に立ち向かうアジャイル開発っぽくないなと感じました。タスクを消化しているときにより良いアイデアが浮かんだらどうするかについて考えるとタスクを厳密に計画するのは良いことなのかがわからなくなってきます。これを開発の自由度と呼んでいました。
そこで、タスクを厳密に作成するのをやめ、開発の自由度を高めるためにざっくりと作成するようにしてみました。タスク間の協調や作業の漏れなどはコミュニケーションで補うようにしました。
ここからは、受託開発によるものなのかわかりませんが、言われた作業をこなすことから問題解決にマインドセットをシフトする必要がありました。タスクがざっくりとなることによって何をどのような順番で行うのかといったことから、なぜその作業をするのか、その結果を受けてどうするのかなどを考えながら作業することが新しいことと感じるメンバが多かったと思います。成長につながると思うので良い傾向だと思っています。
また、タスクをざっくりとすることによって、スプリントプランニングの時間が短くなりました。これは良いことです。
さらに、CSM研修を受けたことによって、良いタスクの作成方法がより明確になりました。CSM研修ではタスクは有機的に作成するのがコツだと教わりました。ピンとこない表現かもしれませんが、植物が育つように、タスクを消化するとプロダクトが成長するようなイメージです。 今はセーブポイントとか、レポーティングポイントみたいに言っています。タスクが終わったタイミングで納品可能であることが良いタスクであるということをうまく伝える方法を日々考えているところです。
タスクが終わったタイミングで納品可能であるというのはscrum開発においてすごく相性がいいと思います。scrum開発ではスプリントごとに納品可能な状態を作成します。であれば、作業の最小単位であるタスクも同じであったほうが良いと思います。ただ、良いというだけで必須かというとそうではないのではないかと感じます。
それからどうした
現在もタスクはざっくりと作成しています。リファインメントしたバックログに対して、ざっくりと方針を決めて、重要な通過点になりそうなポイントをタスクとする感じです。各タスクの独立性はモブプログラミングを取り入れたので無視しています。なので、タスクを順番にモブプログラミングで消化していく形で開発しています。
タスクの切り方はすごく難しいです。各メンバ間の認識のズレやタスク消化中の学びなどを考慮して効率よく作業を進められるようなタスクの切り方は、もはや一つの研究テーマではないかとも思います。もしかしたらチームが成熟してメンバのスキルも上がってくれば特に問題なく運用できるようになるのかもしれませんが、今のところだいぶ先の未来な気がしてしまっています。これからも色々実験して、ふりかえってより良い方法を探していきたいと思っています。
