IPA（情報処理推進機構）から出された
「アジャイル型開発におけるプラクティス活用事例調査」の報告とリファレンスガイドを読みました。3月に出てたのにようやく…。
◆アジャイル型開発におけるプラクティス活用事例調査
http://sec.ipa.go.jp/reports/20130319.html
リファレンスガイド
IPAのSEC（ソフトウェアエンジニアリングセンター）が出したものです。
3年ほど前から定期的にアジャイル開発についてのレポートが出ていて、アジャイル開発への機運の高まりを感じます。
【2011年度】
http://sec.ipa.go.jp/reports/20120328.html
http://sec.ipa.go.jp/reports/20120611.html
【2009年度】
http://sec.ipa.go.jp/reports/20100330a.html
事例の多さがすごい
今年のレポートは、日本の開発現場で実践されているアジャイルのプラクティスをまとめたものです。
プラクティスなんて本読めば書いてあるし、「なんとなくこんなものだよねー」という知識だけは持ってるのですが、いざ自分の現場でやってみると上手くいくもの／いかないものが出てきます。
それを何とか工夫して頑張るわけですが、その知恵や経験はとても貴重なものです。
その多くの現場から出たアイデアをパターンとしてまとめてある。すごいです。
それに「日本の現場」ってところが素敵です。
商習慣や人材流動性など、アジャイル開発をやる上でのコンテキストが欧米とは違います。
日本の現場での問題に皆がどうやって立ち向かったのかが書いてあります。これはすごい。
印象に残ったもの
「リリース計画ミーティング」
「いつどのような価値をユーザーに届けるのかという目標がなければ、ただイテレーションを繰り返しているだけになってしまう」という問題をいうのはよくあるし、やっぱりプロジェクトにはマイルストーンが必要。
顧客と開発側で１つの目標に向かって進むのが大事ですね。
K社事例はすごい。
K社事例(20)では、全工程の3分の1をバッファとしており、開発期間の半分を過ぎても進捗が遅れているようであれば、リリース期日から逆算、リリース期日優先で線表を引くようにしている。その結果、あるリリースでは、必要な機能が入らないと判明した時点で顧客との調整を行っている。無理に機能を入れこんだがためにトラブルに発展した過去の体験を、顧客もチームも経験として活かすことができた。最終的には品質を優先する開発を行っている。
「バーンダウンチャート」
バーンダウンチャートはとても大事だと思うのですがあまち有効に使えたことがありません。
短い期間の中だと計測するほどのものでもないので、イテレーション内ではタスクボードだけで十分かな…。
I社事例(15)ではリリース日までのリリースバーンダウンチャートを使って、日々の状況を反映させて残時間ベースで管理をしていた。
リリースバーンダウンをちゃんと使いたい。リリース計画をちゃんと考えて、バッファも含めてチーム全体で状況がわかるようになっておきたいです。
「柔軟なプロセス」
開発には、様々な業務領域（ドメイン）があり、チームメンバーの状況も異なる。同じドメインであったとしても、アジャイル型開発のスタイルやプロセスは現場によって異なる。例えば、同じコードとサービスであっても、サービスのリリース前か後かによってスタイルが変わってくる。
自分たちのプロダクト、組織特性にあわせて開発スタイルを変えていく。大事なのは「何が価値となるか」でしょうか。
アジャイルには「振り返り」がプロセスに組み込まれているので、継続的な改善が可能です。
こういう取り込みができるかどうかは振り返りの空気感によると思います。チームとしては振り返りの質が上がるようにしていきたいです。
「受入テスト」
受入テストは可能な限り自動化するのがよい。
受入テストの自動化はあまり意識していませんでした。そう言われれば自動化は必須のように思えます。
