アジャイルソフトウェアガイド

90年代にエクストリームプログラミングで肯定的な経験をした後、私はスクラム、クリスタル、DSDMなど、似たようなアプローチに興味を持つようになりました。それらを掘り下げていくうちに、これらの新しい方法論に共通する特徴を抽出しました。それは、予測的な計画よりも適応的な計画を好み、プロセスよりも人を成功にとってより重要視することです。やがてこれらのアプローチはアジャイルソフトウェア開発の旗印の下に集結しましたが（そして私は記事を改訂しました）、私はまだこの記事の視点をアジャイルの本質を理解する良い方法だと考えています。

すべてが始まったわけではないかもしれませんが、この宣言は、ムーブメントに名前と最初の活力を与えました。10年後も、アジャイル手法の本質をとらえています。

アジャイルソフトウェア開発宣言を書いてから10年以上が経ち、アジャイルというミームは私たちが期待していた以上に成功しました。しかし、どんな成功にも、意味の拡散という危険が常に付きまといます。私は、アジャイルソフトウェア開発の本質、つまり予測的計画よりも適応的計画を好み、プロセスよりも人を重視することを説明することで、この病と闘おうとしています。

次に、アジャイルチームがどのように熟練していくかを考える上で効果的な方法であるアジャイル流暢性モデルと、アジャイル技術のより熟練したユーザーになるにつれて一般的に経験する手順について説明します。

ソフトウェア開発プロジェクトでよく議論されるのは、ソフトウェアの品質向上に時間を費やすか、より価値のある機能のリリースに集中するかです。通常、機能を提供するというプレッシャーが議論を支配し、多くの開発者はアーキテクチャとコード品質に取り組む時間がないと不満を漏らします。この議論は、品質を向上させるとコストも増加するという、私たちの共通の経験に基づく仮定に基づいています。しかし、直感に反する現実は、内部ソフトウェアの品質が新しい機能の開発を遅らせる不要なものを取り除き、ソフトウェアを強化するコストを削減することです。

ソフトウェア開発者にとって、自分のマシンで動作するコードを書くことだけでも大変です。しかし、それができたとしても、そこから価値を生み出すソフトウェアへの道のりは長いです。ソフトウェアは本番環境にある場合にのみ価値を生み出すからです。私のソフトウェアデリバリー哲学の本質は、常に本番環境に投入できる状態になるようにソフトウェアを構築することです。私たちはこれを継続的デリバリーと呼んでいます。なぜなら、このソフトウェアがデリバリーできる状態にあるかどうかをテストするデプロイメントパイプラインを継続的に実行しているからです。

エクストリームプログラミングに少し触れたことのある多くの人にとって、XPはソフトウェアデザインの死を要求しているように見えます。多くのデザイン活動が「Big Up Front Design（大規模な先行デザイン）」として嘲笑されるだけでなく、UML、柔軟なフレームワーク、さらにはパターンなどのデザイン技術も軽視されたり、まったく無視されたりしています。実際、XPは多くのデザインを含みますが、確立されたソフトウェアプロセスとは異なる方法で行います。XPは、進化を現実的なデザイン戦略にすることができるプラクティスで、進化型デザインの概念を活性化させました。また、設計者はシンプルな設計方法、リファクタリングを使用して設計をクリーンに保つ方法、進化型スタイルでパターンを使用する方法を学ぶ必要があるため、新しい課題とスキルを提供します。

アジャイル手法に共通する要素の1つは、ソフトウェア開発においてプログラミングを、ソフトウェアエンジニアリングコミュニティが通常行うよりもはるかに重要な役割に引き上げることです。これは partly ソフトウェアシステムの主要な、あるいは主要なドキュメントとしてコードを分類することです。

毎日のスタンドアップミーティングは、特にアジャイルソフトウェア開発において、多くのチームの一般的な儀式となっています。しかし、効果的なスタンドアップと時間の無駄を区別する微妙な詳細がたくさんあります。

今日のソフトウェア開発に携わる多くの人は、ペアプログラミングというプラクティスを耳にしたことがあるでしょう。しかし、業界ではまだ部分的にしか採用されていません。その理由は、ペアプログラミングのメリットがすぐに明らかになるものではなく、中長期的に効果が現れるためです。また、単純に「2人が1台のコンピュータで作業する」というものでもないため、不快に感じるとすぐに拒否する人も少なくありません。しかし、私たちの経験では、ペアプログラミングは共同作業と高品質なソフトウェアにとって不可欠です。

ユーザーストーリーとは、ソフトウェアシステムに求められる振る舞いの塊です。アジャイルソフトウェア開発のアプローチでは、大量の機能を計画のために小さな断片に分割するために広く利用されています。同じ概念を機能と呼ぶこともありますが、最近のアジャイル界隈では「ストーリー」または「ユーザーストーリー」という言葉が主流となっています。

アジャイル手法に関してよくある誤解があります。それは、ユーザーストーリーの作成方法と開発活動における流れに関するものです。よくある誤解は、プロダクトオーナー（またはビジネスアナリスト）がユーザーストーリーを作成し、それを開発者に実装させるというものです。これはプロダクトオーナーから開発者への一方通行の流れであり、プロダクトオーナーは何をすべきかを決定し、開発者はどのようにすべきかを決定するという考え方です。

私が好きな言葉の1つは、「痛いなら、もっと頻繁にやれ」です。一見すると無意味に思えますが、深く掘り下げると貴重な意味が見えてくるという、嬉しい特性があります。

経営陣はメトリクスが大好きです。「私たちは、自分たちがどうしているかを測るための数字が必要です。数字は人々を集中させ、成功を測るのに役立ちます。」このような考え方が一般的です。しかし、数字による管理は、直感に反して問題のある行動につながり、最終的にはより広範なプロジェクトや組織の目標を損なうことになります。メトリクスは本質的に悪いものではありません。ただ、しばしば不適切に使用されているだけです。このエッセイでは、経営陣による従来のメトリクスの使用によって引き起こされる多くの問題点を示し、これらの機能不全に対処するための代替案を提示します。

リモートワークとコロケーションワークは単純な二分法ではなく、チームの分散にはいくつかのパターンがあり、それぞれに異なるトレードオフと、それに適した効果的な手法があります。決定的な証拠を見つけることは不可能ですが、私の感覚では、ほとんどのグループはコロケーション方式で作業する方が生産性が高いです。しかし、分散型作業モデルを使用することで、より幅広い人材プールにアクセスできるため、より生産性の高いチームを構築できます。

Thoughtworksは過去4年間、北米とヨーロッパのソフトウェア開発プロジェクトをサポートするために、インドのバンガロールにラボを運営してきました。オフショア開発の従来のアプローチは計画駆動型の手法に基づいていますが、私たちはアジャイル陣営にしっかりと属しています。ここでは、オフショアアジャイル開発における私たちの経験と教訓について説明します。これまでのところ、私たちはそれがうまくいくことを発見しましたが、そのメリットはまだ議論の余地があります。（この記事は2006年に最終更新されましたが、2011年にオフショア作業を再訪したところ、教訓は依然として有効であり、この記事をさらに大幅に改訂する必要はないことがわかりました。）

一流のエンタープライズソフトウェア開発者を構成する要素について議論する場合、フレームワークや言語の知識、あるいは複雑なアルゴリズムやデータ構造を理解する能力についての話になることがよくあります。私にとって、プログラマー、あるいは開発チームにおいて最も重要な特性の1つは、顧客との親和性と呼ぶものです。これは、開発者がソフトウェアが対処しようとしているビジネス上の問題、そしてそのビジネスの世界に住む人々に対して抱く興味と親密さです。

ソフトウェア開発のスポンサーは、通常、ベロシティや本番環境へのデプロイ頻度などの開発メトリクスにはあまり興味がありません。彼らは、ソフトウェアがもたらすビジネス上のメリット、例えば、手作業の削減、販売コンバージョンの向上、顧客満足度の向上、つまりビジネス成果をより重視します。成果志向のチームとは、ビジネス成果を達成することを義務付けられ、装備されたチームであり、成果を実現するために必要なすべてのアクティビティを実行できる能力を持つ人材を擁しています。対照的に、活動志向のチームは、成果を実現するための装備も義務付けもありません。彼らは、成果を実現するために必要な複数のアクティビティのうちの1つしか実行できません。

表面的には、アジャイルソフトウェア開発の世界は、現在主流となっているため、明るいものです。しかし、現実には、行われていることの多くは、アジャイルの価値観と原則を無視した偽のアジャイルであるため、厄介です。私たちが焦点を当てるべき3つの主な課題は、アジャイル産業複合体とそのチームにプロセスを押し付ける習慣との闘い、技術的卓越性の重要性の向上、そして（プロジェクトではなく）製品を中心としたチームの編成です。問題はあるものの、コミュニティの大きな強みは、学び、適応し、私たちマニフェストの原著者が想像もしなかった問題に取り組む能力です。

私は、ソフトウェア開発で見られることを説明するために新語を作成する癖があります。ソフトウェア開発にはまだ有用な専門用語が不足しているため、この分野のライターの間ではよくある習慣です。専門用語を作る際の問題点の1つは、意味の拡散（これも専門用語に追加される可能性のある言葉です）のプロセスにおいて、用語がその意味を失ってしまうことです。

アジャイルアライアンスの現在の理事会によると、アジャイル手法は「キャズムを超えた」とのことです。これは、アジャイル手法がより広く普及していることを意味していると思います。これには利点もありますが、問題ももたらします。方法論や設計アプローチが流行すると、流行に焦点を当て、真の詳細を重視しない多くの人々がそれを使用したり、教えたりするようになります。これは、アジャイルの名の下に行われたことが、運動の創設者たちの原則とは正反対であるという報告につながる可能性があります。

最近、かなりの数のプロジェクトで耳にするようになった問題があります。それは次のようなものです。

• 彼らはアジャイルプロセスを使用したいと考えており、スクラムを選択します。
• 彼らはスクラムのプラクティス、そしておそらくは原則も採用します。
• しばらくすると、コードベースがめちゃくちゃになっているため、進捗が遅くなります。

アジャイル手法の一般的な、おそらく支配的なプラクティスは、開発中のソフトウェアの機能リスト（多くの場合、ストーリーと呼ばれます）を作成することです。これらの機能は、インデックスカード、作業キュー、バーンダウンチャート、バックログ、または選択したツールで追跡されます。