需求不写文档只写故事卡片，一般我也会写验收条件，或者写改动点（看具体情况，目的是开发能理解需求到底是什么），通过大量的Conversation完成细节。这些动作都是按Story的3C原则落实的。
同时继续维护Use Case文档。这个是作为系统说明书的开发基本不太看了。重点是用例和算法，业务规则等。

 

在代码之前编写测试：测试本身可以用来阐释真正需要的设计。设计的缺陷常常是通过测试用例被发现的。想想看，编码之前，通过这些用例，可以节约多少时间。但是，为用例1编写测试，然后编码，然后再开始用例2。

 

敏捷开发是重沟通，轻文档。文档要适度，既不能成为项目团队的累赘，也要出现争议的时候有具可查。

先说需求文档，分为两部分，一方面是框架性的需求文档，对功能、交互方式、出错或边界情况的表

 

我记得敏捷的一个原则是轻文档，但是轻文档不等于不需要文档，开发过程中的需求文档、概要设计和详细文档，这些最基本的文档依然是必须的，这些文档的作用不仅仅是项目当时的需要，也是一种知识的沉淀，对于后续接触的人员是非常重要的。

 

软件设计的目标是成功开发出一个成品，让用户可以使用它。 

 

在做项目的过程中，我们往往过份关注了软件的扩展性与易用性，以致于过度的分析需求，不但提供了一些用户用不着的功能，也让用户投入了不需要花费的资金，同时，我们还浪费了大量的时间。 

 

文档这个东西总是让人很纠结，做的时候不想写，真正想要看，到时候又没有，敏捷里用到一个词“演进”，演进的架构，演进的需求，你现在做哪些东西你就写哪些东西，不用考虑大而全的东西，因为计划没有变化快。

 

敏捷的一个原则是轻文档，但是轻文档不等于不需要文档，开发过程中的需求文档、概要设计和详细文档，这些最基本的文档依然是必须的，这些文档的作用不仅仅是项目当时的需要，也是一种知识的沉淀，对于后续接触的人员是非常重要的。

对于怎么理解轻文档，我建议你好好看下scrum里面的product backlog和sprint backlog。注意这就是文档的一种形式，而且这种文档包括了需求，业务场景，实现思路，验证和测试方法，估算等多个内容的按user story的追溯。而不是按传统软件工程思路拆分为多个文档。