アジャイル ~壁を乗り越える~【第2回 改善のフレームワーク】

はじめに

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

開発効率を上げるために

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

スプリントの流れ

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

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

KPT

KPTとは
K・・・Keep → 良かったこと、今後も継続していきたいこと
P・・・Problem → 失敗、問題点、良くなかったこと
T・・・Try → Keep に対するさらなる改善策や Problem に対する対策
の頭文字をとったものです。

以下のような表に貼りつけて、そのスプリントの問題点、反省点を洗い出し、解決策を考えて次のスプリントで実行していきます。

試行例

例えばこんな感じです。
和気あいあいとやっているので、本当はふざけた意見がバンバン出ます。
…が、ここではちょっと猫をかぶって真面目そうなものだけ書きます。
Keep リハーサルをしていたためレビューの説明がうまく出来た。新規参加のAさんの仕様理解がWikiベースで上手く行った。Problem 機能XXの理解が難しい。(Aさん)開発言語が未経験のため開発効率が良くない。近頃、飲み会が少ない。Try リハーサルをしていたためレビューの説明がうまく出来た。リハーサルの開始時間がギリギリだったため、次回は余裕を持った時間に行う。 機能XXの理解が難しい。 理解するために数学(確率)の知識が必要になる。Wikiに確率の基礎説明を追記する。次スプリント内で確率の説明会を開く。 (Aさん)開発言語が未経験のため開発効率が良くない。 Aさんを含めてペアプロを実施し、一通りのパターンについて技術共有する。 近頃飲み会が少ない。 来週末に実施しましょう!
私たちのチームでは、次のような流れで行っています。

(Keep を記入する時間5分)

各人が順番に発表する。

(Problem を記入する時間5分)

各人が順番に発表する。

出てきた Keep と Problem に対して、同じ方向性のものをまとめる。

まとめたもの1つ1つに対して、全員で改善案を出し合う。

この流れをだいたい2時間かけて行います。
しかし、途中雑談も交えたり議論が白熱したりすると、時間を超過してしまうこともあったり…Problem ですね。
振り返りはとても大切なので、しっかり時間を確保して必ず実施します。
改善案がなかなか実現できない場合は別案を考えたりもします。

おわりに

振り返りでチームは改善され、より良い方向に進むことができます。
次回は、アジャイルのアンチパターンについてお話します。

アジャイル~壁を乗り越える~ 【第1回 導入編】
アジャイル~壁を乗り越える~ 【第3回 壁を乗り越える】

関連記事

  1. ASP.NET MVC で Wijmo を使う – 2

  2. 自宅Wi-Fiお知らせアプリ開発【第二回】 Beacon 探索機能編

  3. Elastic Stack を使った予兆検知結果の可視化 〜異常検知の…

  4. Elastic Stack を使った予兆検知結果の可視化 〜検知した異…

  5. ねぇClova、開発したい 【スキル登録編】

  6. 【家庭で使える!? Beaconアプリづくりにチャレンジ】BLEAD-…