開明堂 : kaimeido : XPは私たちに何をもたらすのか

XPは私たちに何をもたらすのか

書誌

text	唯野
author	藤本聖,平鍋健児
publisher	ソフトバンク
year	『C MAGAZINE 2002.2』p.51-67

履歴

2002.1.18	読了
2002.1.21	公開
2002.2.14	修正

感想

このところ知名度も上がってきた XP (エクストリーム・プログラミング : eXtreme Programming)についての特集記事。関連書籍もちらほらと出てきているが、(多くの人がそうなのかもしれないけれども)私もまだ様子見という感じの手法である。そのため時期的にもちょうどよく、この入門記事はありがたかった。

感想としては以前から抱いていたのと同じで「要は新規の手法とかいうものではなく、既存のリファクタリングであるとかオブジェクト指向といった諸々の技術の集積」という印象が強い。つまり、それらを系統立てて実際の手法レベルとしてまとめたもの――ということである。

ただ、個人的にいって試験の自動化には強い関心がある。よくいわれるようにソフトウェア開発のコストのうち、その大部分はメンテナンスが占めるわけであるから、そこで更に大きな意味を持つテストの自動化は効果も大きいと思うからだ。また、それを足ががりにすることで、開発サイクルや既存の手法を見直すこと、つまり間接的な XP への接近ができればおもしろいと思う。そんなわけで私の場合は CppUnit の使い方というような辺りから接することができれば...という感じでいる。

なお、この記事では単なる手法の紹介というだけではなく、導入に対する位置付けとして「プログラマが XP で幸せになれるかどうか/プログラマに苦痛ではなく達成感を与えるための」という視点で解説がされている。この手の手法では割とこのような紹介のされ方が多いように思うが、「デスマーチプロジェクトの克服」を推し進めればこれも納得のいくアプローチだと思う。

しかし、後から気付いたことではあるのだが、個人的には実際の記事やこの要約より、文中でも紹介されている eXtreme Programmin FAQ という Web ページががよくまとまっておりおすすめである。(この記事の著者たちによるより詳しい説明がある。)

# 抄録

XP の特徴

開発に対する変化を自然なものとして受け入れる
テストを重視する。これは自動化されコーディングに先立って記述する
初期設計よりもリファクタリングによる再設計の重視
従うべき実践項目(プラクティス)の明確な提示

XP の生い立ち

XP は Smalltalk のコミュニティから Kent Beck と Ward Cunningham によって生まれた。彼らは 1996 に C3 (Chrysler Comprehensive Compensation) というプロジェクトで Martin Fowler らと共に XP を実践し 1999 年に最初の本が出版された。

XP での価値基準

コミュニケーション　顧客を交えた積極的な推進
シンプル　今現在に求められるものだけを実装
フィードバック　テストからコードへの、頻繁なリリースから顧客より
勇気　上記から得られる変更や取捨選択に対する勇気

コアプラクティス

以下の 13 個のプラクティス(経験によって有効性の立証されたテクニック)を極限(エクストリーム)まで利用する。

チーム全体　顧客をチームの一員として含めることによるビジネス価値の取得
計画ゲーム　顧客の提示するストーリーから 2-3 週間単位でのイテレーション計画を立て、それを継続していく
顧客テスト　受け入れテストを定義して自動実行することにより、機能の実現と影響を確認する
小さなリリース　2-3 週間単位でのリリースごとに動くコードを提供する。顧客に最短の時間で最大のビジネス価値を提供し、最大のフィードバックを得る
シンプルな設計　設計は常にシンプルなものを選択する。そのため最低限の機能だけを実装する。「いつか使うコード」はコード量を増やし、可読性とメンテナンス性を損なうということ
ペアプログラミング　コーディングは 2 人 1 組で行う。これによりコードは常にレビューされ品質が上がる。またチーム内での知識共有やスキルアップが自然に行える
テストファースト開発　コーディングより前にテストプログラム(ユニットテスト)を記述し、テストにパスするまでコーディングとテストを行う。ユニットテストはコードとともにリリースされる。先にテストを書くことで機能への必要性が絞り込まれる
設計の洗練　シンプルな設計はリファクタリングによって洗練させていく。また、リファクタリングによってシンプルさを維持する
コードの共有所有　コードの担当者は決めずに全員で全てのコードを共有する。これによりコードが多くの人の目に止まり(=レビューされ)品質が向上し、重複コードが見つけやすくなる
コーディング指標　全コードはプロジェクト標準のコーディングルールに従って記述する。これによってコミュニケーションやコードの共同所有が円滑になる
継続的インテグレーション　1 日に何回もインテグレーション(結合)する。これによってプログラマ間での衝突やエラーを早期に検出できる
メタファ　チームの働きを理解するために、チーム全体がメタファ(隠喩)としてのビジョンを共有する
適切なペース　持続可能なペースを維持する。デスマーチプロジェクトは生産的でもないし高品質にもつながらない

開発の流れ

顧客によるユーザストーリーの提示
↓
ストーリに基づいて数ヶ月単位でのリリース計画と 2-3 週間単位でのイテレーション計画を立てる。
(リリース計画でユーザストーリーのコストを見積り、それに基づいて顧客が実際に盛り込むストーリーとリリース時期を決定する。取捨選択は難易度とビジネス優先度から決定される。一方、イテレーション計画では直近の 2-3 週間(イテレーション)で行うストーリーを決定する。機能分担や実装方法はチーム内のブレーンストーミングによって決定され、作業は 1-2 日で完了できる量単位に行われる。)
↓
繰り返し

全文を読まれる場合はログインしてください

検索