目次
『アジャイル×パターン＝ぼくたちの現場』に行ってきました。mixiの会議室で行われた勉強会です。
床はライトブラウン、フローリング調のビニル素材。スクウェアの白い4人掛けテーブルが並べられ、後ろにはバーカウンターがある、さらにその後ろには様々な自動販売機が並んでいる。奥の壁は上から下までガラス張りになっていて、高所恐怖症の人にはちょっとしたアトラクションとなっている。
この勉強会のベースになっているのは書籍『アジャイルプラクティス 達人プログラマに学ぶ現場開発者の習慣』。そしてその書籍のベースになっているのはIPAの調査報告『非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査』。
IPA関連資料
これらの資料を熟読しましょう。
アジャイル方式の今
アジャイル方式が取り入れられているのは多くが会員向けサービスです。基幹システムの事例は1件でした。
手法としてはスクラムがわずかに多いですが、XPも同じくらい使われていました。
開発プロセスの中で目立つ点としては、大半がデイリースタンドアップミーティングを行っており、大半が反復プロセスとは別にテスト工程を設けていた点が挙げられます。
小規模開発でのアジャイル
小規模開発においては、メンバが少なく十分な担当者がいないなどの問題点があります。今回のワークではこの件について考えることとなりました。解決策としては、必要性の低い役割は切り捨てること、一部の役割を開発者以外の関係者に割り振る、リーダ的存在の人がPO・マスターを兼任するという方法があるという結論に至りました。
これは一種の開発パターンとなっていて、往々にして発生するものです。『アジャイルプラクティス』には45のパターンが記述されていますが、各開発現場には現場独自の特性があるためパターンの一部は変更が必要な場合もあります。むしろIPAの報告書ではほとんどが40-100人の開発現場であるため、『アジャイルプラクティス』を適用する際には大幅に変更が必要かもしれません。
アジャイルのパターン
そこで現場でパターンを作ってしまいましょう、というのがこの勉強会の提言です。パターン作成には下記資料を利用します。上述の小規模開発についてのパターン検討でも利用しました。
個人的にはテストフローをパターン化したいと思っています。
