*本ブログは ATLASSIAN blogs を翻訳したものです。本文中の日時などは投稿当時のものですのでご了承ください。
*原文 : 2009 年 6 月 10 日、Chris Mountford 投稿 "Atlassian Agile Process Revisited"



2007年に、私はアトラシアンのアジャイルプロセスについて一連のブログ記事を書き、それは驚くほど人気がありました。私たちのアジャイルストーリーを再度お話しするために、私の以前のブログについてアップデートしたいと思います。前回、私はXPのプラクティスを列挙し、それらをアトラシアンのプラクティスにマッピングしました。私は同じことは繰り返したくありません（D.R.Y.）ので、もしアトラシアンのアジャイルプロセスの最初のブログに興味がありましたら、こちらのパート１、２、３、４をご覧下さい。

今日、エンジニアリング部門において、私たちは依然として各開発チーム毎に、そのチームのために、そのチームにより定義されたアジャイルプロセスを持っております。今でも2007年の時と同様にです。変化があったことは、ほとんどが二次的影響のカテゴリーにおいてです。

拡散

この2年間におけるアトラシアンのアジャイルプロセスの最も大きな変更点は、エンジニアリング作業プロセスだけではありません。どの部門も機敏になりつつあるということです。アジャイルプラクティスに関する人気のある本は、手にとって回され、共同使用している本棚に積まれ、また、黄色くて汚い付箋紙がはみ出た状態で、散らかった机の上によく置いてあります。そして今では、皆がそれらを読んでいると思い始めました。アジャイルプロセスがアトラシアンで大量に導入され始めたというもう一つの兆候は、約１年前に、中間管理職（アトラシアンにおいてその時にできたばかり）がスタンドアップを開始したことでした。その後、まるで、クリティカルマス（注：その点を超えると普及率が跳ね上がる）に到達し、スタンドアップミーティングのプラクティスはどこででも見られるかのようになりました。アトラシアンだけではなく、何かを成し遂げたい賢い人々の間では、ミーティングを最小限にするという文化があるように見えます。

それはスタンドアップミーティングだけではありません。カイゼンのように、一部の組織が考慮するものはもちろん、ユーザーストーリー、それは必要ないだろう、うまくいきそうなもっともシンプルなことを行う、繰り返さない、などは今ではアトラシアンの用語集の一部です。私は、この導入を3つの属性に分けました:

1. それが上手くいくのを人々が見ていた。
2. リーダーたちがそれを好きである。
3. それは新しいことではなく、すでに確立された多くの知恵に当てはまることである。

拡大

アトラシアンは、スタッフの数においても、オフィスの数においても、6年間の歴史の中で急速に成長してきました。プロセスは、長距離とタイムゾーンにまたがって拡大させる必要がありました。成長による痛みの良い例は、自動化されたJIRAの一連のテストです。それは素晴らしいケダモノです。ユニットテスト（junit)、機能テスト（jwebunit)、ウェブブラウザードライバーテスト（selenium)、の数は増加しています。また今では、テストを含む、品質保証体制に関する全ての側面を見直し、改善するQA部門があります。

JIRA は複数のOS、JDK、アプリケーションサーバー、データベース、そしてそれらのバージョンをサポートしています。そして、異なるフィーチャーセットをもつ３つのエディション（スタンダード、プロフェッショナル、エンタープライズ）があります。（注：JIRA 4から、エディションは１つになりました）各エディションは、異なる形式で配布されます。EAR/WAR版、アプリケーションサーバーとしてTomcatを含んだスタンドアローン版、そして実行可能なWindowsインストーラー版です。それだけはなく、JIRAはまた異なるウェブブラウザーの複数のバージョンで動作します。

つまり、テストしなければならない多くの組み合わせがあるのです！全ての組み合わせを自動的にテストできれば良いと本当に願っています。現在、私たちの全機能テスト一式は、2時間以上を必要としています。それに全ての組み合わせを乗じると、おそらく完了するまでに数日のCPU時間を要するでしょう。もちろん、ユニットテストは、比較的素早く実行でき、そのグリーンバーにより、十分な自信を持つことができますが、もし、コードのリファクタリングを行った時に、JIRAのユーザーインターフェースがどこか壊れていないか確認したいのならば、少なくとも2時間は待つ必要があります。

数千もの機能テストを実行することは、恥ずかしくなるほど並列な作業負荷として知られていることであり、それ故に、作業を適切に "並列化" して完了できなかったことを恥ずかしく思います。

しかし今では、BambooがEC2クラウド内で動作するエージェントをサポートしており、継続的インテグレーションに利用できるコンピューターリソースの効率を上げることができ、そして、機能テストの待ち時間を、多くのトラブル無しに20分以内におさえられるようになっているはずです。幸運を祈っています。

コードレビュー

"ペアプログラミングは、究極のコードレビュー" はアジャイル実践者の口癖となりました。それは理解できます。それがどのように上手くいくのか分かりますし、そしてペアリングによりコードレビューの便益を感じているからです。私は、次の週にペアプログラミングについてブログを書く予定なので、ここでこの側面について議論することはしません。しかし、コードレビューは、私が知っている伝統的なアジャイルプロセスの一番上にくる、もっとも効果的な、単体の品質保証の方法であることは言っておきたいと思います。

ペアリングに対して、コードレビューもまた同様に多くの利点があります。もちろん、ペアリングを放棄する理由などはありません。何故なら、ペアリングはコードレビューよりももっと多くのものを提供するからです。もしウェブベースのコードレビューツール、、、エヘン、あー、こちらをご覧下さい、あっせんできる製品を私たちは持っているようです、Crucible、、、のようなツールを使用しているならば、主な利点は、もっとも明らかでしょう。レビューアーの人数を増やせますし、異なる場所やタイムゾーンから使用することができます。永続的な記録もまた残せます。そのJIRAチームの、プラクティスとしてのコードレビュー導入度は、おそらく平均的なところでしょう。それが任意に選べるところにおいてです。これは私たちに合っているようです。なぜなら、処方された用量のアジャイルをいつも使えるからです：ただ十分なのです。

GreenHopperのバーチャルインデックスカード

タスクをトラッキングするための紙のカードは、小さくてシンプルで本当に気に入っていますが、いくつかの点において電子バージョンの方が優れていることがあります。分散したチームにおいて使用できるという利点だけではありません。もちろん、私たちはJIRAを大量のバグとフィーチャーリクエストをトラッキングするために使用しています。しかし、GreenHopperプラグインにより、JIRAは完全に、即座のフィードバックをユーザーに提供したり、共同設置されたチームに対してカードにより視認性を提供することができるようになったと感じています。それはまたバーンダウンチャートも作成することができ、それはオフィスのあちこちの大きなLCDスクリーン上で見られるのですが、数が増加してきました。

以上です。私たちは、自身のアジャイルプロセスを気に入っています。アトラシアンに合っているようです。



関連記事

• アトラシアンアジャイルブログ：ペアプログラミングはクリプトナイト！