アジャイルの基本原則と価値 (Jeff Sutherland 著)

アジャイル開発とは、スクラム、エクストリーム プログラミング (XP)、ダイナミック システム開発メソッド (DSDM)、および Crystal の開発者と、フィーチャ駆動型開発の代表的な提唱者、さらにソフトウェア業界のその他数人のソート リーダーで構成されるグループによって 2001 年に策定されたアジャイル宣言から派生した用語です。 アジャイル宣言は、当時の個々のアジャイル方式すべてに共通する、包括的な価値と原則を確立しました。 DSDM チームで高い成果を挙げるための 4 種類の中心の値を示します。

• 個人とその相互作用

• 正しく機能するソフトウェアの提供

• 顧客とのコラボレーション

• 変化への対応

これらの中核的な価値は 12 の原則によって支えられています。これらの原則については、Web サイト「Manifesto for Agile Software Development (アジャイル ソフトウェア開発のための宣言)」を参照してください。

これらの価値は、アジャイル宣言の策定者が口先だけで提唱し、すぐに忘れるようなものではありません。 これらは実用的な価値です。 これらの価値にどのように取り組むかは個々のアジャイル方式によって若干異なりますが、どの方式にも、価値を 1 つ以上高めるための固有のプロセスと手順が定められています。

個人と相互作用

個人と相互作用は、チームで高い成果を挙げるためには欠かせません。 あるプロジェクトで "コミュニケーションの飽和" について調べたところ、コミュニケーションに問題がなければ、チームは業界平均の 50 倍の実績を達成できることがわかりました。 通信を行うために、アジャイル方法は、調査と順応のサイクルを前提としています。 このサイクルは、ペア プログラミングでは数分ごと、継続的な統合では数時間ごと、毎日のスタンドアップ ミーティングでは毎日、そして検閲と振り返りではイテレーションごとと、さまざまです。

ただし、単にフィードバックとコミュニケーションの頻度を増やすだけで、コミュニケーションの問題を解消できるわけではありません。 調査と順応のサイクルは、チーム メンバーが、次に示すような重要な姿勢を示した場合にのみ効果を発揮します。

• すべての人に対する尊敬の気持ち

• すべてのコミュニケーションにおける正直さ

• すべてのデータ、アクション、および決定の透明性

• 全員でチームを支えるという信頼感

• チームと、チームのゴールに対する貢献

このような姿勢を促すために、アジャイル管理では協力的な環境が必要になります。また、チーム コーチはこれらの姿勢を積極的に取り入れ、チーム メンバーはその姿勢を示す必要があります。 そうして初めて、チームは完全な能力を発揮できるのです。

チームでこれらの種類の動作を満たすことが表示されることがあります。困難です。 文化的な規範や、率直に意見を述べたために対立が起こり嫌な思いをしたという過去の経験などから、ほとんどのチームは正直さ、透明性、および信頼感を示すことを避けています。 こうした傾向を打破するために、リーダーとチーム メンバーは、建設的な対立を促進する必要があります。 チームが正の競合を行うと、だけでなく、の生産性な動作を実現しますが、他のいくつかのメリットを達成するために機能:

• プロセスの改善は、チームが組織内の障害や問題点のリストを作成し、それらに対して正面から取り組み、重要度に応じて体系的に解決していけるかどうかに左右されます。

• 革新的な機能が矛盾した考えを自由にやり取りして、Hirotaka Takeuchi と Ikujiro Nonaka が検索され、説明する現象は、スクラムの名付け親でのみ発生します。

• 競合する議題の解決は、チームが共通のゴールの周囲に配置し、その問題と競合発生すると発生します。

• 協力して作業を行うという取り組みは、メンバーが共通のゴールに合意し、個人として、そしてチームとして向上に努めることよって初めて可能になります。

特に重要なのは、最後の取り組みについての点です。 高い価値を実現するための責任感を持ってこそ、個人もチームも熱心に取り組むようになります。これは、ソフトウェア開発チームにおいて重要な点です。 アジャイル方式ではピックアップ チーム メンバーに、コミット、自己組織化を優先度が付けられた作業リストから項目を、独自に管理する作業の方法の改善に作業するとフォーカス転送します。 これらの方法は、アジャイル チームの成果を挙げるための原動力のある自己組織の基礎となります。

アジャイル方式では、高い成果を挙げるチームを形成するために、プロセスやツールよりも個人と相互作用に重きを置いています。 実際、どのアジャイル方式も、調査と順応のサイクルを頻繁に繰り返すことによって、コミュニケーションと協力の活性化を目指しています。 ただし、これらのサイクルは、アジャイル チームに対する正直さ、透明性、信頼感、尊敬、責任などで成り立つ強固な基盤を構築するために、アジャイル リーダーが建設的な対立を促して初めて効果を発揮します。

包括的なドキュメントより、正しく機能するソフトウェア

正しく機能するソフトウェアは、アジャイル開発がもたらす大きな変化の 1 つです。 アジャイル宣言で表されるすべてのアジャイル方式は、正しく機能するソフトウェアを少しずつ、一定の間隔で顧客に提供することを重要視しています。

すべてのアジャイル チームは "正しく機能するソフトウェア" が何を指すかを定める必要があります。多くの場合、これは、完了の定義と呼ばれます。 高いレベルでは、1 つの機能は、その中の機能がすべてのテストに成功し、エンド ユーザーが操作できる段階になって初めて完成したことになります。 少なくとも、チームは単体テスト レベルにとどまらず、システム レベルでのテストを行う必要があります。 良いチームの場合は、1 つの機能の完了の定義の中に、統合テスト、パフォーマンス テスト、および顧客による承認テストも含めます。

1 種類の CMMI レベル 5 の会社は、多くのプロジェクトの広範なデータによって既に世界で最も低い欠陥率は 1 ですが、アジャイル手法の利点があります。 具体的には、運用の効果的な体系的に二重速度で、40 は次の処理を行うことによって問題を軽減できます:。 他社設定します。

• 機能を定義するときには、受け入れテストを定義します。

• 逐次的および優先順位の順で機能を実装します。

• 実行するとすぐに各機能の受け入れテストを実行します。

• 最も優先度の高いようにできるだけ早く識別されるバグを修正します。

アジャイル宣言では、正しく機能するソフトウェアを、チームが一定の間隔で提供できるよう推奨しています。 対応するにはよって、の成功を意味する場合は、チームでアジャイル チームこの目標を満たすために必要なパフォーマンスと高品質が導入する実際的な方法の 1 種類です。

契約上の交渉より、顧客とのコラボレーション

過去 20 年間にわたり、世界中のプロジェクト成功率は 2 倍以上になりました。 これらのアップグレードは貴社が機能するソフトウェアに関するフィードバックを一定の間隔で提供できるようにするより頻繁に発生すると、付属の小型プロジェクトの結果として。 アジャイル宣言の提唱者たちは、明確な考えがあって、ソフトウェア開発プロセスに顧客を参画させることが成功に不可欠であることを主張していたのです。

アジャイル方式では、作業を支持する顧客が、開発チームと手を携えて連携することによって、この価値を高めています。 たとえば、最初のスクラム チームは、数千もの顧客を抱えていました。 これは、製品開発にそれらをすべて含めることは、実行可能ではないため、製品所有者という貴社のプロキシを選択します。 製品所有者は、フィールドの貴社のすべて、管理、販売、サポート、クライアント サービス、およびそのほかの関係者だけでなく、表される。 製品所有者は、チームが正しく機能するソフトウェアをリリースする 4 週間ごとに、要件のリストを更新する責務を担っています。その際、現状と、顧客および関係者からの実際のフィードバックを考慮に入れます。 貴社の積極的にアシスト図形、作成中のソフトウェア。

最初の XP チームは、社内 IT プロジェクトから始まりました。 XP チームはこれを使用してチーム作業の会社のをエンド ユーザーに参加してもらいました。 コンサルタント時間、および内部チームの約 10 を占めますチームが日常的に使用できるエンド ユーザーを検索できます。 残り 9 割については、プロキシを立てる必要があります。 この顧客プロキシは、XP チームでは顧客と呼ばれており、エンド ユーザーと連携して、開発者が実装する必要がある機能について明記され、かつ優先度付けされたリストを提示します。

これは、業界のデータに示す毎日の貴社 (または貴社のプロキシ) コラボレーションに、アジャイル プロジェクトに倍以上の平均により、世界中のプロジェクト成功率があることにあります。 アジャイル方式が貴社の視聴時間の値を確認するため、貴社を表すための特別な構文で、開発チームの場所を作成しました。

計画に従うより、変化に対応する

貴社を満足させ、ビジネス価値を提供する製品を作成するチーム用に、チームが変更に応答する必要があります。 業界のデータによると、製品やプロジェクトの要件の 60% 以上は、ソフトウェアの開発中に変わります。 本来のプロジェクトが、期限内、予算内で、かつ計画されていたすべての機能を組み込んで完了したとしても、自分が求めていたものとは違うということから、顧客が満足しないことが多々あります。" ハンフリーの法則" によると、顧客は、正しく機能するソフトウェアを目にするまでは、自分が何を求めているかわからないそうです。 プロジェクトが終わるまで、顧客が正しく機能するソフトウェアを目にすることがなければ、顧客からのフィードバックを反映できなくなります。 アジャイル方式では、製品を開発するにはつれてチームがフィードバックや新しい情報を取り込むことができるように、プロジェクトを通じて顧客からのフィードバックを検索します。

すべてのアジャイル方式には、顧客や顧客プロキシからのフィードバックに基づき、定期的に計画を変更するプロセスが組み込まれています。 この計画は、最も高いビジネス価値を常に最初に提供できるよう策定されています。 価値の 80% は機能の 20% に含まれるため、従来のプロジェクトの大半では終了が遅れますが、効率の良いアジャイル プロジェクトは早期に終了する傾向があります。 その結果、顧客の満足度は高くなり、開発者も仕事を楽しめるのです。 アジャイル方式は、成功するには変化に備える必要がある、という認識に基づいています。 こうした理由から、顧客フィードバックやビジネス価値に基づいて、定期的に優先度を変えるよう策定された、検閲や振り返りのプロセスを確立したのです。

アジャイルは包括的 - 方式は実装

アジャイル開発そのものは、方式ではありません。 いくつかのアジャイル方式を説明する、包括的な用語なのです。 2001 年のアジャイル宣言の署名時には、スクラム、XP、Crystal、FDD、DSDM などの方式が含まれていました。 それ以来、有益なアジャイル方式としてリーン手法も生まれ、このトピックの下の図に示すように、アジャイル開発の傘下に入れられました。

多くのコンピューター言語が、オブジェクト指向プログラミングの中核的な機能を異なる方法で示しているのと同様に、アジャイル宣言の中核的な価値を実装するアプローチは、それぞれのアジャイル方式によって少しずつ異なります。 最近の調査によると、約 50% のアジャイル実践者がスクラムを取り入れているそうです。 残りのうち 20% は、XP コンポーネントでスクラムを実践しており、 さらに 12% は XP だけを取り入れているとのことです。 世界中のアジャイル実装の 80% 以上がスクラムか XP であるため、MSF for Agile Software Development v5.0 では、スクラムと XP の中核的なプロセスと慣例に重点を置いています。

スクラムとは、アジャイル開発プロセスのフレームワークです。 特定のエンジニアリング手法は含まれていません。 反対に、XP はエンジニアリング手法に重点を置いていますが、開発プロセスの包括的なフレームワークは含みません。 しかし、これはスクラムが特定のエンジニアリング手法を推奨していない、または XP にはプロセスがないということではありません。 たとえば、最初のスクラムは、現在 XP として知られているすべてのエンジニアリング手法を実装していました。 しかし、ソフトウェア開発向けのスクラム フレームワークは 2 ～ 3 日でチームを立ち上げるよう策定されていますが、エンジニアリング手法は多くの場合数か月かかって実装されます。 したがって、特定の手法をいつ実装するか (および実装するかどうか) は、各チームに任されているのです。 スクラムの共同提唱者である Jeff Sutherland と Ken Schwaber は、障害とプロセス改善計画のリストをすぐに作成することを、スクラム チームに推奨しています。 エンジニアリング手法が障害として識別される場合は、改善策として、XP 手法に注目します。 良いチームは、XP 手法で補完したスクラムを実践します。 スクラムは XP の規模を拡大縮小でき、XP はスクラムが効果を発揮できるようにします。

次の表に、スクラムと XP の主要用語の相互対応を示します。

参照

概念

Visual Studio ALM および TFS での作業の追跡

その他の技術情報

Visual Studio ALM 用 MSF for Agile Software Development