はじめに

アジャイルやってます。
この開発手法が一般的になって10年以上経つ認識ですが、まだまだ誤解が多い気がします。
代表的な誤解は、「ドキュメントは作らなくていい」とか「無計画でも大丈夫」とか。
それらの誤解の1つに「アジャイルを適用すれば開発効率が上がる」というものがあります。

開発効率を上げるために

アジャイルには「プラクティス」というものがありますが、プラクティスの適用だけでは開発効率は上がりません。
チームはそれぞれ多様な個性を持つ開発者の集まりです。
境遇も開発内容もチームの人間性も異なります。
ですので、「どんなチームにも必ず効果がある方法」なんて簡単には見つかりません。
プラクティスを適用してから、そのチームに合ったやり方でチームを改善していくことが大切です。
チームを改善するために「KPT」というフレームワークがあります。
今回はその KPT についてお話します。

スプリントの流れ

私たちのチームのスプリントは例えば次の流れになっています。

スプリントの最後には必ず振り返りを行います。
ここで KPT を使っています。

KPT

KPTとは
K・・・Keep → 良かったこと、今後も継続していきたいこと
P・・・Problem → 失敗、問題点、良くなかったこと
T・・・Try → Keep に対するさらなる改善策や Problem に対する対策
の頭文字をとったものです。
以下のような表に貼りつけて、そのスプリントの問題点、反省点を洗い出し、解決策を考えて次のスプリントで実行していきます。

試行例

例えばこんな感じです。
和気あいあいとやっているので、本当はふざけた意見がバンバン出ます。
…が、ここではちょっと猫をかぶって真面目そうなものだけ書きます。

私たちのチームでは、次のような流れで行っています。
(Keep を記入する時間5分)
↓
各人が順番に発表する。
↓
(Problem を記入する時間5分)
↓
各人が順番に発表する。
↓
出てきた Keep と Problem に対して、同じ方向性のものをまとめる。
↓
まとめたもの1つ1つに対して、全員で改善案を出し合う。
この流れをだいたい2時間かけて行います。
しかし、途中雑談も交えたり議論が白熱したりすると、時間を超過してしまうこともあったり…Problem ですね。
振り返りはとても大切なので、しっかり時間を確保して必ず実施します。
改善案がなかなか実現できない場合は別案を考えたりもします。

おわりに

振り返りでチームは改善され、より良い方向に進むことができます。
次回は、アジャイルのアンチパターンについてお話します。
アジャイル～壁を乗り越える～ 【第1回 導入編】
アジャイル～壁を乗り越える～ 【第3回 壁を乗り越える】