アジャイルITはIT業界をどのように変革できるのか？

コンテンツ

• なぜアジャイルITなのか？
• アジャイル手法は、ウォーターフォールモデルの問題にどのように対処しますか？
• アジャイルはIT業界にどのような影響を与えましたか？
• バグやストレスなし-あなたの人生を破壊することなく人生を変えるソフトウェアを作成するためのステップバイステップガイド
• BTがアジャイルプラクティスに移行した理由
• 要件の不十分な管理
  
• 貧弱なソフトウェア設計
• 開発の制約
• BTは上記の問題に対処するために何をしましたか？
• 結論

ソース：Darkovujic / Dreamstime.com

取り除く：

多くの人にとって、ソフトウェア開発のウォーターフォールモデルは何十年もの間標準でしたが、現在でははるかに柔軟なアジャイル手法に置き換えられています。

ソフトウェア開発のアジャイル手法は、IT業界にプラスの影響を与える可能性があります。アジャイル手法の採用結果は、さまざまな方法で測定できます。ソフトウェア変更要求の迅速な対応、バグの減少、チームのパフォーマンスの定量的測定およびボトルネックはすべて、アジャイルの実装の成功を反映しています。アジャイルの影響を正常に測定するには、組織はアジャイル前およびアジャイル後の開発に関連するさまざまなメトリックを比較する必要があります。アジャイルの実際の影響は、収益の増加や修正されたバグの数の増加だけでは測定できません。実際の影響を理解するには、いくつかの内部パラメーターを考慮する必要があります。 （アジャイル開発の詳細については、アジャイルソフトウェア開発101を参照してください。）

なぜアジャイルITなのか？

IT業界は、主にソフトウェア開発のウォーターフォールモデルの制約のために、アジャイルプラクティスに傾いています。一般に、IT企業は変化する顧客の需要や市場の状況に対応できず、ソフトウェア開発のウォーターフォールモデルではコストを削減できないことが観察されています。この圧倒的なアジャイル手法への傾倒を相殺し、興奮の一部を単なる誇大広告と見なしても、ウォーターフォールモデルに対する多くの経験的フィードバックがあります。

簡単に言えば、ウォーターフォールモデルはソフトウェア開発モデルであり、作業は次々と順番に行われます。このモデルには、要件、設計、実装、検証、メンテナンスの5つのフェーズがあります。通常、1つのフェーズが完了した後、以前のフェーズに変更を加えることは不可能ではないにしても困難です。そのため、要件はほとんど修正されているという前提があります。アジャイルモデルとの主な違いは、要件に変更がないという前提にあります。アジャイルは、ビジネス状況が変化し、要件も変化すると想定しています。したがって、ソフトウェアはssを介して小さなチャンクで配信されますが、ウォーターフォールモデルでは、最初の配信またはリリースは長い時間の後に行われます。 （開発の詳細については、Apache Sparkが迅速なアプリケーション開発にどのように役立つかを参照してください。）

ウォーターフォールモデルに対する最も注目すべき批判は、要件に変更がないという前提でした。まさにその仮定は欠陥があり、非現実的です。たとえば、2001年の英国の1,027件のITプロジェクトに関する調査では、この仮定がITプロジェクトの失敗の最大の理由であることが示されました。

別の例では、「アジャイルおよび反復開発：マネージャーガイド」という本の著者であるクレイグラーマンは、米国のウォーターフォールモデルを使用して国防総省（DoD）によって実行された多くのプロジェクトがどのように失敗したかを指摘しています目的を達成します。 1980年代から1990年代にかけて、DoDは、DoD STD 2167で公開された標準に従って、ソフトウェア開発プロジェクトにウォーターフォールモデルを使用する必要がありました。衝撃的な統計により、これらのソフトウェアプロジェクトの75％が使用されなかったことが明らかになりました。このレポートに続いて、ソフトウェアエンジニアリングの専門家として有名なフレデリックブルックス博士の下でタスクフォースが発足しました。タスクフォースは、「DoD STD 2167も同様に、最新のベストプラクティスを反映するために根本的なオーバーホールが必要である」とコメントしたレポートで出てきました。進化的開発は技術的に最も優れており、時間とお金を節約します。」

ウォーターフォールモデルの次の4つの仮定は、実際のシナリオでは失敗しました。

• 与えられた要件は合理的に明確に定義されているため、大幅に変更されることはありません。
• 開発段階で要件が変更されたとしても、開発サイクル内で対応できるほど小さくなります。
• ソフトウェア配信後に発生するシステム統合は、計画どおりに進みます。
• ソフトウェアの革新と革新に必要な努力は、計画された予測可能なスケジュールに従って行われます。

アジャイル手法は、ウォーターフォールモデルの問題にどのように対処しますか？

アジャイルの方法論は、ウォーターフォールモデルとは根本的に異なり、その前提から明らかです。

• 顧客でさえ、だれも要件を完全に理解または理解することはできません。要件が変更されないという保証はありません。
• 要件の変更は小さくて管理しやすいものではない場合があります。実際、それらはさまざまなサイズで提供され、今後も提供されます。そのため、ソフトウェアは変更を追跡するために少しずつ配信されます。

アジャイルはIT業界にどのような影響を与えましたか？

アジャイルは多くの場所で採用されていますが、多くの企業がアジャイルを採用する計画を立てています。アジャイルは間違いなくIT業界に根本的な変化をもたらしましたが、事実と数字を入手するのはまだ少し困難です。しかし、アジャイルの影響は、以下に示すBritish Telecom（BT）のケーススタディで理解できます。

バグやストレスなし-あなたの人生を破壊することなく人生を変えるソフトウェアを作成するためのステップバイステップガイド

誰もソフトウェアの品質を気にしない場合、プログラミングスキルを向上させることはできません。

BTがアジャイルプラクティスに移行した理由

BTは、2004年にソフトウェア開発の実践に関して多くの問題を経験し始めました。BTは、単純なものから複雑なものまで、数多くのソフトウェアプロジェクトを開発しました。多くのソフトウェアプロジェクトは、合意された期間内に高品質の出力を開発できませんでした。 BTは、問題の原因がウォーターフォールモデルにあることを発見しました。したがって、ウォーターフォールモデルの強化は役に立たなかった。問題の主な原因は次のとおりです。

要件の不十分な管理

• あまりにも多くの要件が与えられ、限られた時間内に満たされました。
• 多くの要件は、ビジネスニーズとは無関係でした。
• ほとんどすべての要件に、すべての要件に高優先度ステータスが割り当てられていません。
• 要件は、将来のシナリオを考慮せずに現在のビジネスニーズを表しています。それは将来のソフトウェア変更の可能性を開いたままにした。

貧弱なソフトウェア設計

• 膨大な数の要件を考えると、設計者は要件が何を意味するのかを理解しようとするだけで時間を費やしすぎました。実際の設計にはほとんど時間がありませんでした。
• 要件アナリストは他の任務に移り、書かれていない暗黙の知識を持ちました。
• 上記の2つの要因により、設計が不十分になりました。設計者は、元のタイムラインに従って配信する必要がありました。

開発の制約

ソフトウェア設計の欠陥のため、コーディングは急いで質が悪かった。開発者は、貧弱なソフトウェア設計が貧弱なコードをもたらすことを認識しますが、それでも合意されたタイムラインまでに提供しなければなりませんでした。単体テストと回帰テストが実行されなかったため、統合中に多くのバグが報告されました。

ソフトウェアが展開されるまでに、顧客は要件がすでに変更されていることに気付き、ビジネスシナリオも変更されています。ソフトウェアには多くの問題もあります。事実上、ソフトウェア開発のすべての努力は無駄と見なされています。

BTは上記の問題に対処するために何をしましたか？

BTは、ウォーターフォールモデルの強化は問題の解決策ではないことに気付きました。新しいアプローチが必要でした。そのため、アジャイルアプローチを実装することにしました。新しいアプローチでは、次のことが決定されました。

• 12か月の開発サイクルの代わりに、BTは90日間のサイクルで実行可能なソフトウェアを提供します。 1つまたは2つのビジネス上の問題に焦点を合わせ、90日以内にソフトウェアソリューションを提供することを目標にしました。このサイクルの始まりは、要件が明確に識別され、分析され、優先順位が付けられるように、さまざまな利害関係者間での激しい議論によって特徴付けられました。
• 目標は、明確で具体的なビジネス価値を提供することでした。内部顧客は、明確な要件を提供するよう圧力を受けていました。そのため、あいまいな目標の代わりに、明確な受け入れ基準でユーザーストーリーが提供されました。
• 提供されるソフトウェアは完全にテストされ、文書化されます。ソフトウェアは、事前に問題を特定するために頻繁に統合テストを受けます。

アジャイルアプローチにより、BTは変化する要件やビジネス状況により簡単に適応できます。コードの品質が向上し、土壇場の基本的なバグに対処しました。

結論

アジャイルは、そのすべての利点とその周りの誇大広告のために、まだその可能性が完全に実現されていない段階にあります。これは、多くの組織が元の原則を変更する程度にアプローチをカスタマイズしているためです。その結果、場合によっては、ウォーターフォールモデルが復活しています。カスタマイズは継続しますが、アジャイルの基本原則を維持することが重要です。多くの組織は完全にアジャイルであると主張していますが、真のアジャイル企業になるためにはまだ方法があります。