アジャイル方法論：早くて汚いのか、それとも最初に計画するのか？

アジャイルの質問：アジャイルは物事を立ち上げて「迅速かつ汚い方法」で実行することを信じますか、それともアジャイルは根本からしっかりと構築することを好みますか？または、これは方法論の質問ではなく、ケースバイケースで評価する質問ですか？

構造自体の多くをすでに構築した後、私は技術的にシステムの基礎を「再構築」しています...莫大な量の作業ではありません...アジャイルでは、最初にフロー全体を仕様化して分析する必要がありました。微調整してからビルドしますか？この方法の方が良いように感じます...乱雑なシステムを配置すると、それがどのように行われる必要があるかがよくわかります...一方、それはあまり体系化されていません...何が最良の開発であるかに興味があります実践はこれに関してです。

私はプロトタイピングと使い捨てコードについて質問していないので、この質問はアジャイルとプロトタイプとは少し異なると思います。プロダクショングレードのコードのアジャイルに興味があります。

アジャイル方法論は最初に計画されます。最初にすべてを計画するだけではありません。実際、要件を収集し、設計、コード化、テスト、展開、および提示します。展開してフィードバックを得ることができる最も小さな小さな機能を2週間以内に（ギブまたはテイク）実行するだけです。次に、別の機能を追加したり、古い機能を微調整したりします。

重要なのは、変更を受け入れるコードを記述して、最終的に「フロー全体の流れ」を確認したときに、コードを変更してそれを実行できるようにすることです。そのようにして、「流れが進むべき道」（または何でも）が再び変化しても、それは外傷的ではありません。

速くて汚いことはできません。素早くて汚いので、コードがおかしくなります。小さく働くことで速くなります。知識を広めないことで柔軟性を保ちます。理想的には、単一の機能変更はコードの1箇所だけに影響を与えるはずです。

計画を立てる以外に何時間も費やすことはできません。計画を立てることはできますが、計画を変更できるようにする必要があります。計画を変更する理由をすばやく見つける必要があります。計画が順調に進んでいて、そこから学べる驚きがない場合、つまり、計画が長すぎた場合です。計画とコーディングは、互いに近接して行う必要があります。あなたが学んでいるなら、計画が古いほど、それはごまかしです。

長期的には、よりスマートになることを計画する必要があります。柔軟なコードを記述します。その後、賢くなることは後悔につながりません。

ほとんどの人にとってそれは「素早い、汚い」または「前もって大きなデザイン」のどちらかだと私は嫌いです。彼らは他の選択肢があるとさえ考えていません。

アジャイルは、システムの構築に関するものであり、開発の後半でさえ、変更は簡単です。これは、小さな増分チャンクでソフトウェアを構築し、堅牢な自動テストでそれらのチャンクの動作をロックダウンすることによって行われます。また、本番環境への自動展開を頻繁に使用して、これらの変更の価値を検証します。

堅牢な自動テストを行うことにより、長期間にわたって増分リファクタリングを行うことで、アーキテクチャの最も難しい部分を変更することも簡単になります。したがって、プロジェクトの途中でアーキテクチャを改善できるとわかっていても、現実的には比較的迅速に変更を加えることができます。

一部の人々は、「前もっていくつかのデザイン」がアジャイルで良いと言います。ただし、後でこの設計を反復する場合でも、開発文化が変更しやすいシステムを生成することを確認する必要があります。したがって、「SDUF」は、堅牢なテスト、積極的なリファクタリング、継続的なデプロイの必要性を無効にするものではありません。

「変更の容易さ」をシステムに組み込むことにより、プロジェクトの初期設計を後で変更することができるため、一から考える必要はありません。「クイックでダーティー」なアプローチは、ほとんどの人が「スパイク」と呼んでいますが、価値のある機能を安定させる場合にのみ使用できます。ただし、変更が遅くなるため、コードベースにハッキングされたコードを長時間残さないでください。

どちらでもない。

それは、「シンプルに始めて、前進しながら改善する」ことです。

速くて汚れていると壊れやすくなりますが、速くなります（プロジェクトが十分に小さく、寿命が短い場合）。

最初の計画は厳格ですが、安定しています（プロジェクトが財政的または時間的制約に直面する前に完了した場合）。

アジャイルは上記の2の代替です。これは、機能が機能ごとに1つずつ完了するという反復的なアプローチに依存しており、プログラムのこれらの完全に機能する部分を完了する間に得られた知識は、開発の進行に応じて計画を具体化および調整するために使用されます。そのためには、事前に計画を立てる必要があります。少なくとも、個々の機能に必要な作業量を見積もるのに十分な計画が必要です。

アジャイルの主な特徴の1つは、短い反復を行ってから再評価することです。あなたは新しい領域を探索し、そこから学び、そして計画を立てるために走ります。そうすればあなたの計画はより良くなるでしょう。そして、失敗した場合（コースのアイデアがうまくいかない場合）、「すぐに失敗した」ことになります。これは良いことです。

だからあなたのアプローチは結構です。でも危険なのは、「いいですね、うまくいきました。これで終わりです。次は何ですか？」完了していません。まっすぐにするためのカットコーナーがたくさんあります。アプローチが機能し、実行可能なシステムを生み出すことが明らかとなったら、適切に実行するための時間を確保する必要があります。それは、テスト、ドキュメント、StyleCopを作成し、最適化し、何をしたか、どのようにしたかを同僚に教育したり、レビューしたりすることなどです。

上記の回答に加えて、主要な原則はYAGNIです。事前の設計と計画が次のステップを可能にする場合は、問題ありません。しかし、それがあなたが証明できない架空の将来のステップが必要になる場合は、YAGNIを想定します。

トップダウンとボトムアップの両方の多くの設計では、大幅なコードの再利用が想定されています。ただし、まったく同じ問題を解決することはめったにないため、コードの再利用はそれほど一般的ではありません。今後、その問題のバリアントを解決する必要がある場合は、将来的に設計をリファクタリングしてそのバリアントを追加しますが、現時点では考慮しないでください。

つまり、当面のタスクを計画しますが、これ以上先を計画しないでください。