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

すばやい開(kāi)発のポイントは、文書(shū)を使わないことではなく、軽い文書(shū)です。

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

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

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

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

すばやい開(kāi)発はコミュニケーションを重視し、軽い文書(shū)です。

文書(shū)は適度にしなければならない。プロジェクトチームの邪魔にもならないし、論爭(zhēng)がある時(shí)にも調(diào)べられる。

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

の

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

一方で、良好な

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

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

概要設(shè)計(jì)の詳細(xì)設(shè)計(jì)は、需要ロジックが容易ではなく、規(guī)模によって異なります。

ロジックが複雑なプロジェクト、概要設(shè)計(jì)は開(kāi)発の理解を助ける手段とします。

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

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

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