KPTのアンチパターン~XP祭り関西2014のプレ資料 #xpjugkansai
XP祭り関西2014で「KPTによるプロセス改善~あなたはPDCAを回したことがありますか?」を講演する予定ですが、一部の資料が余ってしまったので、プレ資料として公開します。
【参考】
XP祭り関西2014 ~やってみよう!XP~ - 日本XPユーザーグループ関西 | Doorkeeper
XPやScrumなどのアジャイル開発をやった経験がある人なら、KPTと言えばすぐに分かるだろう。
そして、ふりかえりも実際に経験したこともあるだろう。
僕も、プロジェクトファシリテーションの流れから、KPTとふりかえりを実際に試してみた経験がある。
その経験から、PDCAサイクルとはこういうプロセスなのだな、という感覚がつかめたように思う。
そして、周囲のプロジェクトリーダーや部課長などを見ていると、この人はPDCAサイクルを回した経験が無いんだな、と思う時もあった。
そんな人は、チームを動かしたり、もっと大きな組織を動かしたという経験がないのだろうな、と思う。
作業を指示したからといって、人は動くわけではない。
エンジニアのように、技術の専門家に対して、部課長が上から指示を出して、それでシステムが完成するわけではない。
また、そんな人に限って、計画をきちんと作ったとしても、その計画を現場に当てはめて、微調整しながらコントロールしたことがない。
無理やり、チームや組織に当てはめようとするから、現場の人はサボタージュしたり、服従背面の行動をとったりする。
そんな現場では、いわゆる継続的な改善というプロセスが存在しない。
だから、いつまで経っても、チームも組織も成長しない。
同じような失敗を何度も繰り返す。
「これだけ! KPT」にも書かれているが、PDCAサイクルを回すのは至難の業だ。
1ヶ月や3ヶ月という長いスパンでPDCAサイクルを回すのは、たとえ少人数のチームでも、結構難しい。
PDCAサイクルを回した経験がないプロジェクトリーダーや課長が上に立っていたら、もっと最悪だ。
毎日がデスマーチ。
KPTの良さは、PDCAサイクルを自然に回す仕組みが整っていること。
プログラマ上がりで、マネジメントの経験が短い人でも、KPTでチームを回すことは可能だし、簡単にできるのがいい。
但し、KPTには結構コツがある。
そのコツをKPTのアンチパターンとしてまとめみた。
詳細を聞きたい場合、XP祭り関西2014 - XPJUG関西wikiにぜひ聞きに来てくだい。
| 固定リンク
« 「Working In Progress」な WIP Pull Request ~Github-flowの新たな使い道 | トップページ | 【公開】XP祭り関西2014講演資料「KPTによるプロセス改善~あなたはPDCAを回したことがありますか?」 #xpjugkansai »
「Agile」カテゴリの記事
- 法律のケース問題をモデル化するアイデア(2019.02.11)
- Coplienの開発工程の生成的パターン言語を読むpart1(2012.10.11)
- ユーザ機能駆動開発FDDを再考(2011.05.28)
- Redmineプロジェクトの構造とConwayの法則(2011.05.18)
- Conwayの法則~アーキテクチャは組織にしたがう(2011.04.17)
「プロジェクトファシリテーション」カテゴリの記事
- 組織行動で知られている罠(2016.06.21)
- 【公開】DevLove関西2011発表資料「障害管理からチケット駆動開発へ~BTSから始まる進化の歴史」 #devlove0917(2011.09.17)
- アジャイル開発の始め方(2011.03.26)
- アジャイル開発のインフラを支える三種の神器(2010.12.17)
- チケットの粒度と進捗ビューの関係(2011.07.11)
「プロジェクトマネジメント」カテゴリの記事
- クラウド(対立解消図)の考え方(2019.02.03)
- 大規模組織におけるRedmineを巡る諸問題~組織構造がRedmineに与える影響(2016.06.19)
- チケット駆動開発のアイデアがRedmineへ与えた影響は何か(2018.12.10)
- Conwayの法則の拡張版~運用は組織に従う、ワークフローは組織に従う(2015.07.15)
- Coplienの開発工程の生成的パターン言語を読むpart1(2012.10.11)
コメント