タスクボードの設計で考えたこと
カユいところ
デイリースクラムをしていると、テストしているような開発しているようなレビューしているようなdoneなような、その全ての要素を含んでいるタスクに遭遇することがあります。
原因として考えうるのは、
① タスクボードのステータスレーンの定義がイケてない
② タスクのdoneの定義がイケてない
のどちらかに収束するんじゃないかと思います。
①の場合は、例えば「開発」と「テスト」というレーンがあり、開発者とテスターが同一人物の場合、その二つのレーンの間を高速で行ったり来たりする場合。
べき論で言えば、都度都度ステータスを更新していくべきですが、まあ面倒なのは想像に難くないんじゃないでしょうか。
あるいは、テストは完了しているけど、何らかの理由でデプロイ待ちみたいな場合。
「デプロイ待ち」のようなレーンがなく、うまく表現できないというケースもあると思います。
②の場合は、例えば「何かのバグを調査する」のようなタスクにありがちで、それらしいあたりはつくけど直してみないとわからない、というようなケースです。
あたりがついたからdoneなのか、直してみての結果をもってしてのdoneなのか(見当違いで直っていない場合も含む)、バグを直したらdoneなのか、その辺りに明確なコンセンサスがないと混乱に陥ってしまいます。
ステータスレーンの設計で気を付けていること
①については、細かくステータスレーンを設定すればより正確なステータス管理が可能です。ただし、開発チームにとってはコストが増します。結局面倒になってうまく運用されないかもしれないです。
先の例では、今あるレーンですでに面倒だという印象をもたれている可能性も結構ありそうです。
開発チームの負担を増やしているのであれば、もっと楽な方法を模索する方がよいかもです。
いっそ、開発者とテスターが同一人物であるなら、テストレーンは開発レーンと一緒にしてしまう、とか。
あるいは、テストレーンにおけるテストの定義は全体テストを指すことをしっかりと示し、そのフェーズがいらないような細かい修正は、テストレーンを経由しない、としてしまっても良いかもしれないです。
「デプロイ待ち」レーンについは、明らかに必要であれば追加してしまえばよいと思います。
それによって、開発者は、テストまでは終わっているよということを表現でき、チームも瞬時に理解できます。
ステータスレーンの設計において意識すべきことは、開発チームにとってストレスがないかとボードを見たときに直感的にステータスが把握できるかなんじゃないかと思います。
doneの定義は全力でクリアにする
②については、スクラムやカンバンの枠を超えて、タスク管理をする上で常に気を張っていくべきケースです。
何をもってして完了とするか、が曖昧である限り、仕事はなかなか終わりません。なぜなら、どこで終わっていいかがわからないし、どこで終わらせるべきかの判断にもリソースを割くからです。
タスクが誰かにアサインされたとき、メンバー内で明確なdoneの定義を気にかけ、確認し合うという文化ができてくるとスムーズに事が運びやすいです。
まとめ
- タスクレーンの設計は、いかに開発しやすく、ステータスを直感的に把握できるかを意識
- doneの定義は明確になっているかチーム内で常に気にかけ合う
それだけでも気持ちよく開発ができるんじゃないかと思います。
最後まで読んでいただき、ありがとうございました！
この記事が気に入ったらサポートをしてみませんか？