コラボすると開発チームがストレス?issueの最適な粒度を模索してます

プロマネ#Inside-ShouldBee
suin
suin
2015年4月20日 投稿

ShouldBeeの野澤です!

ソフトウェア開発のフローをうまく回すことって、思いのほか大変ですよね。課題管理やチケットの粒度を最適に設定することをひとつとっても、いろいろ悩むところです。

僕らの開発者チームは、メンバーが2人から3人になりました。それだけでも、開発者同士のプロトコルとしての開発フローをうまく回しつつ、みんながストレス無くコラボしていくのが、ぐっと大変になったなと感じました。

開発チームからの言葉「コラボするのがストレス」

前回のスプリントレトロスペクティブ(開発チームの反省会)では、開発課題管理についての問題がいくつも提起されました。

  • 依存するissueがあって作業しにくい。
  • 誰がどのissueをやっているか把握できていなかった。
  • GitHubのissueの変化に対応しきれなかった。
  • タスク化が漏れていると誰もやってくれない。
  • ひとつのストーリなのに、リポジトリごとにissueが分かれていて混乱する。
  • 以上のことがあってストレスフル。

僕らはスクラム開発を実践していて、trelloをバックログに、GitHub issuesを開発タスクの管理に使っています。開発チームのメンバは才能のあるエンジニアたちなので、個人で開発していればこうした問題にぶち当たることなく、クリエイティブに開発を進められていたはずです。こうした課題が上がった背景には、スクラムマスターである僕が作成したissuesの粒度が3人という規模に対して細かすぎたこともあり、チームに対して迷惑をかけてしまいました。

issueの粒度は大きく、チェックリストは明確に

チームから上がってきた課題を解決するために、「どのようにしたらissuesがシンプルでクリアになり、ストレス無くタスクをできるようになるか?」について、みんなで知恵を絞りあいました。アイディアが山のように出てきました。

その中で僕らが挑戦してみようと考えているものが次です。

  • One story, one issueの原則を徹底する。issueは1つだけにして複数人でそのissueを叩く。
  • issueに開発チェックリストを作り、チェックリストが真っ当か、漏れがないかなど、開発者たちで簡単にレビューする。
  • 自分がやっているtrelloのカードに自分をアサインする。issueにはアサインしない。

依存するissueがあると、そのissueを待つために作業を中断する必要がありましたが、one story, one issueになればその心配がなくなります。一方で、issueの粒度が大きくなり、実装漏れのリスクが大きくなります。それを回避するためにissuesに開発チェックリストを作り、実装漏れができるだけ無いようにします。

また、issueの内容がころころ変わってしまって、開発者が対応しきれず混乱することがありましたが、今後は開発者が着手する前に、issueの開発者チェックリストをレビューしてもらうので、着手後はissueの内容の変更が少なくなると期待しています。

One story, one issueになると、trelloのカードとGitHubのissueが一対一の関係になります。なので、GitHubのissueに担当者をアサインしなくても、trelloだけで誰がその作業をやっているか、誰も手をつけてないストーリーはどれかが分かりやすくなります。

次のスプリントからは、このやり方で開発チームを回してみようと思います。やっているうちに、新たな課題が発見されると思います。その時には、僕らがどのように解決したかについて書いてみようと思います。