アジャイル ~壁を乗り越える~【第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. 知識ゼロで Unity をはじめてみた【その2 -キューブを配置-】

  2. Azure Functions に挑戦!(Node.js から SQL…

  3. Raspberry Pi CM4 のセットアップ

  4. どんなもので囲うと電波が弱くなる?Beacon を使った電波強度実験(…

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

  6. LINE BOOT AWARDS 2018 にエントリーしました!