スクラムでデザインをどのように扱いますか？

スクラムでデザインをどのように扱いますか？スクラムの繰り返しごとに十分に書かれた設計文書がまだありますか？UMLダイアグラムをフィーチャーした設計ノートを作成するだけですか？または、よくコメントされたコードがありますか？

各イテレーションにはデザインの変更が含まれる場合があるため、新しい開発者がドメインを理解し、できるだけ早く参加できるようにするため、人々がこれをどのように捉えるかを知りたかっただけです。

スクラムだからといって、すべてのスプリントがすべて変わるというわけではありません！

スクラムとは、必要なこと（しかしそれ以上）を実行することです。設計を行う必要があり、ドキュメントを作成する必要があります。その量は固定されておらず、その方法も固定されていません。

各スプリントの計画の一部は、何をする必要があるかを決定することです。バックログが何かに影響を与えるために設計する必要がある場合、設計プロセスに特定のタスクを追加し、実装タスクの前にそれを行う必要があります。

私はこのトピックについて多くのことを述べています。企業/チーム/人々がソフトウェアにアジャイルアプローチを使用していると言っている多くのケースを見てきましたが、実際には、彼らはアジャイルメソッドが原則を遵守せずに約束する報酬を獲得したいと考えています。

迅速な反復が機能するためには、テスト駆動開発を行う必要があります（不本意ながらTDDを行う必要があると言って間もなく停止しました）。TDDでは、テストはコードの設計と意図を表現します（「コードはドキュメントです」と言うとき、彼らが言うべきことは「テストはドキュメントです」）。手元の機能の理解を表す単体テストを記述することにより、コードが実行する必要があると思われることを明示的に示します。次に、それを行うコードを記述します。次に、適切なアーキテクチャプリンシパル「Red-Green-Refactor」に準拠するように、そのコードをリファクタリングします。

すべてのチェックインで（またはすべてのチェックインの前でも）ユニットテストを実行すると、作成した新しいコードがアプリケーションの他の領域で予期される機能を壊さないことが確認されます。これにより、問題なくコードを変更できるセーフティネットが提供されます。手元の要件に対する理解が深まると、その新しい知識を反映するようにテストを変更できます。実際の設計は、単体テストにあります。他のすべて（カバーされていないコードを含む）は嘘です。

ここにいくつかの推奨読書があります

• きれいなコード
• アジャイルソフトウェア開発の原則、パターン、および実践
• 実用的なプログラマー

これらは、アジャイル開発に真にアプローチする方法を学び始めるのに適した場所です。

スクラムはプロジェクト管理の方法論であり、ソフトウェア開発の方法論ではありません。スクラムは通常、アジャイル手法と組み合わせて使用​​されます。そこにあなたの答えがあります。

要件が頻繁に変わるほど、前もって設計されているわけではありません。そのため、通常、クラスレベルまで設計することは時間の無駄です。ただし、より高いレベルのアーキテクチャ上の決定をスケッチする価値はあります。

ヘビーデューティな設計ドキュメントを作成する際の問題は、作成されてすぐに廃止されることです。したがって、最も効果的に機能するのは、通常、短時間で完全に変更される可能性の低い高レベルのドキュメントです。

スクラムは、アジャイル値に基づいた反復的で増分的なモデルです。つまり、個別の設計段階はありません。アイデアは、あなたがすべきことである常にあなたが常にプロジェクト全体の分析、実装、テスト、および統合を扱っているのと同様に、デザインを扱うこと。

これを機能させるには少し計画が必要です。入力スプリント計画会議のチームが先にスプリントのためのタスクを推定し、。ほとんどの人は、これが推定会議であるだけでなく、設計作業でもあることに気づいていません。たとえば、タスクは「新しい車のモデルのコードを追加する」かもしれません。これはまだ推定できません。もう少し知る必要があります。そのため、チームは設計について議論し、広範なソリューション（「サブクラスカー？」）を考え出し、それをタスクのリマインダーとして追加します。あなたはそれ以上の形式を必要とすることはめったにありません。これで、問題の解決方法がわかりました。まだすべての詳細を把握しているわけではなく、それで十分です。十分な設計を知っているので、快適に見積もることができます。ダイアグラムをまったく作成する必要はありません（この時点で）。

実際の物理的なドキュメントについては、すべての人が見ることができるように壁にシステム概要図を作成することをお勧めします。概要には、最も重要なクラスとモジュールを含めるだけでよく、ほとんど更新する必要はありません。また、システム内の最も重要なクラスの状態図をいくつか作成することは非常に役立ちます。一般的なユースケースのいくつかの選択シーケンス図を振りかけ、人々が物事がどのように接続されているかをすばやく簡単に確認できるようにします。コードからクラス階層図を生成できるため、この問題は簡単に解決できます。

すべての図は、実際の実装後に作成されることに注意してください。これは、「包括的なドキュメントよりも機能するソフトウェア」とジャストインタイムの設計を維持しています。

そして、はい、読み取り可能なコードは間違いなくドキュメントです。

プロジェクトの全体的なアーキテクチャと高レベルの設計は、プロジェクトオーナーがストーリーを作成するときにスクラムチームの外部で行われます。

ストーリーと顧客の期待との関係を理解できるように、あらゆる形式で書き留めた全体的な設計が十分に必要です。

各ストーリーに必要な設計の一部は、計画中に計画し、製品所有者と交渉する際に行われます。

ストーリーの設計作業の大部分はスプリントで行われます。

ストーリーの見積もりが十分に定義されていない場合、現在のスプリントにタイムボックスを確保して、後のスプリント用に適切なストーリーを作成できる十分な設計作業を行うことができます。

私の理解では、プロジェクトの開始時に収集する事前要件を使用して、より高いレベルの設計を行うということです。この設計をよく文書化します。

次に、実際に要件を実装するときに、必要に応じて下位レベルの設計を変更しますが、上位レベルの設計は変更しません。

とにかく、それが5分前にとにかく私に説明された方法です...

現在、Eclipseコミュニティ内では、モデルがコード/開発を推進するMDDに焦点を当てた従来のUMLツールと、モデルだけでなく、反復が開発プロセスを推進すべきであると考えるOmondoとの間で分裂しています。

MDDはがらくたであり、UMLは他のチームメンバーと通信するために標準化するため、本当に優れた方法であるため、私は彼らに同意します。