アジャイル手法とは何ですか?現代のソフトウェア開発は説明しました

今日のすべてのテクノロジー組織は、ソフトウェア開発またはそのバージョンのアジャイル手法を実践しているようです。または、少なくとも彼らはそう信じています。アジャイルアプリケーション開発に不慣れな場合でも、ウォーターフォールソフトウェア開発手法を使用して数十年前にソフトウェア開発を学んだ場合でも、今日の作業は少なくともアジャイル手法の影響を受けます。

しかし、アジャイル手法とは何であり、ソフトウェア開発でどのように実践すべきでしょうか?アジャイル開発は実際のウォーターフォールとどのように異なりますか?アジャイルソフトウェア開発ライフサイクル、またはアジャイルSDLCとは何ですか?そして、スクラムアジャイルとかんばんや他のアジャイルモデルとは何ですか? 

アジャイルは、17人の技術者がアジャイルマニフェストを起草した2001年に正式に発足しました。彼らは、より優れたソフトウェアを開発することを目的として、アジャイルプロジェクト管理の4つの主要な原則を作成しました。

  • プロセスとツールを介した個人と相互作用
  • 包括的なドキュメントを介した作業ソフトウェア
  • 契約交渉をめぐる顧客のコラボレーション
  • 計画に従った切り替えへの対応

アジャイルの前:ウォーターフォール手法の時代

私のような古い手は、ウォーターフォール手法がソフトウェア開発のゴールドスタンダードであった時代を覚えています。ソフトウェア開発プロセスでは、コーディングを開始する前に大量のドキュメントが必要でした。誰か、通常はビジネスアナリストが、最初に、アプリケーションでビジネスに必要なすべてのものをキャプチャしたビジネス要件ドキュメントを作成しました。これらのビジネス要件ドキュメントは長く、全体的な戦略、包括的な機能仕様、視覚的なユーザーインターフェイスデザインなど、すべてを詳しく説明しています。

技術者はビジネス要件ドキュメントを取得し、独自の技術要件ドキュメントを作成しました。このドキュメントでは、アプリケーションのアーキテクチャ、データ構造、オブジェクト指向の機能設計、ユーザーインターフェイス、およびその他の非機能要件を定義しました。

このウォーターフォールソフトウェア開発プロセスは、最終的にコーディング、統合、そしてテストを開始してから、アプリケーションが本番環境に対応していると見なされます。全体のプロセスは簡単に数年かかる可能性があります。

私たちの開発者は、ドキュメントの作成者と同じように、完全なドキュメントが呼び出されたときに「仕様」を知っていることが期待されていました。ページドキュメント。

当時、ソフトウェア開発自体も簡単ではありませんでした。多くの開発ツールには専門的なトレーニングが必要であり、現在存在するオープンソースまたは商用のソフトウェアコンポーネント、API、およびWebサービスの近くにはありませんでした。データベース接続を開いたり、データ処理をマルチスレッド化するなど、低レベルのものを開発する必要がありました。

基本的なアプリケーションでも、チームは大きく、コミュニケーションツールは限られていました。私たちの技術仕様は私たちを一致させたものであり、聖書のようにそれらを活用しました。要件が変更された場合、チーム全体で変更を伝達し、コードを修正するのに費用がかかるため、ビジネスリーダーは長いレビューと承認のプロセスを経ることになります。

ソフトウェアは技術アーキテクチャに基づいて開発されたため、最初に低レベルのアーティファクトが開発され、その後に依存するアーティファクトが開発されました。タスクはスキルによって割り当てられ、データベースエンジニアが最初にテーブルやその他のデータベースアーティファクトを作成し、次にアプリケーション開発者が機能とビジネスロジックをコーディングし、最後にユーザーインターフェイスをオーバーレイするのが一般的でした。誰かがアプリケーションが機能しているのを見るまでに数か月かかり、その時までに、利害関係者は彼らが本当に望んでいることについて腹を立て、しばしば賢くなっていました。変更の実装にそれほど費用がかかるのも不思議ではありません。

ユーザーの前に置いたすべてが期待どおりに機能したわけではありません。場合によっては、ユーザーが機能をまったく使用しないことがあります。また、機能は広く成功しましたが、必要なスケーラビリティとパフォーマンスをサポートするためにリエンジニアリングが必要でした。ウォーターフォールの世界では、ソフトウェアが展開された後、長い開発サイクルの後、これらのことを学んだだけです。

関連ビデオ:アジャイル手法が実際にどのように機能するか

誰もがアジャイルソフトウェア開発について話しているようですが、多くの組織はプロセスがどのように機能するかをしっかりと把握していません。この5分間のビデオを見て、スピードを上げてください。

アジャイルソフトウェア開発への要

1970年に発明されたウォーターフォール手法は、ソフトウェア開発に規律をもたらし、従うべき明確な仕様があることを保証するため、革新的でした。これは、ヘンリーフォードの1913年の組立ラインの革新から派生したウォーターフォール製造方法に基づいており、最終製品が最初に仕様されたものと一致することを保証するために、製造プロセスの各ステップについて確実性を提供しました。

ウォーターフォール手法がソフトウェアの世界に登場したとき、コンピューティングシステムとそのアプリケーションは通常、複雑でモノリシックであり、提供するには規律と明確な結果が必要でした。要件も今日に比べてゆっくりと変化したため、大規模な取り組みの問題は少なくなりました。実際、システムは変更されないが永続的な戦艦であるという前提の下で構築されました。複数年の期間は、ソフトウェア開発だけでなく、製造やその他の企業活動でも一般的でした。しかし、ウォーターフォールの剛性は、スピードと柔軟性が要求されるインターネット時代にアキレス腱になりました。

開発者がインターネットアプリケーションに取り組み始めたとき、ソフトウェア開発方法論は変化し始めました。初期の作業の多くは、チームが小さく、同じ場所に配置され、従来のコンピューターサイエンスのバックグラウンドを持たないスタートアップで行われました。 Webサイト、アプリケーション、および新機能をより早く市場に投入するという財政的および競争的圧力がありました。開発ツールとプラットフォームはそれに応じて急速に変化しました。

これにより、スタートアップで働く私たちの多くは、ウォーターフォールの方法論に疑問を投げかけ、より効率的な方法を探すようになりました。詳細なドキュメントをすべて事前に作成する余裕はなく、より反復的で協調的なプロセスが必要でした。要件の変更についてはまだ議論していましたが、実験とエンドユーザーのニーズへの適応に対してよりオープンでした。私たちの組織は構造化されておらず、アプリケーションはエンタープライズレガシーシステムよりも複雑ではなかったため、アプリケーションを購入するよりも構築する方がはるかにオープンでした。さらに重要なことに、私たちはビジネスを成長させようとしていたので、ユーザーが何かが機能していないと言ったとき、私たちはしばしば彼らの話を聞くことを選びました。

私たちのスキルと革新する能力は戦略的に重要になりました。必要なすべての資金を調達することはできますが、「仕様」に従って惜しみなく従順なコーダーとして扱う場合、急速に変化するインターネット技術を扱うことができる才能のあるソフトウェア開発者を引き付けることはできません。私たちは、開発すべきもの、アプリケーションを出荷する時期、場合によってはコードの構造化方法を説明するエンドツーエンドのスケジュールを持って来るプロジェクトマネージャーを拒否しました。ウォーターフォールプロジェクトマネージャーが作成し、絶えず更新する3か月と6か月のスケジュールを達成するのはひどいものでした。

代わりに、インターネットアプリケーションをどのように設計する必要があるかを説明し始め、繰り返し作成したスケジュールで結果を提供しました。 1週間から4週間の短い間隔でコミットしたときに、私たちが言ったことを実現するのはそれほど悪くなかったことがわかりました。

2001年に、経験豊富なソフトウェア開発者のグループが集まり、従来のウォーターフォール手法とは異なる方法でソフトウェア開発を共同で実践していることに気付きました。そして、彼らはすべてスタートアップにいるわけではなかった。テクノロジーの著名人であるケントベック、マーティンファウラー、ロンジェフリーズ、ケンシュウェイバー、ジェフサザーランドを含むこのグループは、最新のソフトウェア開発プロセスがどのように機能するかについての共通の信念を文書化したアジャイルマニフェストを考案しました。彼らは、文書化、厳格な管理慣行ではなく自己組織化、および厳格なウォーターフォール開発プロセスに縛られるのではなく、絶え間ない変化に対処する能力をめぐるコラボレーションを強調しました。

これらの原則から、ソフトウェア開発のためのアジャイル手法が生まれました。

アジャイル手法における役割

アジャイルソフトウェア開発プロセスは常に、ユーザーを定義し、対処すべき問題、機会、および価値の範囲に関するビジョンステートメントを文書化することから始まります。製品の所有者はこのビジョンを捉え、学際的なチーム(または複数のチーム)と協力してこのビジョンを実現します。そのプロセスにおける役割は次のとおりです。

ユーザー

アジャイルプロセスは常にユーザーまたは顧客を念頭に置いて始まります。今日では、ソフトウェアがサポートしているワークフローのさまざまな役割や、さまざまなタイプの顧客のニーズや行動を説明するために、ユーザーペルソナでそれらを定義することがよくあります。

プロダクトオーナー

アジャイル開発プロセス自体は、内部の利害関係者を含め、顧客の声である必要がある誰かから始まります。その人は、製品のビジョンを作成するために、すべての洞察、アイデア、およびフィードバックを抽出します。これらの製品ビジョンは、多くの場合、短くて単純ですが、それでも、顧客が誰であるか、どのような価値観に取り組んでいるか、およびそれらにどのように対処するかについての戦略を描きます。 Googleの当初のビジョンは、「インターネットにアクセスできる人なら誰でも、シンプルなキーワード駆動型のインターフェースと、検索結果で信頼できるソースを上位にランク付けするアルゴリズムを使用して、関連するウェブサイトやウェブページを簡単に見つけられるようにしましょう」のように見えたと想像できます。

この人を製品所有者と呼びます。彼または彼女の責任は、このビジョンを定義し、それを実現するために開発チームと協力することです。

開発チームと協力するために、製品の所有者は、製品のビジョンを一連のユーザーストーリーに分解し、ターゲットユーザーが誰であるか、どのような問題が解決されているか、なぜ解決が重要であるかを詳しく説明します。どのような制約と受け入れ基準がソリューションを定義するか。これらのユーザーストーリーは、製品の所有者によって優先順位が付けられ、チームによってレビューされて、求められていることについて共通の理解があることを確認します。

ソフトウェア開発チーム

アジャイルでは、開発チームとそのメンバーの責任は、従来のソフトウェア開発の責任とは異なります。

チームは学際的であり、仕事を成し遂げるためのスキルを持つ多様な人々のグループで構成されています。動作するソフトウェアの提供に重点が置かれているため、チームはエンドツーエンドで機能するアプリケーションを完成させる必要があります。そのため、アプリケーション全体ではなく、アプリケーションの一部のデータベース、ビジネスロジック、およびユーザーインターフェイスが開発されてからデモが行われます。これを行うには、チームメンバーが協力する必要があります。彼らは頻繁に会合を持ち、自分たちが構築しているもの、誰が何をしているのか、そしてソフトウェアがどのように開発されているのかについて全員が一致していることを確認します。

ソフトウェア開発チームには、開発者に加えて、ソフトウェアプロジェクトのタイプに応じて、品質保証(QA)エンジニア、他のエンジニア(データベースやバックエンドシステムなど)、設計者、およびアナリストを含めることができます。

スクラム、かんばん、およびその他のアジャイルフレームワーク

ソフトウェア開発ライフサイクルに合わせて、開発プロセスとアジャイル開発プラクティスの詳細を提供する多くのアジャイルフレームワーク。

最も人気のあるアジャイルフレームワークはスクラムと呼ばれます。これは、スプリントと呼ばれる配信リズムと、次のような会議構造に焦点を当てています。

  • 計画—スプリントの優先順位が特定される場所
  • コミットメント—チームがユーザーストーリーのリストまたはバックログを確認し、スプリントの期間中に実行できる作業量を決定する場所 
  • 毎日のスタンドアップミーティング—チームが開発ステータスと戦略に関する最新情報を伝えることができるようにします)

スプリントは、機能が製品の所有者に示されるデモ会議で終わり、その後、チームが何がうまくいったか、何がプロセスで改善が必要かについて話し合う回顧会議が続きます。

多くの組織は、チームがスクラムプロセスを管理するのを支援するために、スクラムマスターまたはコーチを採用しています。

スクラムが支配的ですが、他にもアジャイルフレームワークがあります。

  • かんばんは、ファンインおよびファンアウトプロセスとして機能します。このプロセスでは、チームがユーザーストーリーをインテークボードから引き出し、段階的な開発プロセスを経て、完了するまでそれらを注ぎ込みます。
  • 一部の組織は、新しいアプリケーションにはアジャイルプロセスを使用し、レガシーアプリケーションにはウォーターフォールを使用して、アジャイルとウォーターフォールのハイブリッドアプローチを採用しています。
  • 組織がプラクティスを複数のチームに拡張できるようにするためのフレームワークもいくつかあります。

アジャイルフレームワークはプロセスとコラボレーションを定義しますが、アジャイル開発プラクティスは、アジャイルフレームワークと連携して実行されるソフトウェア開発タスクに対処することに固有のものです。

したがって、たとえば:

  • 一部のチームはペアプログラミングを採用しています。ペアプログラミングでは、2人の開発者が一緒にコーディングして、より高品質のコードを推進し、より多くの上級開発者が後輩の開発者を指導できるようにします。
  • より高度なチームは、テスト駆動開発と自動化を採用して、基盤となる機能が期待される結果を確実に提供するようにします。
  • 多くのチームは技術標準も採用しているため、開発者によるユーザーストーリーの解釈は、必要な機能だけでなく、セキュリティ、コード品質、命名規則、およびその他の技術標準にも適合します。

アジャイル手法が優れている理由