作者：郭振宇，新炬网络高级技术专家。
本人看过一些敏捷开发的书籍，结合在工作实践中的经验，在这里与大家分享一下心得。在大型企业中经常是各种软件开发模式混用，一些采用敏捷开发，一些则是采用传统的瀑布式或RUP（统一软件开发过程）。
传统软件开发模式整个过程为需求分析、系统设计、任务分解、计划安排、开发设计、编码、测试、交付、验收、维护。每个流程都分割为相互独立的阶段，每一步骤都必须等待前一步骤结束后才能继续，也只有等待所有步骤结束后才有可能向客户交付价值。人们往往在开始实现之前先进行“完美化”设计，而美中不足之处就在于这词语太不现实了，对于互联网软件开发经常会出现变化万千，需求不稳定，固然传统开发模式已经难以适应。
说起敏捷开发，并不是因为敏捷而敏捷。这几年的敏捷开发已经被很多人炒作得变了神话，这个东西并不是神器，不是实施了就可以解决所有软件公司的问题，而是要结合自己公司的特点和问题摸索出适合自己的一套模式。敏捷开发相对传统软件开发模式，它主要是针对快速变化的需求，是一种增量式的软件开发过程，早交付、频交付。敏捷团队做的开发工作和瀑布团队一模一样，但他们的做事方式很不一样，敏捷开发周期使用的职能和瀑布方式一样也是需求收集、设计、编码和测试。简单地看，敏捷开发区别在于会做一点点需求收集，一点点设计，编码和测试，最后交付一点点价值给客户，再重复此过程……周而复始，工作推进过程不断改善、调整流程，一直到项目完成为止。在其中，Scrum方法在国内已被逐渐普及，为众多知名IT公司和软件开发团队采用。
Scrum方法的角色可分为：
1) 产品负责人：业务代表、客户代表、拥有产品列表、规定故事优先级、设立故事接收标准、回答团队成员的问题
2) Master：专家、教练、引导者
3) 团队成员：负责交付产品、做开发工作、自组织地交付产品
Scrum方法的简单流程如下：
产品迭代周期一般为1周—4周比较合适，那么效率必然会更高。如果发布周期过长，导致无法尽快发现用户需求，进而无法及时改进产品。
1) 产品负责人将整个产品的用户需求的功能分解成列表。
2) 召开产品sprint规划会议，按优先级排序确定和承诺第一个sprint中交付物，预估每个backlog的时间，即sprint的backlog。（sprint可以理解为一个周期的交付物）
3) 把sprint的backlog列出来，让大家认领分配或者负责人分配。
4) 举行每日站立会议，让大家在每日会议上总结昨天做的事情、遇到什么困难，今天开展什么任务。（时间最好控制在15分钟内）
5) 绘制燃尽图，保证任务的概况能够清晰看到。（燃尽图把当前的任务总数和日期一起绘制，每天记录一下，可以看到每天还剩多少个任务，直到任务数为0 ，这个sprint就完成了）
6) 故事时间，定期开会讨论将要做的事情。
7) sprint成果评审，是在sprint完成时举行，要向客户演示自己完成的软件产品，收集反馈。
8) 回顾会议，每个人轮流发言，收集上一次sprint中遇到的问题，继而洞察问题，确定改进方案，大家一起分享讨论。
9) 结束：感谢团队，予以称赞。
10) 进入下一个sprint。
大家都知道，很多创业公司刚开始需要研发出一款产品并且能够使公司赚钱的产品，不过大部分创业公司没有那么容易一下就能做出来，很多公司还没有成功的产品资金链就断掉了，公司也死掉了。做技术创新为未来能够开发一款人气爆棚的产品摸索着，但是又不能饿着肚子去开发。我们是如何结合自身的特点实施敏捷开发的呢？下面内容主要是我根据自己多年经历进行的经验总结：
1.快速迭代，及早且频繁地交付产品
只有通过早交付，频交付，展示可工作软件的方式，你才能发现客户真正想要的是什么。正因为敏捷流程能够照顾到客户的持续反馈，项目才能不偏不倚地走下去，以定期增量的形式持续地交付价值，也因为只交付已完成的增量，敏捷开发才能规避项目被取消的风险。
2.让测试人员和开发者参与需求讨论
需求讨论以研讨组的形式展开最有效率。研讨组，需要包括测试人员和开发者，这样可以更加轻松定义可测试的需求，将需求分组并确定优先级。同时，该种方式也可以充分利用团队成员间的互补特性。如此确定的需求往往比开需求讨论大会的形式效率更高，大家更活跃，参与感更强。
一般我们记录某个需求条目的时候都会考虑到用户场景，以一个故事的形式表述出来。用户故事是从用户的角度来描述用户渴望得到的功能。一个好的用户故事包括三个要素：
1) 角色：谁要使用这个功能。
2) 活动：需要完成什么样的功能。
3) 商业价值：为什么需要这个功能，这个功能带来什么样的价值。
可利用思维导图软件（例如Mindjet）协助需求记录。
3.多沟通，文档边做边写
沟通这词语相信大家都听得耳熟能详，在这里也不厌其烦地说多一遍，任何项目中，沟通都是一个常见的问题，好的沟通，是敏捷开发的先决条件。在圈子里面混得越久，越会强调良好高效的沟通的重要性。团队要确保日常的交流，面对面沟通比邮件强多了。
只写必须的文档，将文档工作融入流程，只写有关的，有效用的文档，不要让任何个人或部门成为流程、信息的瓶颈。
4.做好产品原型
建议使用原型设计工具软件（例如Axure）来阐明用户界面。并不是所有人都可以理解一份复杂的文档，但人人都会看图。一个常见的问题是软件的功能与用户想要的不一致，为了避免这一问题，可以模拟真实操作，改进模拟操作过程中难以理解和不清楚的操作行为。
5.及早考虑测试，边做边测试
较早地开始编写测试用例，当需求完成时，可以接受的测试用例也基本一块完成了。测试别等到最后关头，现在就修复缺陷，等它有机会在系统里繁衍好几个月后，修复成本可就高了。
新炬网络公众号