アジャイルとは、段階的デリバリー、チームコラボレーション、継続的な計画、継続的な学習を重視するソフトウェア開発へのアプローチを記述する用語です。 アジャイルという用語は、アジャイルマニフェストで2001年に作られました。 マニフェストは、ソフトウェア開発に対するより良いアプローチを導く原則を確立するために設定されています。 マニフェストの中核となるのは、アジャイル運動の基礎を表す 4 つの値ステートメントです。 記述されているように、マニフェストは次のように述べています。
私たちは価値を得るようになった:
- プロセスとツールに対する個人と相互作用。
- 動作するソフトウェアを包括的なドキュメントよりも重視する。
- 契約交渉に関する顧客のコラボレーション。
- プランに従って変更に対応する。
マニフェストは、これらのステートメントの右側にある項目が重要でも必要でもないことを意味するものではありません。 むしろ、左側の項目はより価値があります。
アジャイルの方法とプラクティス
アジャイルは物ではないことを理解することが重要です。 アジャイルをそのまま実践するわけではありません。 アジャイルは、ソフトウェア開発へのアプローチを推進する考え方です。 すべての状況に対して動作するアプローチは 1 つないため、 アジャイル という用語は、マニフェストの値ステートメントと一致するさまざまな方法とプラクティスを表すようになったのです。
アジャイルメソッドはフレームワークと呼ばれることが多く、DevOps ライフサイクルのフェーズ (計画、開発、配信、運用) の包括的なアプローチです。 彼らは、明確なガイダンスと原則を使用して、作業を達成するための方法を規定します。
スクラム は最も一般的なアジャイル フレームワークであり、ほとんどの人が始めるフレームワークです。 一方、アジャイル プラクティスは、ソフトウェア開発ライフサイクルのフェーズ中に適用される手法です。
- Planning Poker は、チーム メンバーが 何を意味 するかについての理解を共有するよう促すために設計されたコラボレーション見積もりプラクティスです。 多くの人がプロセスを楽しく見つけ、チームワークとより良い見積もりを促進するのに役立っていることが証明されています。
- 継続的インテグレーション (CI) は、コードの変更をメイン ブランチに頻繁に統合する一般的なアジャイル エンジニアリングプラクティスです。 自動ビルドでは、変更が検証されます。 その結果、統合負債が減少し、継続的に出荷可能なメイン ブランチが発生します。
これらのプラクティスは、すべてのアジャイル プラクティスと同様に、アジャイル ラベルを持ち歩きます。これは、 アジャイル マニフェストの原則と一致しているためです。
アジャイルではないもの
アジャイルが人気を集めるにつれて、多くのステレオタイプや誤った解釈が、その有効性に否定的な影を落としています。 説明責任を問わず、"はい、アジャイルを行っています" と簡単に言うことができます。 この点を念頭に置いて、アジャイルではないいくつかのことを検討してください。
- アジャイルはカウボーイコーディングではありません。 アジャイルは、ソフトウェア開発に対する "進むにつれて見つけ出す" アプローチと混同しないでください。 そのような考えは真実から遠く離れることはできませんでした。 アジャイルでは、すべてのスプリントで顧客に提供される明確な価値と、完了の定義の両方が必要です。 アジャイルは個人とチームの自律性を重視する一方で、自律性の向上によって価値が高まるよう、一致した自律性を重視しています。
- アジャイルは、厳格さと計画がないわけではありません。 一方、アジャイルの手法とプラクティスは、通常、計画の規範を重視します。 重要なのは、プロジェクトの初期段階だけでなく、全体を通して継続的に計画を立てることです。 継続的な計画により、チームが実行する作業から学習できるようになります。 このアプローチにより、計画の投資収益率 (ROI) を最大化します。
「計画は価値がないが、計画はすべてである」— Dwight D. Eisenhower
- アジャイルは、ロードマップの欠如の言い訳ではありません。 この誤解は、アジャイル運動全体に最も害を及ぼしている可能性があります。 アジャイル アプローチに従う組織とチームは、どこに向かうか、そして達成したい結果を絶対に把握しています。 プロセスの一部として変更を認識することは、毎週、スプリント、または月ごとに新しい方向にピボットすることとは異なります。
- アジャイルは、仕様のない開発ではありません。 どのプロジェクトでも、作業の 理由 と 方法 についてチームを調整する必要があります。 スペックに対するアジャイル アプローチには、スペックが 適切なサイズであること、およびチームがどのように順序付けされ、作業が提供されるかを適切に反映することが含まれます。
- アジャイルは、計画外の作業やその他の中断に対応することはできません。 スケジュールに従ってスプリントを完了することが重要です。 しかし、開発を脇に逸らすような問題が発生したからといって、スプリントが失敗する必要があるわけではありません。 Teams は、問題や予期しない問題に事前にリソースを指定することで、中断を計画できます。 その後、これらの問題に対処しつつ、開発を順調に進めることができます。
- アジャイルは、大規模な組織には不適切ではありません。 一般的な苦情は、アジャイル手法の重要な要素であるコラボレーションが大規模なチームでは困難であるという点です。 もう 1 つの不満は、アジャイルに対するスケーラブルなアプローチが、柔軟性を損なう構造と方法を導入することです。 これらの誤解にもかかわらず、アジャイルの原則を正常にスケーリングすることは可能です。 これらの困難を克服する方法については、「 大規模なチームへのアジャイルのスケーリング」を参照してください。
- アジャイルは非効率的ではありません。 お客様の変化するニーズに適応するために、開発者は各イテレーションに時間を費やして、実際の製品をデモンストレーションし、フィードバックを収集します。 これらの取り組みによって、開発に費やす時間が短縮されるのは事実です。 しかし、顧客の要求を早期に組み込むことで、後で大幅な時間を節約できます。 機能が顧客のビジョンに沿っている場合、開発者は大幅な見直しを回避します。
- アジャイルは、多くの場合、データ ストリーミングを中心とする今日のアプリケーションには適していません。 このようなプロジェクトには、通常、ユーザー インターフェイスよりも多くのデータ モデリングと抽出変換読み込み (ETL) ワークロードが含まれます。 この事実により、一貫した厳密なスケジュールで使用可能なソフトウェアを示すのが困難になります。 しかし、目標を調整することで、開発者はアジャイル アプローチを引き続き使用できます。 開発者は、イテレーションごとにタスクを実行する代わりに、データ実験の実行に集中できます。 稼働中の製品を数週間ごとに提示する代わりに、データをより深く理解することを目指すことができます。
アジャイルの理由
では、なぜ誰かがアジャイルアプローチを検討するのでしょうか? ソフトウェアの構築に関する契約規則が、過去 10 年から 15 年間で根本的に変わったことは明らかです。 アクティビティの多くは似ていますが、それらを適用するランドスケープと環境は顕著に異なります。
- 2000 年代初頭にソフトウェアを購入する場合の内容を比較します。 ビジネス ソフトウェアを購入するために、ユーザーはどのくらいの頻度でストアにドライブしますか?
- 製品に関する顧客からのフィードバックの収集方法を検討します。 チームは、ソーシャル メディアの前にユーザーが自分のソフトウェアについてどのような考えを持っているかをどのように理解しましたか?
- チームが提供するソフトウェアの更新と改善を望む頻度を検討します。 年間更新プログラムは、現代の競争に対して実行可能ではなくなりました。
Forrester の Diego Lo Guidice 氏は、ブログ「 Transforming Application Delivery (2020 年 10 月)」で最高だと述べています。
「すべてが劇的に変わりました。 持続可能性は、グリーンとクリーンに加えて、今日構築されたものは、明日簡単かつ迅速に変更する必要があることを意味します。 戦略的な計画は短期的であり、計画と変更は継続的です」— ディエゴ・ロ・グイディツェ、Forrester
ルールが変更され、世界中の組織がそれに応じてソフトウェア開発にアプローチを適応するようになりました。 アジャイルの方法とプラクティスでは、すべての問題を解決できるわけではありません。 しかし、コラボレーション、継続的な計画と学習、高品質のソフトウェアをより頻繁に出荷したいという要望を通じてソリューションが出現する文化と環境を確立することを約束します。
次のステップ
ソフトウェア開発へのアジャイル ルートを決定すると、DevOps プロセスを強化するための興味深い機会が生じる可能性があります。 1 つの重要な考慮事項セットは、アジャイル開発 が組織の現在のアプローチとどのように比較および対比されるかを考慮しています。