読者です 読者をやめる 読者になる 読者になる

>& STDOUT

主にソフトウェアに関する日々の標準出力+標準エラー出力

アジャイルって何かね?


http://twitter.com/akiyama924/status/21954972499:twitter
(@yumotuyo さんとのやりとりにて)


まったくです。なので、いまわかる”アジャイル”についてまとめてみました。この手の「xxxとは何か?」という命題を扱う記事には、検索で出る程度の定義を集めて整理しひとまず自分なりの解とするだけの記事と、深い経験と実践に基づいて運用を考察し本来どうあるべきかを述べる発展的な記事の2種類がありますが、本編は前者です。

とりあえずwikipedia

アジャイルソフトウェア開発 (アジャイルソフトウェアかいはつ、英: agile software development) は、ソフトウェア工学において迅速かつ適応的にソフトウェア開発を行う軽量な開発手法群の総称である。


そう、ウォーターフォールのように特定のプロセスを指すのではなく、”総称”であるところがポイント。各手法によって強み、弱みが異なるので"総称"してアジャイルを語るのは個人的には違和感がありますが、”総称”する場合の意図するところは、開発プロセスの大分類としての"反復型開発"を指しての事だろうなと考えます。でも、その場合でもアジャイルは"反復型開発"のサブクラスなので、まだストンとは飲み込めきれないなと感じます。


この辺の開発手法は関係が判りにくいので、Wikipediaから読み取れる範囲で図式化してみました。項目によって、アジャイルを反復の子とするか、反復より更に細切れにした別の独立したプロセスとするかの意見が分かれていましたので、こんな形に。



ここまでで、"アジャイル"のインスタンスと他の開発プロセスとの区別ができたので、特に”アジャイル”に分類される開発手法を見ていくことにします。まずは、すべての”アジャイル開発手法”の基盤となる、アジャイル宣言から。

私たちは、ソフトウェア開発の実践
あるいは実践を手助けをする活動を通じて、
よりよい開発方法を見つけだそうとしている。
この活動を通して、私たちは以下の価値に至った。


プロセスやツールよりも個人と対話を、
包括的なドキュメントよりも動くソフトウェアを、
契約交渉よりも顧客との協調を、
計画に従うことよりも変化への対応を、


価値とする。すなわち、左記のことがらに価値があることを
認めながらも、私たちは右記のことがらにより価値をおく。


Kent Beck James Grenning Robert C. Martin
Mike Beedle Jim Highsmith Steve Mellor
Arie van Bennekum Andrew Hunt Ken Schwaber
Alistair Cockburn Ron Jeffries Jeff Sutherland
Ward Cunningham Jon Kern Dave Thomas
Martin Fowler Brian Marick


c 2001, 上記の著者たち
この宣言は、この注意書きも含めた形で全文を含めることを条件に
自由にコピーしてよい。

http://www.agilemanifesto.org/iso/ja/


全てのアジャイル開発手法はこの原則を必ず満たしている、ハズです。また、この宣言の背景にある考え方はこちら


原則と背景を確認したところで、数あるアジャイル開発手法の中から、私がよく聞く、または体験した2つを簡単に紹介したいと思います。この”簡単に”紹介できるかどうかが理解の良いバロメータになると思います。いざ。

XP (eXtreme Programming)

アジャイル=XPぐらいの勢いで語られる事もある代表的な開発手法。

  • コミュニケーション
  • シンプルさ
  • フィードバック
  • 勇気

の4つの”価値”に基づいて、ペアプログラミング継続的インテグレーションなどに代表される12個の具体的なプラクティスの提示によって構成されます。また、プラクティスであるがゆえに一部を抜き出して実験的、あるいは気軽に現場に適用出来る軽快さも人気を集める要因と思われます。ただし、コーディング標準なしでのペアプロや、テスティング無しでのリファクタリングなど、片方が抜けると片方の意味がまったく無くなってしまう、どころか逆に混乱を招く場合もある(特に後者は最悪)ので、抜き出しての適用には充分な注意が必要です。


より詳しく正確に知りたい方は下記平鍋さんの記事がおすすめです。
http://www.objectclub.jp/community/XP-jp/xp_relate/xp-intro


私これ書くまでXPにちゃんとしたプロセスがあるの知りませんでした。そういえばプラクティスに”計画ゲーム”がありましたね。


原典はこちら。

XPエクストリーム・プログラミング入門―変化を受け入れる

XPエクストリーム・プログラミング入門―変化を受け入れる

  • 作者: ケントベック,Kent Beck,長瀬嘉秀,テクノロジックアート
  • 出版社/メーカー: ピアソンエデュケーション
  • 発売日: 2005/12
  • メディア: 単行本
  • 購入: 3人 クリック: 55回
  • この商品を含むブログ (66件) を見る

スクラム

こちらは実際に簡単な研修を受けて、それらしき大規模と中規模のプロジェクトを経験した(している)、最近富みに有名なアジャイル開発手法。スプリントプランニングやストーリーの概念など、プロセス自体はXPと似ているのですが、チームの構成やロール、ツール(バックログ)や会議体が厳格に決められているのがポイント。


プロダクトオーナーが管理するプロダクトバックログなる要件リストをベースとし、スプリントと呼ばれる1,2週間のタイムボックスの中で、プロダクトバックログをその箱の中に収まる大きさに小分けしたスプリントバックログを生成、スクラムマスターとチームメンバーで構成されるスクラムチームがこれに基づいて製品を仕上げ、スプリントレビューで成果の確認と各種バックログの更新を行う、というのが骨格。こちらの図が小気味よくまとまっています。



http://www.scrumalliance.org/pages/what_is_scrum


聴けば聴くほど日本人にはこちらのほうが馴染むのでは、、と思っていたらそれもそのはず。もともと国内外(国内多め)の産業界で適用されていた開発プロセスを日本人が論文として昇華したものが原典だそうです。


というわけで原典はこちら。
http://www.sao.corvallis.or.us/drupal/files/The%20New%20New%20Product%20Development%20Game.pdf

アジャイルの資格?

また、タイムリーな事にアジャイルプロセスの資格認定制度も準備されているようです。Testing,UxDもカバーしているところがイマドキですね。こういう資格試験は少なくとも自分よりは対象に向けた造詣の深い人たちが、本当に共有したい知識を問うもの、と考えるとその獲得の意義は小さくないと思います。
http://www.icagile.org/Certification.html

おわりに

記事を書きながら調べた事でもともとロクに知らなかったアジャイルを多少なりとも知る事ができました。で、これを書いておけば、いつかどこかで「あんたアジャイルの何を知ってるんだ」と問われたときに、あわわあわわとなる事無く、「このぐらいですごめんなさいごめんなさい」。とサクっと言えるポインタが手に入りましたとさ。


また、こちらの記事も併せて読まれる事をおすすめします。


アジャイル勘違い集
http://objectclub.jp/technicaldoc/xp/agile_misunderstanding

アジャイルプロセスはドキュメントを書かない」と最初に言ったのは誰なのでしょうか。
正直、迷惑してます。

↑至言。