【再考】XPプラクティスの相関関係

SEA関西プロセス分科会「エンピリカルソフトウェア工学の実践 」を聞いてきた。

さかばさんの講演でした。
最も興味があったのは「効果的なXPの導入を目的としたプラクティス間の相互作用の分析」。
内容は、XPのプラクティスの相関関係を調査したもの。

2004年当時、2個のプロジェクトでヒヤリング形式で調査したとのことだが、下記の結果が得られている。

【1】生産性や向上に役立つプラクティス
　ペアプロ
　リファクタリング
　テスト駆動
　シンプルデザイン

　更に、保守性に役立つプロセスは、上記＋アルファとして、
　コードの共同所有
　コーディング規約

【2】要求品質に役立つプラクティス
　短期リリース
　常時結合
　ユーザテスト
　計画ゲーム

【3】コミュニケーションに役立つプラクティス
　全員同席
　計画ゲーム
　ユーザテスト

XPは第2版になって複雑化してきているが、現在のシステム開発をパワーアップさせるプラクティスがまだまだたくさんある。

プログラマの観点から見ると、生産性や保守性の向上は、仕事の効率性そのもの。

今となっては、テスト駆動やリファクタリングは、かなり流通した技術になっている。
今時、テストファーストでないプログラミングスタイルは、逆に怖い。
テストされていないプログラムは、ガラクタと同じ。

ペアプロは現状普及してないけれど、少なくともその効果は皆知っている。
二人の目による作業は、プログラミングでなくとも、本番リリース作業や本番DBメンテナンス作業など、失敗が許されない作業はペアでするのが普通。

プロジェクトリーダーの観点から見ると、ソース管理や即検証できるビルド環境は、必須だ。

と言っても、CVSやSubversionすらない開発チームも今だあるようだが、考えられない。
ソース管理は、達人プログラマーによれば、プログラミングのUndoそのもの。

更に、ソース管理はコードの共同所有につながる。
プログラムは人に見られた方が綺麗になる。
他人のソースを見てアイデアを盗む。
それは、丁度、女の子が人に見られて綺麗になっていくように。

すぐにビルドできない開発チームもあるようだが、今となっては考えられない。
組み込み系は1日1回程度しかビルドできないようだが、Web開発ならば、リリース直前に1日10回ビルドすることも稀ではないだろう。

即ビルドできるならば、すぐに検証できる。
バグが見つかれば、すぐにバグを再現させることができる。
開発者が修正したら、すぐにビルドして、稼動確認できる。
インクリメンタルな開発のためには、常時結合できるビルド環境が必須だ。

だが、チームビルディングと言う観点では、やや力点が劣る。
しかし、今の日本では、チームビルディングに焦点を当てたプロジェクトファシリテーションという技術がある。

毎朝の朝会。
会議術として、ファシリテーショングラフィックなど。
進捗管理にタスクかんばんなど。
週末にふりかえりやKPT。

昨今の開発は、3ヶ月単位にプロジェクトが立ち上がり、初対面同士のメンバーをかき集めて、3ヵ月後にアウトプットを出すというスタイルが多い。
人が集まれば、すぐにチームは機能するものではない。
メンバーのスキルと、チームが必要とする役割が初めて合致して、チームの一体感が生まれる。

XPで最も刺激を受けた概念は「ドライブ」と「ナビゲーション」。

XPは最近は熱気が冷めたように見えるが、それは、XPのプラクティスの一部が実践されてきているからだろう。
やっぱりXPは面白い。