こんにちは、 @wd0214です。
週末は大雪でしたね。都内でのこんな大雪は20年ぶりというニュースを見かけました。筆者は20年前の大雪の時、父親と二人、神戸・三宮から高速バスに乗って春からの上京のため新宿に部屋探しに来ていました。思えばあれからずっと、実家に戻ることはなく、ここ東京で暮らしています。日本酒でも飲みたくなりますね。
さて、今回は前回に続きアジャイル・メソッドの一つであるエクストリーム・プログラミング(XP)について紹介することを試みます。
エクストリームプログラミング、XPとは
人によって人のために書かれるソフトウェア
エクストリームプログラミングは,Smalltalker として有名な Kent Beckらによって 提唱されているソフトウェア開発プロセス(開発工程)であり、正式にはエクストリームプログラミング(eXtreme Programming)、略してエックスピー(XP)と呼ばれています。
筆者が注目しているXPの利点は下記です。
人間性、人に焦点を当て、人に力を与え、人に利益を与えるなら、自分とチームメイトは、人々が一緒に働き、新しく革新的な方法で問題を解決することに人々を没頭させるようなプロセスを見つけられるようになる。
XPでは、赤ちゃんの歩幅で小さく前進し、それぞれの反復内で小さいサイズの機能を実装、時間が経つにつれ大きな歩幅が成し遂げられます。
XP の特徴
• 5名から10名のプログラマーからなるチームが顧客とともに同じ場所で働く
• 開発は頻繁なビルドもしくは反復形式で行われる
• 要求はストーリーとして明示され、ストーリーにはユーザーが要求した機能性が含まれる
• プログラマーはペアになって開発する。厳格なコーディング規約に従い、彼ら自身で単体テストを行う
• 変化を許容し、要求、アーキテクチャ、設計はプロジェクト活動を通して形作られていく
• 具体的な12のプラクティスが定義されている
では次に具体的な12のプラクティス(技法)を見てみましょう。こちらはどんな開発チームでもすぐに実施できるプラクティスとも言われています。
12のプラクティス
1.計画ゲーム(The Planning Game)
ビジネス優先度と技術的見積により次回リリースの範囲を早急に決めること
2.小さなリリース(Small Releases)
新バージョンを非常に短いサイクルでリリースすること
3.メタファー(Metaphor)
システムの動きを示すメタファーを共有すること
4.シンプルデザイン(Simple Design)
シンプルに設計すること、余分な複雑さは悪
5.テスティング(Testing)
プログラマは継続的にユニットテストを書き、 顧客は機能テストを書くこと
6.リファクタリング(Refactoring)
システムの動作を変えることなくシステムを再設計すること
7.ペアプログラミング(Pair Programming)
コードは2人のプログラマにより一台のマシンでおこなう
8.共同所有権(Collective Ownership)
誰でもどのコードでも修正できること
9.継続的インテグレーション(Continuous Integration)
一日に何回もビルドし,テストを 100% パスさせること
10.週40時間(40-Hour Week)
週40時間以上の仕事はよい結果を生まない
11.オンサイト顧客(On-Site Customer)
顧客をフルタイムでチームに加えること
12.コーディング標準(Coding Standards)
全プログラマがコーディング標準に従うこと
すぐに皆さんのチームでも適用できそうなものがいくつかあると思います。
ここではXPの面白いところ、特にペアプログラミング(Pair Programming)と週40時間(40-Hour Week)のプラクティスが定義されているところに注目したいと思います。
ペアプログラミングは、プログラマー2名が、ドライバーとナビゲーターに分かれて交互にコーディングを行います。プログラマーは一人ひとり違った人間なので、それぞれバラバラのコードを書きます。プラクティスを適用すると、コードは常にレビューされ、可読性の高いプログラミングが行えます。プログラマー同士の知恵を出し合え、テクニックの共有とチームとしての開発力の底上げにもつながります。
近年では「ペアプログラミング合コン」というものもあります。どうでもいい情報ですが筆者は行ったことはないです。
ペアプログラミングのやりかた
また、週40時間(40-Hour Week)というプラクティスでは、
「知的作業には週40時間の労働時間が最適であり、特にXPでは、集中力を高めて効果を生む事を重視しているため、心身ともに健全な状態を保つ必要があり、それ以上の労働は適さず、そのため、計画的に開発スピードの調整を行う」
とされています。
現在では、多くのテストやデプロイの自動化などにより、この部分を週30時間にしたほうが効率が上がるという議論も出てきています。
XPについては「ソフトウェア開発はロボットでなく生身の人間が行うもの」というアジャイルの本質に関わる基本精神が貫かれているところが筆者の好みです。
国内の企業では、なかなかこういったプラクティスを適用するのは困難かもしれません。しかしあなたが意欲あるエンジニアで、本当にチームとしてのスピードと品質を上げたいなら、管理者層やチームを巻き込んでここにチャレンジすることをお勧めします。
XP の価値
Communication(コミュニケーション):顧客とのコミュニケーション、開発者とのコミュニケーション
Simplicity(シンプルさ):後に必要になるかわからないもののための設計をしないこと
Feedback(フィードバック):軌道修正ができること、そのために単体テストを重視すること
Courage(勇気):上記3つの価値が揃ってはじめて、時にはソフトウェアに大きな変更も行い、難局を乗り越える
Communication + Simplicity + Feedback = Courage. これがXPの流儀です。
XPコミュニティ
国内でもコミュニティとメーリングリスト「XP-jpメーリングリスト」で議論されていますので紹介します。
http://objectclub.jp/community/XP-jp/
(※12のプラクティスの和訳はこちらの平鍋健児氏の論文から引用させていただきました)
今回はここまでにします。
エクストリーム・プログラミングとソウル・ミュージック
雪ですしこんなセクシーな曲でも聴きながら東京の夜を過ごしましょう。
うーんやっぱいいですね。
次回は最もポピュラーなアジャイル・メソッドで、筆者の大好きなスクラム(Scrum)を紹介します。