こんな"アジャイル開発"、していませんか？：解答編

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

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

　


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

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

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

レトロスペクティブとは、定期的に実施するふりかえり(反省会)のことです。
チームの中の仕事の進め方や手法についてチーム全員で振り返り、改善点を見出していきます。

レトロスペクティブは、不慣れなチームが導入すると目の前の問題点の対策に議論が終始してしまいがちです。
例のような日々の進捗についての問題は、問題が発生した時にすぐにチーム内で相談すべき内容です。
そのような問題点をレトロスペクティブまで話合わないで放置することになっては本末転倒です。

レトロスペクティブでは、チーム内のプロセスや約束事について、改めて「これでよいのか」を話し合うべきです。
より本質的な議論をする為に、KPT法といった会議運営手法を用いることがあります。
KPT法とは、Keep(良かった点)、Problem(問題点)、Try(今後の対策)の略称で、それぞれの項目について話し合う会議運営手法です。
まずKeepについて全員で話し合い、次にProblemについて、最後にKとPの結果からTryを決めます。
それぞれ明確に話合う時間帯を分けるのが大切です。
そうすることでKeepやProblemについては「なぜそうなったか」を深堀りし、より本質的な原因を探り、実効性のあるTryを見つけ出すことが可能となります。

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