• ホーム
• ソフトウェア工学
• プログラミング

エクストリーム・プログラミング (XP)

XP とは

エクストリーム・プログラミング (eXtreme Programming: XP) は，Kent Beck氏らが考案し提唱しているソフトウェア開発手法である． XP は，従来のウォーターフォール型の開発方法論と比較して，開発の初期段階の設計よりもコーディングとテストを重視しており，各工程を順序立てて積み上げていくよりも常にフィードバックを行って修正・再設計していくことに重点を置いている．

XP は次のようなケースのソフトウェアの開発に向いた手法とされている．

• プロジェクト規模が比較的小さい (10人程度位まで)．
• 要求仕様が最初は明確でなく，開発中に変更される可能性が高い．
• 明確な顧客があり，プロジェクトに積極的に関与させることができる．
• 開発環境の充実や開発技術が高く，変更コストを下げることができる．

XP の原則

システムを開発する上では，次の 4つの変数が重要となる．XP は，これらの相反する項目のバランスを採りながら開発する手法である．

• コスト
• 時間
• 品質
• スコープ (顧客がプログラムを提供された時点で，機能を支障なく利用できる範囲)

• 4 つの価値
  XP では，開発チームが共有すべき 4つの価値が存在する．
  • コミュニケーション
    顧客，間発メンバとの意思の疎通
  • シンプル
    Simple is best. シンプルな設計，シンプルなコーディング．
  • フィードバック
    頻繁なテスト，新たな要求や変更にはすみやかに対処
  • 勇気
    種々の場面で短時間に判断する意思と行動
  
  これらに，"尊重" が加えられ，現在 5 つの価値になっている．
• 5 つの基本原則
  4 つの価値を次の 5つの基本原則として具体化する．
  • 素早いフィードバック
    勇気を持って素早くフィードバック
  • 単純さの採用
    熟慮されて設計された単純なシステム
  • インクリメンタルな変更
    小さな単位で，継続的にリリース (リスクマネジメント)
  • 変化を取り込む
    短期間でリリースできる単位で開発，変化する要求に柔軟に対応
  • 質の高い作業
    質の高い環境で開発
  XP では，この基本原則をもとに XP を開始するのに最適と考えられる経験に基づいた具体的な実践項目 (プラクティス) を定義している．

XP のプラクティス

開発チームが行うべきプラクティス (習慣，実践) である．これらのプラクティスを実行することが，XPを実行することになる．

初期には以下に示す 12のプラクティスであったが，その内容をより理解しやすくするための改定が数度行われている．プラクティスの追加と対象者の立場による分類(共通，開発者，管理者，顧客）であある．しかし，本質的な内容や理念は変わってはいない． これらのプラクティスは，固定的，強制的なものではなく，また各プラクティス間には相関関係がある．

• 計画ゲーム (Planning Game)
  短時間で大まかな計画を立て，あらゆることが明確になるに従い，それをさらに精密化していく．
  • 開発者
    
    • 1 つのストーリーを開発するのにかかる時間の見積もり
    • さまざまな技術オプションを使用する際のコストの推定
    • チーム編成
    • 各ストーリーのリスクの評価
    • 1 つの反復工程における，ストーリー開発の順序 (リスクの高いものから始めることにより，リスクを軽減できる)
  • 顧客
    
    • 目標範囲 (あるリリースに対するストーリー設定と，各反復工程に対するストーリー設定)
    • リリース日
    • 優先順位 (ビジネスにおける有用性に基づき，どの機能を先に開発するか)
• メタファ (Metaphor)
  システムのアーキテクチャをメタファ（比喩）として表す．
  • アーキテクチャは，システムのさまざまなコンポーネントとそれらがどう相互作用しているのかを示す図面，つまり開発者に新しいコンポーネントがどこに適合するのかを示す地図のようなものである．
  • システム・メタファは，既存のシステムが機能する方法，新しいパーツが適合する場所，およびそれらがどのような形式を取る必要があるのかを明らかにする．
  • 開発メンバ全員にシステムのイメージを常に意識させ，理解させることが重要である．
• 小規模リリース (Small Releases)
  顧客からのフィードバックを速やかに受け取るため，動作確認が行える単位でソフトウェアを短期間でリリースする．
  • リリースは可能な限り小規模なものにし，その一方で高い価値を持ちビジネスにおける有用性を備えている必要がある．
  • システムは妥当だと判断されれば，すぐにリリースする．これにより，少しでも早くその価値を顧客に提供することができる．
  • 小規模なリリースによって，開発者は何が顧客のニーズを満たしていて，何がそうでないのかに関して具体的なフィードバックを得ることができる．このようにして得たその教訓を次のリリース用の計画に含めることができる．
• 週40時間 (40-Hour Week)
  
  • 「毎朝，フレッシュでやる気にあふれ，毎晩，疲れて満足している」週40時間労働ではこれが実現できる．40という数字は重要ではなく重要なのは，その信条である（Kent Beck）．
  • 疲れた開発者は通常よりも多くのミスを犯す．その 結果，長期的には標準的なスケジュールに沿って行うよりも作業が遅くなってしまう．
  • たとえ，開発者がもっと長い時間有効に作業することができたとしても，そうする必要はない．
  • 残業は，プロジェクトの問題の解決策ではない．残業はさらに大きな問題の兆候である．
• オンサイト顧客 (On-Site Customer)
  
  • 顧客にオンサイトでストーリーを明確化し，重要なビジネス上の意思決定をしてもらう必要がある．開発者だけでこ れを行うことは許されていない．
  • 顧客にその場で参加してもらうことで，顧客の決定を待たなければならない場合に生じるボトルネックを排除することができる． ここでの狙いは，静的な文書にすべての要件を書くよりも，対面して直接コミュニケーションを取る方が誤解を最小限に抑えるとこができるということである．
  • 顧客にオンサイトで参加してもらうのが考えられる最も良い状況であるが，重要なのは，顧客が，ビジネスの有用性に基 づいていつでもチームに対して質問に答えたり，指示を与えたりすることが可能でなければならないということである．
• シンプルな設計 (Simple Design)
  
  • 変更がないという幻想に基づき，最初の時点で設計を一度に行なうようなことはしてはいけない．日々発生する現実を反映するために設計を変更しつつ，どの時点においても常に正常に機能する最も簡潔な設計を使用するように努める．
  • 正常に機能する最も簡潔な設計とは，以下のような設計である．
    • すべてのテストが正常に実行される．
    • 重複するコードを含まない．
    • すべてのコードに対し，プログラマーの意図を明確に述べている．
    • 可能な限りの少ないクラスおよびメソッドしか含まない．
  • 簡潔な設計とは，可能な限り簡潔でかつ正常に機能するものであり，使用されない余分な機能は含まないようする．
• テスティング (Testing)
  テストはすべての作業の前提となるものである．「テストしていないコードは存在していないのと同じ」と考える．
  • 単体テスト
    
    • 開発者は，コードを作成する際に単体テストを作成する．
    • 開発者は，単体テストによって，そ のシステムがある任意の時点で「動作する」かどうかを確認することができる．
  • 機能テスト (受入れテスト)
    
    • 顧客は，ストーリーを定義した後に，受け入れテストを作成する．
    • 受け入れテストは，開発チームに対しシステムがユーザの希望どおりに動作するかどうかを知らせる．
• 継続的インテグレーション (Continuous Integration)
  
  • 頻繁にコードのインテグレーション (統合) を行う．システムを実行するためのすべての単体テストが終わった後に，一日数回コードをインテグレートする．
  • 従来の方法における作業は，「コードをたくさん作成し，大規模のインテグレーションを行い，その後問題の修正に非常に長い時間をかける」という傾向がある．大規模なインテグレーションは，チームに多くの問題を一度にまとめて提出する．しかも，これらの問題には考えられる原因が数え切れない程ある．
  • インテグレーションを頻繁に行うと，特定のインテグ レーションの障害の原因はより明白になる．問題に遭遇した際，原因の範囲をかなり限定することができる．
• ペアプログラミング (Pair Programming)
  すべての実稼働用コードは，ペアになった 2人の開発者の組によって作成する．ペアプログラミングでは，次のことが言える．
  • すべての設計に関する決定に最低でも 2つの頭脳が関わっている．
  • システムのすべての部分について，最低 2人の開発者が熟知している．
  • その 2人の両方がテストあるいは他のタスクを怠る可能性は低い．
  • ペアを変えることによって，チーム内で知識を広めることができる．
  • コードは常に最低 1人によってレビューされることになる．
• リファクタリング (Refactoring)
  機能を変更することなく，コードを改善する技法である．
  • 開発者がリファクタリングを行うための主な機会は，機能をインプリメントする前と後である．開発者は，既存のコードを変更することによっ て，新しい機能の実装が容易になるかどうかを判別する．また，作成し終わったコードについて，これ以上簡潔にする方法がないかを調査する．
  • リファクタリングは，テストをパスしつつ，開発者が学んだことをコードに反映していくことを促す．これによって，コードをクリーンに保つことができる．すなわち，コードの寿命が長くな り，将来の開発者にもたらす問題が減り，また彼らを正しい方向に導くことができる．
• コードの共同所有 (Collective Code Ownership)
  
  • チームの誰もがコードを改善するために変更を加える権限を持つ．全員がすべてのコードを所有する，すなわち全員がコードに対し責任を持つ．
  • 開発者は，コード所有者を気にすることなくコードを変更することができる．全員が責任を持つという事実により，コー ドが誰にも所有されずに混乱状態が起こることはない．
  • 「壊したら自分で直せ (You break it, you fix it)」
    必ず，すべてのインテグレーションの前と後に単体テストを実行する．もし，何かを壊した場合，それがコードのどの部分であっても，修正するのは壊した人の責任である．
• コーディング標準 (Coding standards)
  コーディング標準を決めて遵守する．XP では，"ペアプログラミング"，"リファクタリング"，"コードの共同所有" のために必須となる．
  • コーディング標準により
    
    • 重要でないことに関するくだらない議論によってチームの気が散ることがなくなり，最大スピードで作業を行うことができる．
    • 他者のノウハウや経験をうまく取り入れることができる．
  • コー ディング標準がないと
    
    • コードのリファクタリングが難しくなる．
    • 必要なときにペアを変更したり，迅速に作業を進めていくことが難しくなる．
  • コーディング標準の目標
    
    • チームの中で誰がどのコードを書いたのか区別がつかなくする．
    • コードが明確に情報を伝えることができるようにするための指針を提供する．
    • コーディング標準はまず単純なものから 始め，その後チームの経験に基づいて徐々に発展させていく．

／