レベルエンター山本大のブログ

面白いプログラミング教育を若い人たちに

BLOCKVROCKリファレンス目次はこちら

アジャイルは大変2

前回アジャイルは大変だという話を書きました。
今回は続きですが、そろそろプロジェクトも佳境を超えて安定してきたので、振り返りに近くなりました。

管理単位は粒度を粗くとらえる

管理単位の粒度を粗くとらえておくことが、顧客側・開発側の双方の首を絞めない秘訣です。

ちょっと語弊があるかもしれませんが、機能単位に管理するのではなくユースケース単位で管理するという感じです。
見積もり時点からユースケースドリブンですすめます。

例えば見積は「顧客検索機能」「顧客メンテナンス機能」「見積作成機能」ではなく
「ユーザは自分の担当顧客の情報を閲覧・編集できる」とか、
「ユーザは自分の顧客に対する見積書を作成することができる」というように、
利用用途を中心に割り出した要件をあらゆる管理のベースとして利用します。

このようにちょっと粗めの管理単位を設けておくと、アジャイルらしさが際立ちます。
特徴的なメリットを2つ上げるとしたら、
実装者に、微細部分の決裁権を渡せる
そして
顧客に、要件出しの窮屈さを与えないというのがもう一つのメリットです。

アジャイルといってるのに1個1個の要件の範囲にガチガチに縛られてしまっては、名ばかりアジャイルといえます。
請負でアジャイルやると特にそうなりがち(名ばかりアジャイルになりがち)なんです。

議事録は超重要!時間かけてまとめた方がいい。

アジャイルって、実装命なところがあって仕様書は必要最低限に留めます。
でも、そこで心配になってくるのが言った言わない系とか、忘れてました系、そういえばそんなこと言ってたな系とか。
これを抑止するのは、もう議事録しかないです。

僕らは「アジェンダ兼議事録」という形で、ミーティングの前に予め議題にすることをリストアップしておいて、
ミーティング中に合意事項を、直接議事録に書き込みつつまとめてます。

そのあと、帰社してからも大体2-3時間かけて、ミーティング内での合意事項を整理して、
議事になかった思いとかあいまいさを補完して最後に共有しておきます。

この手間を惜しむと、アジャイルでとても重要な顧客の安心感が損なわれると感じています。
顧客側が安心して進められることがアジャイル請負のメリットだと思うので、仕様書を無くす代わりにしっかりした議事録を書くべきです。

お客さんの理解度と、信頼度と、融通の効き度が、とっても高まります。

アジャイルやってみて感じたのは、「WFのストイックな制約がお客さんをも硬直させてたんだな」と言うことです。

極論すると、
納期と要件と品質のトレードオフ
開発側だけの責務ではなく顧客を巻き込んだチームの責務とすることができます。
もちろん、開発側の責務を全うして全力尽くした上で、信頼関係が成り立った上での話になると思いますが、顧客を味方につけ、巻き込む形が広がるほどに融通の範囲も広がります。