私は主にプロジェクトでウォーターフォール方法論を使用しましたが、今ではアジャイル方法論に視野を広げています。これまで読んだことから、そしておそらく間違ったことを読んだことから、アジャイルは小さな滝を意味します。1年または2年にわたって広がる大きな滝の代わりに、最後の数週間またはせいぜい数ヶ月の小さな滝があります。
私の理解は正しいですか、それ以上のものがありますか？アジャイル哲学とは何ですか？
回答:
簡単なレベルでは、はい。2週間ごとにウォーターフォールを実行するだけではアジャイルになりませんが、反復的です（アジャイルの半分です）。
ウォーターフォールモデルは、要件、アーキテクチャ、設計、実装、検証（テスト）、検証（受け入れテスト）、およびリリースのフェーズを定義します。反復方法論では、すべての反復内でこれらの各フェーズを実行します。それらの間には重複があるかもしれませんが、要件を引き出してキャプチャし、実装を可能にするシステムのアーキテクチャと設計を採用し、新しい機能を開発するか、欠陥を修正し、新しいモジュールをテストしてから、受け入れのために顧客に提示しますテストと展開。
ただし、アジャイルには、単に反復的で増分的であるだけではありません。アジャイルのテナントは、アジャイルソフトウェア開発のためのマニフェストに取り込まれています。マニフェストには4つの重要なポイントがあります。
プロセスとツールを介した個人と相互作用
個々の人が頻繁に関与します。多くの実装は、自己組織化および自己管理チームに集中しています。ほぼ全員が、顧客または顧客の声を持っている人と頻繁にやり取りします。従うべき正式な一連の手順や使用するツールを用意するのではなく、プロジェクトに携わる人々に、プロジェクトがどのように実行されるかを駆動させ、最良の方法で実行できるようにします。
包括的なドキュメントよりも機能するソフトウェア
ソフトウェアプロジェクトの主な目標は、ソフトウェアの提供です。ただし、一部のプロジェクトでは、価値のないドキュメントの無駄な生産があります。Scott Amblerが、Agile / Lean Documentationについての良い記事を書きました。ドキュメントを作成しないことではなく、チーム、将来の開発者、顧客、またはユーザーに価値を加えるドキュメントを選択することです。付加価値のないドキュメントを作成するのではなく、ソフトウェアエンジニアがソフトウェアと関連テストを作成しています。
契約交渉を介した顧客コラボレーション
事前に条件とスケジュールとコストを定義するのではなく、顧客との継続的な努力になります。たとえば、ユーザーストーリーの形式で要件をキャプチャし、ポイントを割り当てることができます。数回の反復の後、速度（ポイント/反復）を決定し、反復でチームが実装できる機能の数を決定できます。顧客は、どの機能が最も価値を高めるかについてのフィードバックを提供するので、プロジェクトがいつ完了するかを決定できます。頻繁な配送と顧客とのやり取りでは、さまざまなことが起こり得ます-要件が満たされ、プロジェクトがメンテナンスと最終的に寿命に至りました。プロジェクト、プロジェクトは失敗しており、顧客はこれを早期に確認し、キャンセルできます...
計画に従うことによる変化への対応
大きなデザインや最終的な計画は事前に用意されておらず、その設計や計画を変更する必要がある場合はいつでも再作業を実行する必要があります。あなたは、あなたが持っている情報に基づいて、絶えず見積もりを見積もり、修正します。メトリックを慎重に選択して、プロジェクトの健全性と内部変更をいつ行うかについての洞察を提供します。顧客との要件を頻繁に追加、削除、および優先順位付けし直します。最終的には、変化が唯一の不変であることを理解します。
アジャイルであるということは、高品質で付加価値のあるソフトウェアを迅速に提供することにより、人々に焦点を合わせ、ニーズを満たすことを意味します。顧客のニーズが変化すると、それらのニーズに適応して価値の付加に集中します。アジャイル方法論の特定の実装がありますが、それらはすべて人、作業ソフトウェアのタイムリーな配信、および急速に変化する環境への適応を中心にしています。
私はそれを単純化する方法だと思います。はい、あなたがそれに着くとき、それは小さな水流ですが、それを機能させるのはそれの後ろにもっとたくさんあります。プロジェクトへのアプローチ方法を変える全体的な方法論...それに必要な考え方は言うまでもありません。
アジャイルを真剣に考えているなら、興味のあるウェブキャストの良い（そして長い）シリーズがここにあります：
アジャイルをちょっと忘れて、「滝」の意味を考えてください。
要件フェーズがあり、誰もが最終製品が解決する必要のある問題を把握しようとします。人々はこれについてしばらく議論し、その後、全員が一連の要件に同意します。この時点で、スコープが定義され、契約が署名され、顧客はあきらめて、それらの定義された要件を解決する製品を思いつくのを待つことができます。
次に、1つ（または2つ）の設計フェーズがあります。設計者（開発者である場合もそうでない場合もある）は、サインオフされた要件を満たすためにシステムがどのように連携しなければならないかについて議論します。要件を十分に理解していない場合、問題が発生する可能性があります。つまり、顧客に戻って、要件フェーズを再開する必要があります。 。多くの場合、設計者は単に最善の推測を行います。彼らは、論理データモデルと、新しいシステムとその動作方法を説明する多くのUMLを考え出すかもしれません。その後、彼らはそれにサインオフします。
開発者は、サインオフされた設計に基づいて、実際にコーディングを開始できます。設計を十分に理解していない場合、問題が発生する可能性があります。つまり、設計者に戻って設計フェーズを再開する必要があります。 。設計者は、混乱が実際に要件に戻っていることに気付く可能性があります。つまり、要件の議論、承認、および変更管理を再開する必要があります。多くの場合、プログラマー（締め切りが迫っている）は、単に最善の推測をします。彼らは機能的なコードを作成するためにできることをします。その後、テスト用にリリースします。
システムテストフェーズが開始されました。テスターは要件と設計の理解に基づいてテストを行い、欠陥として認識したものをバグ追跡/変更管理システムに登録します。設計上の欠陥など、設計に送り返すなど。最終的に、システムテストはパスし、サインオフされます。
最後に、顧客は戻ってきて、新しいシステムでユーザー受け入れテストを行います。ここで、テスターがテストし、開発者が開発し、設計者が設計したソリューションが実際に望むものであるかどうかを決定します。そうでない場合は、設計段階に戻るか、要件を再検討する必要があります。
ウォーターフォールの背後にある考え方は、フェーズが完了した後に戻ることは難しい（そして非常に望ましくない）ということです。一般に、さまざまな人がさまざまな段階に関与しているため、複数のハンドオフがあります。それぞれのハンドオフでは、誤解や情報損失のリスクが大きくなります。また、顧客が望むものを言うときと、構築されたものを見るときとの間に大きなギャップがあり、その間に実際の要件は非常によく変わったかもしれません。
アジャイル方法論は、すべての利害関係者間の強力なコミュニケーションと協力に焦点を合わせています。「契約交渉よりも顧客とのコラボレーション」という原則は、一連のサインオフやハンドオフを行う必要はなく、代わりに単純に顧客と協力して、各反復がパズルの要件を決定することを意味します。すべてのプレーヤーができるだけ直接通信することで、テスト、設計、および作業コードをすぐに作成します（ハンドオフコストとリスクを排除します）。作業コードは顧客によって迅速にテスト可能であり、タイムラグのリスクを排除します。すべてのアクティビティは、下向きの流れではなく、共同の渦巻きで発生します。
アジャイル手法が何をしようとしているのかについての優れた概要については、Allistair Cockburnのアジャイルソフトウェア開発：協調ゲームを強くお勧めします。
アジャイルプロジェクトの静的構造（プロセス定義）を見ると、多くの小さな滝のように見えます。しかし、アジャイルプロジェクトの目標は、より迅速で優れたフィードバックを得ることです。
アジャイルマニフェストは、（署名した人々によって知覚される）アジャイルとウォーターフォールの間にいくつかの違いを強調しています。