おもに Groovy やアジャイル開発について勉強していることを書き散らしてます。
わたしのひとりごとが、だれかのお役に立てればと…

タスクボードが腐りました

うちのチームでは、タスクボードを使っています。
TODO・Doing・Done と区分けして、ふせんを貼り付けてタスクを管理しています。

アジャイル開発、スクラムといったところではよく使われる手法です。
進捗の見える化だけでなく、チームコミュニケーションの始点・取っ掛かりとしても非常に有効です。

どんどん、ふせんがDoneの方に遷移していく状態になると、チームとして活気が出てきて「今日中に終わらせるぞ」みたいな雰囲気になります。

そのタスクボードですが、先週あたりから腐り始めました。

腐るといっても

どういうことかと言いますと、
まったくタスクボードが使われなくなりました。ふせんもそのまま。

チーム内の数人が更新しなくなったというのではなく、全員です。
それも自然と暗黙的にタスクボードが機能しなくなりました。

チームを取り巻く状況が変わったからです。

状況の変化

これまでは2週間単位のイテレーションで開発をしてきました。
8月に入って、大きなリリースがあり、開発というよりも保守な作業が多くなりました。

リモート開発をやっているのですが、ウチはリモート側です。
リリースしている現場は遠いところにあります。対岸ですね。

よくあることですが、リリース後トラブっています。
ということで、Q&Aやら不具合対応が都度やってきています。

至急やら、緊急やら、最優先やら…無計画ですね。

ということで…

イテレーション計画も立てられず、イテレーションの単位も崩れ、
なし崩し的に日々言われるがままの作業をこなしています。

作業はどんどん増えるし、やろうとしたことの優先度は下がって割り込みばかり。
定時で帰れるかと思ったら夕方に緊急対応依頼で残業。

というわけで、タスクボードが腐ったわけです。

なぜ腐ったのか?

腐った原因を考えてみました。
・主体的に作業を決めたわけではない
計画的な作業ではない
・作業内容が場当たり的なものが多くなる

自分たちが主体的に計画的に作業を決めることができていないというのが
大きな要因だと思っています。

不具合をひとつひとつ直していくことで、確かにソフトウェアの価値は高まるかもしれません。
しかし、それが本当に価値があって、重要度が高く、優先してすべきかという話になると腹落ち度は下がります。

自分たちが本当に直すべきだと思って、タスクを選んでいくこと。優先度を決めること。
不具合対応というのは本質的に場当たり的ですが、その主体性は大切だと感じました。

主体性がなくなれば、見える化する必要も、課題共有する気も失せますよね。
それがタスクボード腐るという形で、ウチのチームは体現してしまいました。

場当たり的でもタスクボードを活用する方法

チケット駆動開発と銘を打っているのであれば、すべての作業はチケット(ふせん)化するのは当然です。
しかし、ウチのチームはそれに近いですが、そこまでというレベルではありません。

すぐに終わるような作業は見える化する必要はないですし、わざわざ貼ってもすぐにDoneになって面倒さが先立ちます。
そのような中で、メンバーにチケット化を徹底させることができるかと…

こういった状況の時にウチのチームとしてどうすべきか?
いま、答えは出せないですが継続して考えてみたいと思います。