開発者にとっては馴染み深いと思いますが、課題管理システムに登録する課題の粒度がどうにもバラバラになってしまうことについて、理由を考えてみました。その前に、課題管理システムと書いているのは、JIRAやMantis、Redmineなどのことです。私はJIRAがメインです。
何が起きる？
課題の粒度がバラバラだと何が起きるでしょうか？私の経験では次のようなことが起きます。
- すぐに終わる課題と終わらない課題のバランスが悪い
- たくさん終わったように見えても、軽いものだけで実際にはあまり進捗していない
- 粒度が大きすぎる課題で終わりが見えない。焦りも出てくる。
一般論として、1件の課題には1件のやることがあると思いますが、そのやることは大変なものも簡単なものもあります。これが粒度に違いにつながってくると思います。例えば、あまりにも簡単な課題はいくつかをまとめて一つの課題にしたり、大きすぎる課題は複数の課題に分割するという方法で粒度をある程度、近くすることは出来ると思います。しかし、分かっていても出来ないというのが現実です。この理由と改善案を考えてみました。
原因は何か？
原因を考えてみると、以下ではないかと思います。
課題登録時に課題のゴールの定義が不十分
何を言いたいのかというと、登録する課題が「完了」になる状態がどのようになったときか、というのを詳細にしっかりと書いているかどうかではないかと思います。そして、その状態が重いか軽いか検討が不十分なときに、粒度のばらつきが多くなるのではないと思います。
例: ライブラリを組み込む
例を挙げてみたいと思います。例えば、次の課題を考えてみます。
表題: ライブラリAを組み込む
詳細: 表題の通り
このゴールは「ライブラリA」が組み込まれている状態であると即答できると思います。しかし、この組み込み、軽いですか？重いですか？やることは何ですか？上記の記述からは経験者しか想像つかないのでは無いでしょうか。経験者でも思い違いがあるかもしれません。思い違いも含めて、改善する方法があればもっと良いと思います。
もう少し、「完了状態」を詳しく書いてみます。
表題: ライブラリAを組み込む
詳細: ライブラリAを組み込むため、プロジェクトの設定を変更し、ライブラリAとのリンクを追加する。ライブラリAはビルド済みのバイナリとヘッダファイルで提供されているため、それぞれプロジェクト内のフォルダに配置する。アプリからは必要な機能でAPIを呼び出す。ライブラリの初期化処理と解放処理はそれぞれ、アプリの初期化処理と終了処理にAPIの呼び出しを追加する。
このように書くとこの課題が完了状態、つまり、ライブラリが組み込まれた状態がどの状態かが定義されます。つまり、以下を満たしたときです。
- プロジェクト内のライブラリフォルダにバイナリが配置されている。
- プロジェクト内のヘッダフォルダにヘッダファイルが配置されている。
- アプリの初期化処理にライブラリの初期化処理が追加されている。
- アプリの終了処理にライブラリの終了処理が追加されている。
- 利用する機能からライブラリのAPIを呼んでいる。
ここまでなると、課題の重さが見積もれます。この課題が重いかどうかは「5. 利用する機能からライブラリのAPIを呼んでいる」をどのように見積もるかになります。これが単純に呼べば動くものなら、問題ありません。しかし、呼ぶために、準備処理が必要、専用の画面を実装する必要があるなどが予想される場合には、この課題から分割する必要があるでしょう。「ライブラリAを組み込む」は1から4までを満たすところまで。5については、必要に応じて更に複数の課題に分割するなど、別の課題として登録します。
このように視覚化されると、経験者による思い違いもある程度、防止できると思われます。
やってみてどうなった？
しばらくやってみました。頭で分かっていても、改めて課題管理に詳細を定義するという作業です。課題の重さを自然と見積もっていることが多いのですが、書いてみて視覚的に見ると粒度のばらつきに気が付くことが多くなりました。特に課題が書く前に見積もったよりも、重い場合に気が付きやすくなります。
それと、何をしたかが記録に残るので、コードの変更履歴を追うよりも、問題が起きたときや調査のときに役に立ちます。
