Pages

2014年2月12日水曜日

エクストリーム・プログラミングとソウル・ミュージック

赤坂や 歩くところに 飲み屋あり

こんにちは、 @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 の価値


XPの価値は以下4つとされています。

Communication(コミュニケーション):顧客とのコミュニケーション、開発者とのコミュニケーション

Simplicity(シンプルさ):後に必要になるかわからないもののための設計をしないこと

Feedback(フィードバック):軌道修正ができること、そのために単体テストを重視すること

Courage(勇気):上記3つの価値が揃ってはじめて、時にはソフトウェアに大きな変更も行い、難局を乗り越える

Communication + Simplicity + Feedback = Courage. これがXPの流儀です。

XPコミュニティ


国内でもコミュニティとメーリングリスト「XP-jpメーリングリスト」で議論されていますので紹介します。
http://objectclub.jp/community/XP-jp/
(※12のプラクティスの和訳はこちらの平鍋健児氏の論文から引用させていただきました)

今回はここまでにします。

エクストリーム・プログラミングとソウル・ミュージック


本日はEXTREMEでもと思いましたが、エクストリーム(究極)なソウル・ミュージックというところで。
雪ですしこんなセクシーな曲でも聴きながら東京の夜を過ごしましょう。


うーんやっぱいいですね。

次回は最もポピュラーなアジャイル・メソッドで、筆者の大好きなスクラム(Scrum)を紹介します。


2014年2月2日日曜日

アジャイル・メソッドとロック・ミュージック

こんにちは、@wd0214です。

今回はアジャイルソフトウェア開発手法について書くことを試みます。

アジャイルの誕生


アジャイルは2000年ごろに生まれたと言われています。

90年代までのソフトウェア・デベロップメントは、予め決められた計画を遵守することで正しいソフトウェアが得られると考えられていました。しかし次第にソフトウェアのオープン化が進み、ビジネス要求の複雑化と要求スピードに対して、従来の開発手法では満足できるソフトウェアを得ることが困難になりました。

まずは作ってみないことには、目的とする事柄に合っているのか、またステークホルダーの要求を満たすソフトウェアなのかどうかさえわからないのです。

筆者は1999年の大晦日、KDD新宿本社ビルで2000年対応のため年越しで仕事をしていました。
「だいたい2000.1.1に問題が起こるなら、1999.9.9にすでに起こってるはずだよね。」
C言語のプログラマーならそんな愚痴でもこぼしつつ、万が一に備えて新年を迎えられた方も少なくなかったことでしょう。(結局何も起こらなかったけど

あれから14年程経ちますが、アジャイルはロック・ミュージックと同じくたいていは誤解されています。

考え方は至ってシンプルですが、習得するには非常に困難で、正しい理解と継続的な開発現場での実践が必要です。アスリートが日々自身の身体をチェックし、鍛錬するごとく真摯にエンジニアリングに向かわなければ、本質的に習得することは難しいと思われます。

ニワトリとブタ


アジャイルでは次のような「ニワトリとブタ」の寓話が有名です。


ニワトリとブタがいた。ニワトリは「さあ、レストランでもやろうよ」と言った。ブタはよく考えてから「レストランのメニューは何にしようか」と言った。ニワトリは答えた。「ハム・エッグさ」。ブタは言った。「僕は止めておくよ。君は産むだけだけど、僕は切り刻まれるんだよ」

これは、デイリースクラムミーティング(朝会)での参加や発言権について「傍観者としてのニワトリは必要ない」ということへの理解のための喩え話で、シュエイバー・ビードル共著の「アジャイルソフトウェア開発スクラム」(ピアソン・エデュケーション)で紹介されています。

アジャイルの本質


アジャイルはシンプル、ほとんどすべてがこれまでと異なっている

アジャイルの捉え方については、世界中で語り尽くせない様々な意見がありますが、一つ確かなことは

開発現場をよりよくするためには、必ず自分自身がソフトウェア開発をしなければならない

というところです。一番プロダクトを理解している人自身が開発(コーディング等)を行うことこそアジャイル(俊敏)という意味です。

あなたがエンジニアならなおさらですが、ご興味があれば、上記を踏まえた上で原則を読んでみましょう。

アジャイルソフトウェア開発宣言
http://agilemanifesto.org/iso/ja/

アジャイルソフトウェアの12の原則
http://agilemanifesto.org/iso/ja/principles.html

アジャイル・メソッド


アジャイルと呼ばれるメソッドは下記が有名です。すべてのメソッドは各々異なるチャレンジを持っています。

• エクストリーム・プログラミング(XP)
• スクラム(Scrum)
• ラショラム統一プロセス(RUP)
• リーン・ソフトウェア開発(LSD)
• ダイナミックシステム開発メソッド (DSDM)
• フィーチャ駆動型開発(FDD)
• etc...

あなたならどちらのチームに仕事を依頼しますか?


あなたがプロダクトをビジネスにしたいと考えた時、
「あなたならどちらのチームに仕事を依頼しますか?」

*ウォーターフォール(従来のやりかた)
 大量のドキュメントを納品し、依頼したソフトウェアは最後まで秘密とされるチーム

 *アジャイル
 お客様が一番大事だと考えている順に機能を実装してテスト済みで毎週必ず届けてくれるチーム


  北アメリカとヨーロッパでは企業の14%がアジャイルを採用しており、19%は興味を持っているかすでに計画を立てているようです。

  ▼アジャイルを採用している企業調査(なぜアジャイルを採用したか?)

  1.生産性とタイムツーマーケット(66%)
  2.コスト削減(48%)
  3.品質向上(43%)
 [ForresterResearch,2005] ←古くてスミマセン

  アジャイルへの動機は、これまで同様、ソフトウェアをより早く、より良く、より安く開発することに加え、さらに、高い生産性、高い士気を生み出すことができます。


管理者層に対する最も重要な哲学


例えば、スクラムには「プロジェクトマネジャー」の役割はありません。

アジャイルではリーダーシップとマネジメントは全く異なったものと捉えており、これまでソフトウェアエンジニアに指示をして開発をすすめていた管理職の方は、アジャイルを導入する際にまずこの部分でつまづくと思われます。前述したように自身でソフトウェア開発をしないスタッフはスクラムチームのメンバーに入ることは(原則では)できません。

その意味で、アジャイル、スクラムの価値、原則、プラクティス (管理者層に対する最も重要な哲学)は、

• ビジョンとチャレンジをチームに与えるが、チームが目的を達成するための具体的なステップを与える訳ではない

• 「ここに私たちの欲しいものがある、どうやってそれを成し遂げるかは自分でみつけてくれ」というアプローチ

• 自己組織的なプロジェクトチーム

• 信頼こそがコラボレーションの基礎であり、個々の約束を果たすことが信頼関係を構築する基本である

深く、いいですね。今回はここまでにします。

アジャイルとロック・ミュージック


ロックってほんと最高ですよね。
アジャイルが生まれた頃のロック・ミュージックを一曲紹介します。



やっぱかっこいいですね。

筆者は世の中で一番かっこいいのはバンドマンだと思います。
Bobbyみたいにガリガリにダイエットして、熱唱していきたいところです。

本当に好きなことをやるのが一番、それが一番アジャイルな人生だと思います。

次回からは一つ一つ、アジャイル・メソッドを紹介していきたいと思います。