アジャイル手法を使用する際に優れたデザインを取得する方法は？

私は約3年間アジャイル手法（SCRUM）を使用しており、特に多くのレベル（実装された機能への早期アクセス権を持つ顧客から、機能をテストできるテスターからの短期フィードバックで）それらが実装されるとすぐに、レビューなどを通じて新しいコードに関する非常に早いフィードバックを提供できる他の開発者から。

一方、私は2つの未解決の問題を抱えています。最初の問題については、この質問で説明します。

問題：良いデザインを得るのが難しい

コードが乱雑になり次第、リファクタリングを試みます。できる限り単体テストを作成します（これは一般的なバグ、特にリファクタリングの際に役立ちます）。一方で、毎日のコミットで少しずつ複雑な機能を開発し、構造化されていないコードを継続的に再考すると、本当に良いデザインを作成できません。

最近作成した唯一の適切に設計されたモジュールは、別のアプローチをとることで得られました：数日間問題を分析しました（実際に問題に取り掛かる前に数か月間、問題が頭に浮かびました） ）、関係するすべてのクラスとそれらの関係の詳細な設計をさらに数日間スケッチし、その後約3週間作業を中断せずにオフィスに閉じ込めてコード全体を書き留めました。結果は、私がしばらくの間作り出した最高のものであり、バグを見つけたり修正したりするのはかなり簡単で、それ以降は関連する変更を必要としない非常に明確な設計でした。

そのため、これまでは、全体像が魔法のようにプロセスに現れることを期待して、少しずつコードを書き始めるよりも、事前にやりたいことの全体像を把握する方がはるかに効果的でした。私の最善の努力により、小刻みの開発アプローチは常に私をより悪い設計へと導いてきました。

質問：同様の経験がありますか？SCRUMを間違った方法で適用しているのですか、それとも少しずつ開発しても、うまく設計されたソフトウェアを作成したい場合、何に注意する必要がありますか？または、実際のコーディングを開始する前に、デザインユーザーストーリーをスケジュールする必要がありますか？少なくとも平均よりも複雑な機能については、これは良い習慣と考えられていますか？

編集-注

良いデザインは絶対的なものではなく、それ自体に価値はありませんが、コンテキストに依存するという事実と、手近な問題に十分なデザインを目指すべきであるという事実を知っています。

たとえば、（1）できるだけ早く準備する必要がある、（2）一度だけ使用する、（3）しないという単純なコンポーネントを実装する必要がある場合、良いデザインを（あまり）気にしませんシステムの他の部分（YAGNI）によって使用されます。

コンポーネント（1）が数回使用され、製品のいくつかの異なるリリースで使用される場合、（2）長期にわたって保守および拡張する必要がある場合、（3）それに応じて他の多くのコンポーネントを使用する場合、良いデザインが重要です。

一方で、毎日のコミットで少しずつ複雑な機能を開発し、構造化されていないコードを継続的に再考すると、本当に良いデザインを作成できません。

その後、それをしないでください。

すべてが素晴らしいアジャイルボックスに収まるわけではありません。多くの場合、製品にはいくつかの複雑なものがありますが、それらは個人に耕作することができず、スプリント内で正常な方法で完成させることはできません。それらをそのボックスに強制すると、トラブルが発生するだけです。しかし、これらはごくわずかです。コンポーネントの多くがこのようなものであることがわかった場合、製品所有者は（チームとともに）物事をよりうまく分割するように努力する必要があります。私はあなたがやったことのようにうまくやっています：ストーリーを取り、それを設計し、数週間かかると予想してできるだけ早くそれを打ち出します。

より一般的なケースでは、アジャイルで良いデザインを得るために私が見た3つのことがあります：

• 実際にデザインを行う -私が見た多くの場所でスプリントが始まり、コードのカウボーイが始まります。この方法では、デザインが悪くなります。アジャイルは、計画-コード-テスト-リリースの開発プロセスを変更するものではなく、より細かな部分に短縮するだけです。スプリントの最初に、必要に応じて座って、実際にソリューションを設計します。

• アーキテクト/リードを持つ -プロジェクトが十分に大きくなると、アプリケーションのさまざまな部分で作業する複数のスクラムチームになります。デザインの観点からすべてのチームが何をしているかを知ることが主な仕事である誰か（またはアプリケーションのサイズに応じて複数の人）がいると非常に便利です。彼らは質問に答えて、より調和のとれた包括的な設計に向けてチームを導くことができます。各スクラムチームには、他のチームが何をしているかのほとんどを知っているリードがいて、非常に効果的でした。

• 実用主義者になろう -これについては上記で説明した。アジャイルはツールであり、他のツールと同様です。すべての問題に適用されるわけではありません。一部のコンポーネントに適用する意味がない場合は、そこに適用しないでください。あなたの目標は良いソフトウェアを出荷することです。忘れないで。

少しずつ実装して、適切に構造化された保守可能なコードを作成することは非常に可能です。理論的には、それは非常に単純です。各変更後にコードが適切に構造化されていることを確認すれば、常に適切に構造化されます。リファクタリングする必要があるときにコードを追加し続けるため、コードの構造が不十分になります。

設計にどれだけの時間を費やしても、最終的に要件は予期せぬ方法で変更され、元の設計に適合しないコードを作成する必要があります。次に、増分変更を行う必要があります。優れた単体テストのセットがあり、リファクタリングに熟練している場合、新しい要件を満たしてもコードを適切に構造化しておくことができます。

「うまく設計された」は主観的です

あなたにとって「うまく設計された」とはどういう意味ですか？プロダクトオーナーに？顧客に？

される「うまく設計された製品の所有者の目標を」？顧客の目標は？それともあなた？

何であるあなたが考える「うまく設計されていない」まだ製品所有者の期待に応え、顧客の幸せを作りますか？それはかなり「よく設計された」です。

Good Enough and YAGNI

すべてのシステムが製品の所有者が完全なように物語を受け入れることと、顧客はそれがされ、その要件を満たしていると考えているため、ほとんどのアジャイル方法論では何も、「うまく設計された」と話さない「うまく設計されました」。

開発者は専門家であり、ベストプラクティス、適切なデザイン、イディオムを実用的に使用して、機能とストーリーを実装することが期待されています。

開発者の問題である物事を正しく行う時間を考慮していない場合、製品所有者がそれらを行うことができる時間内に物事を要求している場合、これを行う特権と、それらについて教育する責任があります技術的負債の物語の形での結果。

スクラム

_{書き留められるアジャイル方法論は、アジャイル方法論ではありません。」-ジャロッド・ロバーソン}

SCRUMは、ソフトウェア製品のライフサイクル全体を管理するツールのフレームワークであると想定されています。堅固なものであるとは考えられていませんが、開始して改善することを願っています。

私が働いたほとんどのショップには、スプリントZEROと呼ばれるものがあります。チームのシニアメンバーが製品の全体的なアーキテクチャやテーマをスケッチするためのスプリントです。

通常20を超えるストーリーは、実際に3〜5ポイントのストーリーになるまで分解されます。これらのストーリーの1つは、「チームとして、この機能をどのように設計するかについて話し合う必要があるため、割り当てられた時間を考慮して、技術的な負担をできるだけ少なくする必要があります」です。

一般的に

一般に、「適切に設計された」システムは十分であり、YAGNIに従います。

アジャイル、および特にアジャイルの実装としてのSCRUMは、製品所有者/スポンサーに対して可能な限り透過的に製品を生産する方法に関するものです。

技術的な設計/アーキテクチャに関するものではありません。これは、顧客のニーズと期待に応えるソフトウェアの提供に取り組む方法についての哲学です。「適切に設計された」部品と呼ばれるものがなければ、それ自体が失敗ではありません。それは哲学の基本的な部分ではないからです。

私たちは数か月前からスクラムを扱ってきましたが、あなたの問題に関する私の経験を共有したいと思います。

数ヶ月前、私は実装するための大きな部分を与えられました。すべての仕様を準備していたので、それに応じて新しい機能を実装する必要がありました。タスクは約5〜6週間かかることでした（私が見積もったように）。最初の1週間はデザインのみに取り組みました。タスクはやや複雑でした。仕様から結論付けたように、15の異なる状態を持つメインオブジェクトがあり、UIは状態ごとに異なる動作をすることでした。

その後、ワークフロー全体、およびDB構造とクラスを設計しました。

私の場合、他のアプローチは見当たりません。すぐにコーディングに飛び込んだら、最後に大きな厄介な混乱を抱えていたでしょう。維持することはほとんど不可能であり、それ以上の変更を加えることは非常に困難です。しかし、変更は次の2週間で行われたため、コードを修正しなければなりませんでした。これは、当初の考え抜かれた設計により、今では簡単でした。これにより、時間、お金、神経が節約されました。

この経験の後、最初に許容できるデザインを作成する価値があると確信しています。奇跡を起こして最後にデザインすることを望みます。

後視力は20〜20です。プロジェクトの最初に情報を入手して、全体を把握し、数週間でコードを記述した場合は、それを行うことをお勧めします。

獲得したすべての洞察、試行され、失敗/失敗したアプローチ、およびクライアント/ユーザーが要件を十分に提供できる能力の向上に十分なクレジットを与えていません。

成功したウォーターフォールプロジェクトの歴史を持つ人が、なぜアジャイルな方法論に切り替えるのでしょうか？

プロジェクトを開始する前に、最終目標がどのようなものであり、どの機能を実装するのか、いつ実行するのか、全体像を常に把握する必要があります。ストーリーをアトミックタスクとして処理することは、問題を求めています。将来の要件をできるだけ念頭に置く必要があります。