素早い開発は文書を書く必要がないという意味ですか？

敏捷開発後に文書を書かないというのは、すばやい開発に対する大きな誤解です。

すばやい開発のポイントは、文書を使わないことではなく、軽い文書です。

このような軽さは私も言ったことがあります。新しいシステムの開発には全體的な方案や構造があってから軽いほうがいいです。

どのように軽い文書を理解するかについて、すみません、scrumの中のproduct backlogsとsprint backlogsを見てください。

これは文書の一形式であり、この文書には需要、ビジネスシーン、構想の実現、検証、テスト方法、試算など複數の內容のuser storyによる追跡が含まれています。

従來のソフトウェアエンジニアリングの考え方ではなく、複數のドキュメントに分割します。

すばやい開発はコミュニケーションを重視し、軽い文書です。

文書は適度にしなければならない。プロジェクトチームの邪魔にもならないし、論爭がある時にも調べられる。

まず必要な文書を二つの部分に分けます。

の

機能、インタラクティブ方式、エラー、または境界狀況の表現を全體的に説明する必要はありません。このような文書は、製品マネージャーが言語を組織して文書を書いたり、文書を開発して読んだりします。文書を理解するには、時間がかかります。全體的にまとめて作成する必要があります。

一方で、良好な

習慣としては、どんなコミュニケーションによって生み出された結論も保存すべきです。メールはより良い形式です。

會議が終わるたびに、結論を聞きますが、誰がメモを取りますか？文書は重要ではないというのではなく、會ってコミュニケーションすることで、文書が必要な細部の內容を共有します。

概要設計の詳細設計は、需要ロジックが容易ではなく、規模によって異なります。

ロジックが複雑なプロジェクト、概要設計は開発の理解を助ける手段とします。

大型プロジェクトは、詳細な設計アーキテクチャの設計が避けられない。

一言で言っても規模の需要なら、勝手にやってもいいです。

この中では常に面と向かって意思疎通を行います。前提はプロジェクトメンバーがあまりにも融通がきかないことです。