アジャイルは約20年前に登場したという事実にもかかわらず、彼らは過去8年間にのみ多かれ少なかれそれを積極的に使用し始めました。 コラボレーションと顧客重視の効率を高めることで、顧客に送信する準備ができているソフトウェア（出荷可能なソフトウェア）を作成するコストを削減するために、柔軟な原則が従来の開発方法の代替として登場しました。 つまり、ビジネス上の問題を解決するために一連の原則が形成されました-開発プロセスを加速し、生産コストを増加させることなくチームから最大限の結果を達成するためです。
はい、柔軟な方法論により、チームから最大限の効率を引き出すことができますが、状況下でアジャイル効果を減らす2つのニュアンスがあります。 まず、原則は本当に小さなチームでのみ機能します。 さらに、チーム内のすべての専門家が非常に強い場合、生産性を大幅に向上させることが可能になるという事実はまったくありません。
どのように機能しますか？
今日の開発プロセスは、コードの作成、ローンチおよびプロダクションの準備の3つの段階に分けることができます。
従来、アジャイルの目標は開発の最初の段階、つまりコードの作成でした。 遠い90年代の終わりに、改善と重大な変更が必要と見なされたのはこの段階でした。 その後、アジャイルの最も一般的な実装の1つであるスクラムが有名になりました。 公平に言えば、スクラムは、2001年にアジャイルに適応する15年前の1986年にリリースされたことに注目する価値があります。
スクラムは、作成する必要があるもののサンプルを提供し、開発プロセスの追跡、初期段階での欠点と矛盾の特定を可能にします。 技術的なタスクがなければ、プログラマーはどの製品が結果になるかを知りません。 たとえば、GoogleやFacebookについて話している場合、特定のサービスの開発者に質問はありません。 彼らは自分たちで製品を作ります-彼らは熱心なユーザーであり、新しい機能が便利になるように、何をどのように見えるべきか、何をする必要があるかを理解しています。 別のこと、たとえば、課金システム。 プログラマーは、例えば決済業務のさまざまなモデルのように、 規制とマーケティングの両方のサービスの正しい運営のために考慮しなければならない膨大な数のニュアンスを知りません。
アジャイルのパイオニアは、最先端のテクノロジーを使うことを恐れない小さな会社でした-失うものは何もありませんでした！ 明らかな理由により、このような組織でコードを記述することはプロセスの主要部分です（準備および起動プロセスは実質的にありません）。 効果はすごかった！ しかし、より先進的な組織で従来のアジャイルを数年間使用した後、彼らは市場での新製品の発売を減らすことに関連する問題が消えないことに気付き始めました。 アジャイルは、輻輳を次の段階に移しました-リリースのために新製品を準備します。 その後、2000年代の最初の10年半ばに、アジャイルの概念が拡大され、元の意味とは対照的に、開発の最初の段階のみに焦点を当てた集合体になりました。
書かれたコードを潜在的なリリース用に準備するために、継続的デリバリーが登場しました。 リリースは必ずしもすぐに行われる必要はありませんが、たとえば、ビジネスタスクに応じて特定の日付にバインドするために遅延する可能性があることに注意してください。 このアプローチにより、調整されたチーム作業を実現し、すべてのプロセスを自動化し、潜在的なコードを本番に送信する速度を向上できます。 ただし、受け入れチェックはコードの配信速度に対応せず、正式な段階として使用されることが多いため、製品の品質は自動テストによってのみ保証されます。 もちろん、今日では、開発者自身が作成することが多い個々のコンポーネントのこのような自動テストにより、コードが正しく実行されることが保証されます。 しかし、方法論自体も、既存のツールも、今日のより複雑な環境である本番環境でのコードの正しい操作を提供しません。 さらに、コードが顧客に必要な機能を実行し、割り当てられたタスクを解決することは事実ではありません。
たとえば、2015年7月、次のソフトウェアアップデートの後、ニューヨーク証券取引所での取引が停止しました。 この失敗は世界経済を揺るがし、特に、1日の米国株価指数を1％低下させ、ギリシャと債権者間の交渉を1週間遅らせました！ 別の顕著な例は、デルタ航空の航空券販売システムの更新です。 本番環境での新しいソフトウェアのリリース後、情報は通常、ディスパッチサービスに送信されなくなりました。 その結果、航空会社はすべてのフライトをキャンセルし、重大な財政的および評判上の損失を被りました。 間違いなく、どちらの場合も、起動前の多くのチェックに合格しましたが、リソースと時間を少なくすればさらに多くのチェックが行われていました。
コードの品質を確保することとのギャップは今日非常に重要であり、徐々に埋められます。 Gartnerによると、今後3年間で、少なくとも75％のIT企業が、ビジネスプロセスを統合する自動テストの開発を余儀なくされるでしょう。 品質の問題を解決するための特定の希望は、コンテナやBDD（ビヘイビアドリブン開発）などのテクノロジと方法論に割り当てられます-Docker、Cucumberなど。
これは誰のために働くのですか？
現在、アジャイルの原則は、ビジネスに特別なリスクを与えることなくこれを行うことが可能であったほとんどの企業で実装されています。 そして、新しいプロセスを構築できた人は誰でも、結果に満足しています。たとえば、Google、Zara、Ikeaなどです。 ただし、これらの企業は「分割統治」の原則に基づいて運営されていることに注意する価値があります。つまり、作業は比較的小さな独立したチームによって実行されるプロジェクトに分割されます。 さらに、アジャイルの場合、これらの企業は開発部門だけでなく、主に事業部門（特にZaraとIkea）を運営しています。 それらは、プロセスの組織だけでなくビジネスも変更したため、当然ながらアジャイルモデルに対応します。
しかし、柔軟な方法論を完全に適応させることがまだできない企業もあります。結果がまったくないか、ビジネスの期待を満たしていないかのいずれかです。 たとえば、INGとシティバンクは、アジャイルの適応という点で、銀行セクターで最も先進的であると考えられています。 ただし、これらの金融大手のすべての部門が柔軟な方法論に従って機能しているわけではありません。 アジャイルは主に、表面シェル、モバイルアプリケーション、またはその他の高度な開発を扱う部門に移動しました。 つまり、主要なビジネスプロセスに関係のない部門は、その失敗が年間収益を危険にさらし、企業全体の崩壊につながる可能性があります。
つまり、エラーのコストが非常に高い分野では、企業はまだ何かを変えることを恐れています。 はい、彼らはWaterfallが長生きしていることを理解しており、古い方法で作業していると、ある時点で競合他社に遅れを取り、すべてを失う可能性があります。 彼らは喜んで新しい作業方法に切り替えますが、リスクはイノベーションの潜在的な利点よりもはるかに高くなります。 さらに、ビジネスを柔軟な方法論に移行するために大規模な投資が必要になることが多く、すべてがすぐにうまく機能するという事実からはほど遠いです。 これは主に、ほとんどのビジネスプロセスが、Java、Scala、GOなどのモジュール式ではないプログラミング言語で数十年前に作成されたソフトウェアで構築されている企業に適用されます。
しかし、アジャイルを実装しようとして期待した結果を得られなかった企業は、ますます不満を示しています。 彼らは、柔軟な方法論の実施後、効率が向上し、市場投入までの時間とそれに伴う生産コストが削減されると約束されました。 しかし、コードがより速く出て、開発の高度な段階でますます多くの問題が現れるので、期待される効果は生じません。 場合によっては効率が向上しますが、コストの大幅な削減は行われません。 しかし、ほとんどの場合、本番からのロールバックがあり、目標を達成するための時間を短縮し、市場投入までの時間を短縮し、非常に費用がかかります。 エラーの価格は、検出が遅れるだけでなく、開発速度が速いためにも増加します。 この効果は、流速が特定の媒体の最大許容値を超えた場合の流れの乱流と比較できます。
これらすべてが最近、これらの問題を解決し、それでもアジャイル効果を達成するためのツールに対する大きな需要があるという事実に至りました。
効率を上げる方法は？
クラウドは過去10年間で非常に活発であり、大規模なテストのためにゲートウェイを部分的に開いています。 ただし、この問題は完全には解決されていません-すべての利点にもかかわらず、クラウドコンピューティングは比較的高価です。 さらに、必要な検証環境をクラウドに構築することは必ずしも容易ではありません。 今日、平均して、各開発者には10の環境が必要です。そのため、環境の価格を開発者自身の給与予算と比較できます。
その結果、コンテナ化、データ、サービスの仮想化など、他の技術が登場し始めました。 統合環境で使用すると、ゲートウェイがさらに公開されます。 単一のサーバーでこれらのテクノロジーを使用すると、ほんの数秒で、実際の環境と特定のサービスの誤動作をシミュレートする数百の環境を構築できます。
ただし、変更の頻度とテストの頻度の間には依然として不均衡があり、これらの変更を検証できます。 そのため、ボトルネックは開発チームと単純化されたテスト環境から統合テスト環境に移行しました。 ところで、このプロセスは、ソフトウェア環境を整理する問題の解決に取り組んでいる多数のスタートアップの出現によって確認されています。
アジャイルは何を表し、どこに行くのか
柔軟で継続的な方法論の中心概念の1つは、いわゆる左シフトです。これは、責任を開発者のできるだけ近くに移すことを意味します。 そしてこれは真実です-今では、非常に多くのプロセスがコードの記述に移行していることがわかります。 たとえば、技術的なタスクの議論、最初のコードチェック、および動作中のアプリケーションのプレゼンテーションでさえ、多くの場合、開発者が直接または直接に実行します。
将来的には、このシフトはさらに左に移動し、プログラマーにさらに近づきます。つまり、不可欠でストレスの多いチェックを含むすべてのチェックは、変更のソースと変更の時間に非常に近く実行されます。 これは、変更の頻度とテストの頻度のバランスを取る必要があるためです。
さらに、このシフトにより、数百人が作業しているときに検出できる乱流効果が回避され、1日に何度もコードが送信されます。 乱流の影響は、環境を見越して何百もの変化が蓄積し、環境の欠如がそれらの配信の速度に影響するという事実にあります。 これには2つの理由があります。 まず、リソースが不足しているため（すべてを完了するために、人々は多くの余分なアクションを作成し、これによりプロセス全体がさらに遅くなります）。 第二に、100件の変更のうち、数十件がテストに「落ちた」場合、修正後は修正したものだけでなく、すべてを再度確認する必要があるため、環境の赤字がさらに大きくなります。 たとえば、構成モジュールの変更は、支払いモジュールの障害やアプリケーション全体の障害につながる可能性があります。
したがって、アジャイル効果を高めるには、最初に2つの条件を実装する必要があります。
1.特定の費用なしでビジネステストを実行する機会の出現、
2.統合テストとビジネステストを可能な限り変更のソースに近づけること。
そして、もちろん、実際の状態でアプリケーションの品質を監視するための効果的なソリューションが必要です。
アジャイル黄金時代はいつ来ますか？
当初から、アジャイルは一連の原則からさまざまな方法論、プロセス、さらには標準にまで変化しました。 今日、これらの方法論の活動分野は開発チームに限定されません。 ほぼすべてのIT部門で柔軟なプロセスが正常に実装されており、ビジネスでもアジャイル標準に導かれています。 最も有名なものには、スクラム、スクラムバン、SAFe、ScaleAgile @ Spotify、継続的デリバリー、リーン、Prince2アジャイルなどがあります。
アジャイルのフレームワーク内のリーダーであると主張し、すべての問題を解決し、すべての障壁を取り除くと主張する多くのフレームワークと方法論にもかかわらず、品質は、IT企業のすべての部門と開発段階のアジャイルへの無条件の移転への主要なゲートウェイのままです。 このゲートウェイの存在は、アジャイルに対する不信の理由であり、カスケードモデルまたはウォーターフォールの原則の維持を正当化する試みです。 従来のテストフェーズの導入を通じてアジャイルを変更する試みも進行中です。
これにより、企業のビジネスプロセス、サイト、アプリケーションを一時的にあふれさせるエラーのフローが維持されます。 しかし、激しい競争に直面して、ビジネスはそのようなモデルを長い間容認しません。 メカニズム全体を柔軟な方法論に移行することによってのみ、高い品質と速度のパラメーターを備えた、柔軟で市場の要件に適合したビジネスを実現できます。
したがって、今日のアジャイルの重要な問題の1つは品質です。 そして、その解決策は非常に近い将来の問題です。 そのため、アプリケーションの新しい変更に対するビジネスの満足度を迅速かつ正確に予測するのに役立つ多くのツールがすでに登場しています。 このようなツールの導入により、検査の実施において良好な結果を得ることができます。
この問題を解決した後、今後5年間で、柔軟な方法論が残りの3分の1の企業に道を開き、それまでは開発をより現代的でありながらリスクのある方法に移すことを敢えてしました。