スクラムでデザインをどのように扱いますか？
スクラムでデザインをどのように扱いますか？スクラムの反復ごとに、まだよく書かれた設計ドキュメントがありますか？ UMLダイアグラムを使用したデザインノートを作成しますか？または、コメントの付いたコードがありますか？
各イテレーションには設計の変更が含まれる可能性があるため、新しい開発者がドメインを理解し、可能な限り迅速に参加できるように、新しい開発者がこれをどのように捉えるかを知りたいだけでした。
スクラムだからといって、すべてのスプリントが変更されるわけではありません。
スクラムとは必要なことを行う（それ以上ではない）についてです。設計を行う必要があり、文書化する必要があります。金額は決まっていません。
各スプリントの計画の一部は、実行する必要があることを決定しています。バックログの何かが他に影響を与えるために設計する必要がある場合は、設計プロセスに特定のタスクを追加し、実装タスクの前にそれを行う必要があります。
私はこのトピックについて多くのことを言う必要があります。企業/チーム/人々がソフトウェアにアジャイルアプローチを使用していると言う多くの事例を見てきましたが、実際には、彼らは原則に固執することなくアジャイルメソッドが約束する報酬を享受したいと考えています。
迅速なイテレーションを機能させるには、テスト駆動開発を行う必要があります（TDDをしぶしぶと行う必要があるとは言い切れませんでした）。 TDDでは、テストはコードの設計と意図を表現します（「コードはドキュメントです」と言うとき、テストはドキュメントです）。手元にある機能の理解を表す単体テストを作成することにより、コードが何をする必要があると確信しているのかを明示的に述べることになります。次に、それを行うコードを記述します。次に、そのコードをリファクタリングして、優れたアーキテクチャプリンシパル「Red-Green-Refactor」に準拠します。
すべてのチェックインで（またはすべてのチェックイン前であっても）単体テストを実行すると、作成した新しいコードがアプリケーションの他の領域で期待される機能を損なうことがないことが確認されます。これにより、無謀な破棄でコードを変更できるセーフティネットが提供されます。目前の要件に対する理解が深まるにつれて、新しい知識を反映するようにテストを変更できます。本当のデザインはユニットテストにあります。他のすべて（カバーされていないコードを含む）は嘘です。
ここにいくつかの推奨読書があります
これらは、アジャイル開発に真にアプローチする方法を学ぶために探し始めるための良い場所です。
スクラム はプロジェクト管理の方法論であり、ソフトウェア開発の方法論ではありません。スクラムは通常、アジャイル手法と組み合わせて使用されます。そこにあなたの答えがあります。
プロジェクトの全体的なアーキテクチャと高レベルの設計は、プロジェクトオーナーがストーリーを作成するときに、スクラムチームの外で行われます。
ストーリーと顧客の期待との関係を確認するのに役立つように、あらゆる形式で書き留めた十分な全体的なデザインが必要です。
各ストーリーに必要な設計の一部は、計画中に計画と製品所有者との交渉で行われます。
ストーリーのデザイン作業の大部分はスプリントで行われます。
ストーリーを見積もるのに十分に定義されていない場合は、タイムボックスを現在のスプリントに確保して、後のスプリント用に適切なストーリーを作成できるように十分な設計作業を行うことができます。
スクラムは アジャイル値 に基づく反復および増分モデルです。つまり、個別の設計フェーズはありません。アイデアは、プロジェクト全体で常に分析、実装、テスト、および統合を扱っているのと同じように、常にデザインを扱っている必要があるということです。
これを機能させるには少し計画が必要です。 スプリント計画会議に参加します。ここで、チームはスプリントのタスクを予測します。ほとんどの人は、これが見積もり会議だけでなく、設計作業であることを理解していません。たとえば、「新しい車種のコードを追加する」というタスクが考えられます。これをまだ見積もることはできません。もう少し知っておく必要があります。したがって、チームは設計について話し合い、幅広いソリューション（「サブクラスCar？」）を考案し、それをタスクのリマインダーとして追加します。それ以上の形式が必要になることはめったにありません。これで、問題を解決する方法がわかりました。まだすべての詳細がありませんが、それで問題ありません。快適な見積もりを行うために、設計の十分を知っています。 （この時点で）ダイアグラムをまったく作成する必要はありません。
実際の物理的なドキュメントの場合、私は 推奨 すべての人が見られるように壁にシステム概要図を作成します。概要には、最も重要なクラスとモジュールが含まれていればよく、更新する必要はほとんどありません。また、システムで最も重要なクラスの状態図をいくつか作成すると、非常に役立ちます。典型的なユースケースのいくつかの選択されたシーケンス図をふりかけて、人々が物事がどのように接続されているかをすばやく確認できるようにします。コードからクラス階層図を生成できると思いますので、問題は簡単に解決できます。
すべての図は実際の実装後に作成されることに注意してください。これは、「包括的なドキュメントに対応する実用的なソフトウェア」とジャストインタイムの設計に沿っています。
そして、可読コードは間違いなくドキュメントです。
要件が頻繁に変更されるほど、事前の設計はありません。したがって、通常、クラスレベルまでの設計は時間の無駄です。ただし、より高いレベルのアーキテクチャ上の決定をスケッチすることは価値があります。
ヘビーデューティの設計ドキュメントを作成する際の問題は、作成されてすぐに時代遅れになることです。したがって、最も効果的に機能するのは、通常、短時間で完全に変更される可能性が低い高レベルのドキュメントです。
今日、Eclipseコミュニティー内では、モデルがコード/開発を推進する従来のUMLツールと、反復が開発プロセスを推進し、モデルだけを推進すべきではないと考えるOmondoの間で、分裂が生じています。
UDDは他のチームメンバーと通信するために標準化されているため、UMLは本当に優れた方法ですが、MDDはくだらないので、私はそれらに同意します。 
私が理解しているのは、プロジェクトの最初に収集した事前の要件を使用して、より高いレベルの設計を行うことです。この設計をよく文書化します。
次に、実際に要件を実装するときに、必要に応じて下位レベルの設計を変更しますが、上位レベルの設計は変更しません。
とにかく、それはとにかくそれが5分前に私に説明された方法です...