文档介绍：敏捷开发的 6 个实战经验作者 Ulf Eriksson 摘要: Ulf Eriksson 根据自己多年的敏捷开发经历,总结了 6 个实施敏捷开发的技巧: 快速迭代、让测试人员和开发者参与需求讨论、编写可测试的需求文档、多沟通& 尽量减少文档、做好产品原型、及早考虑测试等。在大型企业中经常是各种软件开发模式混用,一些采用敏捷开发,一些则是采用传统的瀑布式或 RUP (统一软件开发过程)。敏捷开发,相对传统软件开发模式,它主要是针对快速变化的需求,不断优化管理流程,最终推出优质软件。作者是一家在线问题跟踪软件公司的创始人之一,他是敏捷开发的忠实粉丝,已经进行了多年敏捷开发的实践。下面内容主要是作者根据自己多年经历进行的经验总结。 1. 快速迭代相对那种半年一次的大版本发布来说,小版本的需求、开发和测试更加简单快速。一些公司,一年仅发布仅 2~3 个版本,发布流程缓慢,它们仍采用瀑布开发模式,更严重的是对敏捷开发模式存在误解。由一年发布 2个版本转到一个月发布 2个版本,这也不太可能。但是现在来看,快速迭代已经成为事实标准,关键是要比目前的版本发布速度更快一些。快速迭代,可以逼迫团队不断优化流程、提升工作效率,不要在无足轻重的事情上浪费时间。如果离 deadline 还有 6个月,那么整个工作节奏必然悠哉。如果每月发布一个版本,那么较以前效率必然会更高。如果发布周期过长,导致无法尽快发现用户需求,进而无法及时改进产品。 2. 让测试人员和开发者参与需求讨论需求讨论以研讨组的形式展开最有效率。研讨组,需要包括测试人员和开发者,这样可以更加轻松定义可测试的需求,将需求分组并确定优先级。同时,该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高,大家更活跃,参与感更强。确定需求时,不要过度盯在细节上。需求报告过于详细,就是一种不敏捷的****惯,还浪费大家的时间。当然,不能错过好点子,但就是不要太细,因为项目真正实施起来时需求将会产生很大的变动。 3. 编写可测试的需求文档开始就要用“用户故事”(User Story )的方法来编写需求文档。这种方法, 可以让我们将注意力放在需求上,而不是解决方法和实施技术上。过早的提及技术实施方案,会降低对需求的注意力。规划业务需求,可以采用“3W模板”,也就是: ?谁( Who ) ?是什么( What ) ?为什么( Why ) 上面的 3W实际上就是描述了相关利益者是谁,他们想要什么,他们为什么有这种需求。下面举一例子进行说明: 谁( Who ) 是什么( What ) 为什么( Why ) 用户希望借助一个应用程序在不同服务器间传输文件为了存储项目数据为了更加接近“用户故事”,我们可以改写为: 谁( Who ) 是什么( What ) 为什么( Why ) 消费者/用户想将归档过程数字化为了增强沟通,提高分享效率敏捷项目中编写用户故事有一个常用模板:作为一名[用户类型],我想要[需求],以便于[原因]。应用到这个例子,就是:作为一名用户,我想要将归档程序数字化,以便于增强沟通、提高分享效率。多数情况下,需求内容需要更加充实和详细,这一步要放到后面做,开始不要这样。用户故事的方法有时会因过于简短、不断重复而受到批评。这里我们必须明白:需求文档不是散文或诗歌,应该清晰、简明地描述用户需求