解答編

タスクボードの目的は、現在の開発状況の見える化にあります。
その為、以下のような工夫をこらすことが好ましいです。

• タスクをユーザー機能(ストーリー)毎に洗い出す
• タスクの単位を一日で完了する大きさにまでして、着手中に滞留しないようにする
• タスクボードの縦軸をユーザー機能として、ユーザー機能毎のタスクの消化状況を見える化する

　


タスクボードは開発状況を見える化する為、個々の開発要員の作業状況を管理・記録する為に用いてしまいがちです。
しかし、縦軸に個人の名前を入れて、事前にタスクを割り振ってしまうのは間違った使い方です。
個々人のパフォーマンスを明確にしようとし過ぎると、自分の割当分が終わっていれば良いといった発想に陥って、 かえってチームでの協力意識を阻害してしまうからです。

タスクボードの本質は、チームのリスクを開発者全員で共有(=見える化)する点にあります。
チーム全員で助け合いながら全体の問題に対処する為には、チーム内で現状の進捗に関わるリスク認識を共有する必要があります。
その為に有用な情報提供ツールとしてタスクボードを活用してゆきたいです。

タスクボードの活用方法を含めたチームの活性化方法については、 こちらのトレーニングで紹介しています。

リファクタリングを用いることで解決可能です。





リファクタリングとは、機能追加することなく内部構造をキレイにする開発手法です。
維持する機能=インターフェースを自動化テストで固めておいて、テストを壊さないように内部構造に手を入れてゆきます。
変数名を読みやすいものに変えたり長すぎるメソッドを分割したりと、小さい単位から行うことが通常です。

リファクタリングの本質は、守るべきインターフェースを明確にする点にあります。
小さな内部メソッドのインターフェースを守りながら、メソッドの内部実装を修正することもあります。
大きな外部公開インターフェースを守りながら、内部のモジュール構造を修正することもあります。
いずれにしても、どこのインターフェースがどのような機能を提供すべきといった、モジュール間の責任構造を強く意識しながら開発を進めることで、 結果的に変化に強い構造へと成長させることが可能となります。

尚、リファクタリングを実施するにはインターフェースを明確にする他、当該インターフェースを自動化テストで守っておくことが必要となります。
その為、テスト駆動開発のような自動化テストを充実させる開発技法とセットで導入することが重要です。


このようなコンポーネント開発の考え方の詳細については、こちらのトレーニングで紹介しています。