敏捷开发的6个实战经验

在大型企业中常常是各类软件开发模式混用，一些采用敏捷开发，一些则是采用传统的瀑布式或RUP（统一软件开发过程）。敏捷开发，相对传统软件开发模式，它主要是针对快速变化的需求，不断优化管理流程，最终推出优质软件。

原文做者Ulf Eriksson，是一家在线问题跟踪软件公司的创始人之一，他是敏捷开发的忠实粉丝，已经进行了多年敏捷开发的实践。下面内容主要是做者根据本身多年经历进行的经验总结。

1. 快速迭代

相对那种半年一次的大版本发布来讲，小版本的需求、开发和测试更加简单快速。一些公司，一年仅发布仅2~3个版本，发布流程缓慢，它们仍采用瀑布开发模式，更严重的是对敏捷开发模式存在误解。
由一年发布2个版本转到一个月发布2个版本，这也不太可能。可是如今来看，快速迭代已经成为事实标准，关键是要比目前的版本发布速度更快一些。
快速迭代，能够逼迫团队不断优化流程、提高工做效率，不要在无足轻重的事情上浪费时间。若是离deadline还有6个月，那么整个工做节奏必然悠哉。若是每个月发布一个版本，那么较之前效率必然会更高。若是发布周期过长，致使没法尽快发现用户需求，进而没法及时改进产品。
2. 让测试人员和开发者参与需求讨论
需求讨论以研讨组的形式展开最有效率。研讨组，须要包括测试人员和开发者，这样能够更加轻松定义可测试的需求，将需求分组并肯定优先级。
同时，该种方式也能够充分利用团队成员间的互补特性。如此肯定的需求每每比开需求讨论大会的形式效率更高，你们更活跃，参与感更强。
肯定需求时，不要过分盯在细节上。需求报告过于详细，就是一种不敏捷的习惯，还浪费你们的时间。固然，不能错过好点子，但就是不要太细，由于项目真正实施起来时需求将会产生很大的变更。
3. 编写可测试的需求文档
开始就要用“用户故事”（User Story）的方法来编写需求文档。这种方法，可让咱们将注意力放在需求上，而不是解决方法和实施技术上。过早的说起技术实施方案，会下降对需求的注意力。
规划业务需求，能够采用“3W模板”，也就是：

谁（Who）

是什么（What）

为何（Why）

上面的3W实际上就是描述了相关利益者是谁，他们想要什么，他们为何有这种需求。下面举一例子进行说明：

谁（Who）	是什么（What）	为何（Why）
用户	但愿借助一个应用程序在不一样服务器间传输文件	为了存储项目数据

为了更加接近“用户故事”，咱们能够改写为：

谁（Who）	是什么（What）	为何（Why）
消费者/用户	想将归档过程数字化	为了加强沟通，提升分享效率

敏捷项目中编写用户故事有一个经常使用模板：做为一名[用户类型]，我想要[需求]，以便于[缘由]。应用到这个例子，就是：做为一名用户，我想要将归档程序数字化，以便于加强沟通、提升分享效率。
多数状况下，需求内容须要更加充实和详细，这一步要放到后面作，开始不要这样。用户故事的方法有时会因过于简短、不断重复而受到批评。这里咱们必 须明白：需求文档不是散文或诗歌，应该清晰、简明地描述用户需求；需求文档的重点也在于此，不要管形式多变或内容是否重复这样的问题。
4. 多沟通，尽可能减小文档
任何项目中，沟通都是一个常见的问题。好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。
团队要确保平常的交流，面对面沟通比邮件强得多。
敏捷开发鼓励平常的协调会议和碰头会，5~7人参与的会议尽可能控制在10分钟内。碰头时，要过一遍昨天完成了什么，今天要作什么，哪些问题仍待讨 论。能够用Burndown Chart（燃尽图）来形象展现工做进度。每次迭代的时候也都要开一个计划会议和评审会议，通常须要的时间可能会长些，好比半天。这些会议的目的就是对工 做查缺补漏。
评审会议很重要，传统开发模式每每略过该环节，致使一些错误作法不断重复，好的作法没法推广。
开会时，能够将原先的分组打散，让整个团队都参与到项目的需求讨论和测试中来，这样能够突出成员我的，让你们更乐意参与。
5. 作好产品原型
建议使用草图和模型来阐明用户界面。并非全部人均可以理解一份复杂的文档，但人人都会看图。
一个常见的问题是软件新的功能与用户想要的不一致。为了不这一问题，能够模拟真实操做，改进模拟操做过程当中难以理解和不清楚的操做行为。
6. 及早考虑测试
及早地考虑测试在敏捷开发中很重要。传统的软件开发，测试用例很晚才开始写，这致使过晚发现需求中存在的问题，使得改进成本太高。较早地开始编写测试用例，当需求完成时，能够接受的测试用例也基本一块完成了。
敏捷开发中一个常见问题就是开发者没有对已有的代码库进行充分的回归测试。迭代周期很短，从开始到交付就是4周的时间，这样能够对迭代的设计、实现和底层测试一块进行回归测试。
一系列迭代以后，能够只针对测试活动再补充一个迭代。这个迭代能够将重点放在系统测试、与其余系统的集成度、性能等方面。敏捷开发过程当中，可能会致使过少的测试文档。若是迭代周期为1个月左右，能够没必要对测试文档过于要求，但要制定好测试策略。
最后 可能大多数公司或团队尚未开始尝试敏捷开发，不过能够开始从点滴作起，好比开碰头会、为项目管理采用一个更加高效的管理工具等等。最后，但愿上面的建议可以为你们的软件开发管理带来帮助。