アジャイル開発と計画ベースの開発の本質的な違いは何ですか？
アジャイルプロセスでは、製品の所有者が非公式のアイデア/ユーザーストーリー/バックログアイテムをスプリント/反復に配置します。スプリント/反復は短期間の計画のようなものであり、毎日の会議によって推進されます。計画は両方のプロセスで行われます。それでは、アジャイルと古い計画ベースの開発の違いは何ですか？
ソフトウェアの計画的プロセスとアジャイルプロセスは、いくつかのペアですばやく特徴付けることができます。
- ウォーターフォールvs反復/増分
- ワッツハンフリー vsケントベック。
- 管理主導とチーム主導。
- SEI CMM対アジャイルマニフェスト。
- Microsoftプロジェクトとバーンダウンリスト。
- 暫定xyzレビュー対スクラム立ち会い。
- 年次リリースと日次ビルド。
- コードインスペクションとペアプログラミング。
- 計画スケジュールと計画ゲーム。
- 委員会対先見の明。
ある場合には、この質問はすでに Agile Manifesto で回答されていますが、左から右に読むのではなく、右から左に読んでください。
- プロセスとツールに関する個人と相互作用
- 包括的なドキュメントに対応する実用的なソフトウェア
- 契約交渉を介した顧客のコラボレーション
- 計画の転換への対応
上記の比較のいくつかは少し厳しいかもしれません、確かに計画された実践である多くの機能主導の開発があり、リリースは四半期ごとかもしれません（しかし毎月ではないかもしれません）。
計画されたプロセスの背後にある最良の思想家は、神話のマン月で説明されているような、ソフトウェアへのアドホックまたはあまり適さないアプローチの問題に影響されました。早くも1968年、 NATOはソフトウェアエンジニアリングに関する会議を開催しました 危機を解決しようと試み、その時点で。彼らにはいくつかの素晴らしい革新があったと思います。彼らの12ページの 会議レポート には、ウォーターフォールを説明する驚くべき描画がありますが、ボックスの代わりに曲線があります。また、ソフトウェアプロジェクトの見積もりの課題に関する資料も含まれています。その後、計画されたソフトウェアプロセスの専門家が、デミングのようなQAの先駆者や、自動車や電子機器の製造においてその価値を証明した多くの日本の専門家から借りて盗みました。
最高のアジャイル思想家は、計画されたプロセスに非常に精通していて、その長所の一部を維持しながら、その制限に反応したと思います。計画されたプロセスは、その関連性のすべてを失っていないので、大規模なプロジェクトには不可欠であると主張する人もいます。 Plannedは、特に大規模な組織でまだ広く使用されていますが、アジャイル技術とのハイブリッドを試みる人も少なくありません。おそらくSystem of Systems設計アプローチが計画されていますが、アジャイルのより実用的な場所である小さなチームを作成するという優れた特徴があります。計画は現地での調整の必要性に敏感でしたが、会議や委員会によって促進されると期待されていました。
このトピックに関する優れた参考資料には、Watts Humphriesの書籍、記事、および組織的、 team 、および個人的なソフトウェアプロセスに関する技術レポートが含まれます。 eXtreme Programming Explained のKent Beckの紹介セクションと比較してください。
私の教授の1人は、ソフトウェア開発の歴史を次のように説明しています。
- 1970年代：ツール-カンブリア紀のオペレーティングシステム、プログラミング言語、ツールの進化。
- 1980年代：プロセス-人々のせいにせず、プロセスのせいにして（そして修正して）ください。
- 1990s：People-意思決定とコミュニケーション、そして人々の間の相互作用を強化します。
理論的には@JVXRは正しいです。ウォーターフォールとは、要件を取得し、作業を計画し、価格と配送スケジュールを設定することを意味します。最後に、すべてが一緒になり、要件が間違っていたり変更されたりしていることが多く、作業は予想以上で、大きな泥の玉になります。アジャイルは、変化するニーズに対応して小さな仕事を行い、知識を増やし、定期的に顧客に価値のあるものを提供し、顧客が仕事を終えると（実際には-お金がかかると）停止することにより、ウォーターフォールのすべての問題を解決することを約束しますなくなります）。
滝の問題はよく知られており、文書化されているため、解決策を簡単に提案できます。アジャイルにも問題がありますが、それらはあまり知られておらず、文書化もされていません。業界として、私たちはウォーターフォールを試し、惨めに失敗しました。今はアジャイルを試し、失敗しています（少し悲惨なことは少ないですが、それでも失敗しています）。より良い解決策が見られる/売れるまで、それが機能しないことを誰も提案したくありません。
その結果、100のソフトウェアハウスごとに、おそらく200の「アジャイル」プロセスが使用されています（多くのショップには複数のチームがあり、アジャイルの一部はチームが好きな方法で実行できます。おそらくこれらのプロセスの10は本当にアジャイルです。残りはドラッグの滝（ドキュメントなしの滝）として最もよく説明されます。
「古い計画」とは、私がウォーターフォールを意味していると思います。製品が開発されて提供されるまで顧客からのフィードバックはありません。通常、ウォーターフォールプロセスでファンが何かにぶつかったときです。ウォーターフォールは「要件ドキュメント」に大きく依存しています。このドキュメントは、顧客が1か月間でそのようなことを一度も言わなかったことを誓います。
アジャイルでは、理論的には小さな作業増分を生成し、顧客のフィードバックを得て、それを次のリリースに組み込みます。だから、物がファンに当たる可能性が低くなります。全体として、顧客は、あなたが支払ったものから何かを得ていると感じています。
計画ベースの開発では、詳細な事前計画の作成に重点が置かれますが、アジャイル（より正確にはスクラム）では、作業が開始されるまで詳細計画が延期され、作業の順序または優先順位を変更できます。これにより、変更の影響が最小限に抑えられ、ほとんどの知識が利用可能なときに意思決定（つまり、計画）を行うことができます。一方、計画ベースの開発では、変更が発生したときに計画を改訂する必要があり、チームが問題と解決策をほとんど知らない場合は、ほとんどの決定を事前に行う必要があります。