需求不写文档只写故事卡片,一般我也会写验收条件,或者写改动点(看具体情况,目的是开发能理解需求到底是什么),通过大量的Conversation完成细节。这些动作都是按Story的3C原则落实的。
同时继续维护Use Case文档。这个是作为系统说明书的开发基本不太看了。重点是用例和算法,业务规则等。
在代码之前编写测试:测试本身可以用来阐释真正需要的设计。设计的缺陷常常是通过测试用例被发现的。想想看,编码之前,通过这些用例,可以节约多少时间。但是,为用例1编写测试,然后编码,然后再开始用例2。
敏捷开发是重沟通,轻文档。文档要适度,既不能成为项目团队的累赘,也要出现争议的时候有具可查。
先说需求文档,分为两部分,一方面是框架性的需求文档,对功能、交互方式、出错或边界情况的表
我记得敏捷的一个原则是轻文档,但是轻文档不等于不需要文档,开发过程中的需求文档、概要设计和详细文档,这些最基本的文档依然是必须的,这些文档的作用不仅仅是项目当时的需要,也是一种知识的沉淀,对于后续接触的人员是非常重要的。
软件设计的目标是成功开发出一个成品,让用户可以使用它。
在做项目的过程中,我们往往过份关注了软件的扩展性与易用性,以致于过度的分析需求,不但提供了一些用户用不着的功能,也让用户投入了不需要花费的资金,同时,我们还浪费了大量的时间。
文档这个东西总是让人很纠结,做的时候不想写,真正想要看,到时候又没有,敏捷里用到一个词“演进”,演进的架构,演进的需求,你现在做哪些东西你就写哪些东西,不用考虑大而全的东西,因为计划没有变化快。
敏捷的一个原则是轻文档,但是轻文档不等于不需要文档,开发过程中的需求文档、概要设计和详细文档,这些最基本的文档依然是必须的,这些文档的作用不仅仅是项目当时的需要,也是一种知识的沉淀,对于后续接触的人员是非常重要的。
对于怎么理解轻文档,我建议你好好看下scrum里面的product backlog和sprint backlog。注意这就是文档的一种形式,而且这种文档包括了需求,业务场景,实现思路,验证和测试方法,估算等多个内容的按user story的追溯。而不是按传统软件工程思路拆分为多个文档。