スプリント間でビルドを実行する以外に、アジャイルプラクティスに利点はありますか？

私は最近、ソフトウェア開発のアジャイルプラクティスに興味を持ちました。それ以来、多くの記事で、これらのプラクティスにより全体的なコストを削減できることを指摘しました。

その背後にあるロジックは通常、次のようになります。要件が変更された場合、この変更を次のスプリントバックログに反映できます。これにより、新機能の設計と実装が時間的に近いため、コストの削減につながります。後で要件を変更する必要があるほど、その要件を満たすためにコストがかかるという有名なルールに従って、コストは下がります。

しかし、中規模から大規模のソフトウェアプロジェクトは複雑です。要件が突然変更されても、その要件を満たすためにシステムの他の部分に触れる必要がないわけではありません。多くの場合、アーキテクチャを大幅に変更する必要があります。つまり、古いアーキテクチャに依存していたすべての機能を再実装する必要があります。したがって、コスト削減の全体的な要点はここではなくなります。もちろん、新しい要件がシステムの新しい独立した部分を必要とする場合、それは問題ではなく、古いアーキテクチャが成長するだけなので、再考して再実装する必要はありません。

そしてその逆。ウォーターフォールを使用していて、新しい要件を導入する必要があることに突然気付いた場合は、デザインを変更できます。既存のアーキテクチャを変更する必要がある場合は、再設計します。それが本当にそれを台無しにせず、システムの新しい部分を導入するだけなら、あなたは行ってすべての仕事をします、ここでは問題ありません。

そうは言っても、アジャイル開発の唯一の利点は、スプリント間で機能を完全にビルドできることだけであるように思えます。多くの人やプロジェクトにとって、これは重要ではありません。さらに、アジャイルはソフトウェアアーキテクチャ全体で悪い結果を招くように見えます。機能が相互に平手打ちされるため、アジャイルチームは機能が機能するかどうかではなく機能が機能することのみを気にします。これは、システムが時間とともに複雑になると、アジャイル開発の実践により、製品アーキテクチャ全体の混乱が実際に増大し、最終的にコストが高くなります。なぜなら、ウォーターフォールにより、アーキテクチャを完成させることができるからです。あなたが何かを解放する前に。

明らかに、多くの人が実稼働環境でアジャイルを使用しているので、どこかで間違っているに違いありません。

まず最初に、「ウォーターフォール」モデルは常に、ソフトウェア開発プロジェクトを実行しない方法を説明するわがままな人でした。調べる。

いずれにせよ、ほとんどの「ウォーターフォール」SDLCプロジェクトは、仕様に書き込まれた仮定がもはや有効でないことを人々が発見した場合（そしてこれは常に大規模で複雑なプロジェクトで発生します）に、「変更管理」プロセスを伴います。残念ながら、変更管理プロセスは例外処理手段として構築されており、非常に高額であるため、プロジェクトが遅れたり、品質が低下したりします。

アジャイルの方法論の背後にある考え方は、変化は当然のことであるということです。したがって、例外処理ではなく「変更管理」の標準操作を行う必要があります。これは簡単ではありませんが、多くの優れた設計手法を使用すれば実行できることがわかっています。

フロントロードデザインのもう1つの主要な問題は、（ほとんどの場合）要件の収集と設計に費やされる時間が多く、設計と開発とテストに時間がかかることです。また、テストが最後のフェーズであり、深刻な問題が発見された場合、時間内に修正される可能性はほとんどありません。

おそらく、アジャイルアプローチの最も優れた機能の1つは、ソリューションを開発しているチームとそれを必要とする顧客との間の継続的な対話（つまり、実際のコミュニケーション）を要求することです。優先度が高く、優先度の最も高いアイテムが最初に実行されます（時間がなくなると、優先度の低いアイテムがカットされます）。フィードバックはすぐに来ます。

劇的な変化の問題に戻ると、変化を軽減する方法を使用する必要があります。優れたSOLID OOプリンシパルは、ソフトウェアの回帰テストを実行できるように確実な自動テストスイートを構築できるのと同様に、これの良い役割を果たすことができます。方法論に関係なくこれらのことを行う必要がありますが、俊敏性を追求しようとする場合、これらは本当に不可欠になります。

まあ、いくつかの利点があります。1つは、顧客が仕様書を読まないことです。ずっと。ウォーターフォールは、誰もが最初から仕様にうまく同意することを想定しており、ソフトウェアが1年後に顧客に提供され、仕様が一致すると、彼らは満足するでしょう。実際には、顧客は、ソフトウェア自体を積極的に操作しているときに、本当に必要なもの、本当に必要なもの、そして別のものである必要があるものすべてを発見するだけです。アジャイルは顧客の手で機能するプロトタイプを手に入れるので、これらの切断はすぐにキャッチされます。アジャイルは、要件の変化に対応するだけではありません。また、変更のコストが高い最終的にではなく、変更のコストが低いときに、要件の変更を早期に発生させることも重要です。

2番目の利点は、アジャイルには目に見える成果物がよくあるため、プロジェクトが軌道に乗る可能性が低くなることです。大規模なウォーターフォールプロジェクトでは、実現することさえせずに遅れをとるのは非常に簡単です。滝はプロジェクトの終わりに数ヶ月の死の行進を作り出します。アジャイルを使用すると、数週間ごとに顧客に納品するので、誰もがプロジェクトの場所を正確に把握し、スリップをすばやくキャッチ（および調整）できます。私の経験では、Waterfallは数週間または数か月で、最終的に100時間の週を生成します。アジャイルとは、スプリントの最後に12時間を数日入れる必要があることを意味します。

3番目の利点は、アジャイルプロジェクトの方がやる気を起こさせる傾向があることです。1年にわたるプロジェクトで、人々があらゆる種類の意欲を持つことは非常に困難です。締め切りは遠く離れているように見え、即時性の欠如は、人々が先延ばしにしたり、過度に洗練されたデザインをしたり、さもなければ非常に生産的に機能しない傾向があることを意味します。最初の数か月は、仕様ドキュメントのように、人々がやりたくないことに費やされるため、これは特に当てはまります。アジャイルには、非常に近い将来に常に非常に即時の具体的な期限があるため、人々のモチベーションが高まる傾向があります。来週に予定されている一連のタスクの具体的な期限を先延ばしにすることははるかに困難です。

質問からの引用に対して、これは反アジャイルな対戦相手の根本的な誤解です

「...ウォーターフォールでは、何かをリリースする前にアーキテクチャを完成させることができます。」誤解です。修正させてください。「...ウォーターフォールを使用すると、アーキテクチャを完成させることができるため、何もリリースする必要がありません。」

ウォーターフォールがいかに高品質のアーキテクチャを提供するかということは、根本的に誤りであり、経験的な歴史的証拠によって完全に反証されています。

Facebookが5億人のユーザーを必要とするウォーターフォール方式で設計され、困難かつ高速な要件であり、サポートするアーキテクチャが完成するまでリリースされなかった場合、今日誰も聞いたことはありません。

YouTube、Twitter、そして無数の他の企業と同じです。

彼らは顧客が作業に触れて対応できる何かを得て、それをできるだけ早くリリースしました。彼らはフィードバックを得てそれを改良し、再びリリースしました。繰り返す。このように、これらの3つの例では、顧客が受け入れて欲しい機能だけで応答し、顧客がほとんどまたはまったく価値のないものに費やす時間をできるだけ少なくします。

何年にもわたるソフトウェア開発の経験を持つ人なら誰でも、完璧なアーキテクチャなどは存在しないことに同意するでしょう。他の選択肢よりもエントロピーと大きな泥の塊から遠くから始まるものだけです。アジャイルはこれを認め、考慮に入れます。プロセスに組み込むことで、これは技術的な負債として、迅速な優先順位付けとリファクタリングです。

スクラムは一般的なフレームワークであるため、それ自体は技術的な慣行を規定していません。

アジャイルソフトウェア開発には、チームの卓越した技術が必要です。これは、XP（エクストリームプログラミング）の技術的な実践に基づいています。たとえば、リファクタリング、tdd、チーム全体、ペアプログラミング、インクリメンタルデザイン、ci、コラボレーションなどについて学ぶ必要があります。

このようにすることで、変更を迅速かつ安全に処理できるようになります。これは、そもそもアジャイル開発を使用する主な理由でもあります。

重要なアジャイルの1つの測定値は、定期的（毎週、隔週）に価値のある実用的なソフトウェアを顧客にリリースできるかどうかです。できますか？その後、あなたは私の本の中で機敏です。

私にとって、アジャイルの主な利点はプロジェクトのリスクを軽減することです。

反復的に配信し、ユーザーベースから多くのフィードバックを得ることにより、ユーザーが実際に必要なものを配信する可能性が高まり、最も重要な機能をできるだけ早く実用的に配信することでそれを実現できます。理論的には、これはより良い見積もりと計画で行われます。これは明らかにビジネスの観点から非常に魅力的です-リリース可能なビルドだけではありません。

この絶え間ない変化がシステムを危険にさらし、品質を低下させると主張するかもしれませんが、私は2つのことを言うでしょう。1）この変更は、従来のソフトウェアデリバリープロジェクトでとにかく発生します。これは説明されず、プロジェクトの後半で発生します。これは、ご指摘のとおり、物事を変更するのは困難でコストがかかる時期です。2）アジャイルは、経験豊富なやる気のある人とTDD、ペアリング、コードレビューなどのプラクティスを使用するという観点から、この変化への対処について多くのことを述べています。品質と継続的な改善に向けた考え方の変化がなければ、アジャイルが意味する頻繁な変更が問題を引き起こし始める可能性があることを受け入れます。

多くの場合、アーキテクチャを大幅に変更する必要があります。つまり、古いアーキテクチャに依存していたすべての機能を再実装する必要があります。

要件の変更の結果としてアーキテクチャを大幅に変更する必要がある場合は、アーキテクチャまたは要件が不適切です。優れたアーキテクチャでは、可能な限り多くの決定を延期し、システムのコンポーネントを切り離すことができます。良い（ユーザー）要件は、「別のデータベースを使用する」ようなものではありません。

それでは、適切に機能するアーキテクチャーがあるという前提の下で操作してみましょう。その場合、アジャイル開発方法論は、大規模な先行設計方法論によってこの「洗い流し」を失うことになります。結局のところ、アジャイル開発方法論のコア機能は、コードの疎結合を促進するTDDのようなプラクティスであり、プロジェクトが最初に近いものから非常に成熟したものまで高速で継続できるようにします。

多くの場合、アーキテクチャを大幅に変更する必要があります。つまり、古いアーキテクチャに依存していたすべての機能を再実装する必要があります。したがって、コスト削減の全体的な要点はここではなくなります。

アジャイルプロセスに従うと、あまりにも多くのソフトウェアが開発される前に（そして変更が必要になる前に）この要求をキャッチできる可能性が高くなります。クライアントと協力せずに何かを見せずに数か月行くと、提供する準備ができていると「考えて」初めて、これらの主要なアーキテクチャ上の問題を見つけます。

コンパイルすらしない大量のコードよりも、テストカバレッジのある実際のアプリケーションにこれらの変更を実装したいと思います。テクニカルサポートの責任者として、開発に数か月かかっていたアプリケーションのCDを渡されましたが、インストールもできませんでした。最初の週にその問題を見つけることはできましたが、長い夜だったので、代わりにダイナーを注文する時がきました。