敏捷开发的八个实践经验

敏捷开发的八个实践经验

敏捷开发越来越火热，但在实际应用当中很多时候都是只有敏捷的“形”，却缺少敏捷的“神”，还只是在摸索中。敏捷开发对产品经理/程序员的要求都是很高的，此外还需要各个业务部门对敏捷的理解和支持，形成合力。以下分享产品项目里的八个敏捷开发实战经验。

在《Scrum：兼顾计划与灵活的敏捷开发》一文中，作者最后也提到过，借鉴一种新的模式的时候，最好能够批判性的吸收其精华的部分，不能全部照搬，照搬了反而会出问题。

其实敏捷对产品经理的要求是很高的，需要安排至少两个迭代的任务，两个迭代的规划。

对程序员的要求也很高，当所有的任务都拆散了之后，最终做出来的东西要形成一个产品，技术人员的整体意识要比较强，且一开始就得熟知产品的整个规划，否则到最后就会出现所有任务都已完结，合并出来的最终产物却是什么都不是。并且敏捷开发不仅仅是IT部门的事情，还需要各个业务部门对敏捷的理解和支持，形成合力，从而提升开发效率和业务满意度。

运行一段时间的敏捷之后，发现最容易接受敏捷这种方式的是开发团队，不管是瀑布式还是敏捷，只是做工作的形式不一样了，进度更容易把握了，更能适应需求的变化了，实质其实并没有变化。

对测试团队来讲，测试资源调配会更加的紧张，敏捷要求做完一条测一条，与原先的整体项目排期完全不一样;对产品经理来说，敏捷能让自身更好的掌握整个产品的进度。

但需求分析与产品设计阶段的敏捷拆分还是较为头疼的，究竟要不要写文档了，是不是有什么做什么，还是说要规划完整体设计之后才进行拆分?疑问很多，搜集了部分资料，结合敏捷实践的经验，分享如下：

一、敏捷开发最少需要维护哪些文档?

软件或者系统产品终归是人来维护的，业务知识和技能的传递就成为产品可持续发展的一个重要因素，这就需要有知识性的沉淀，需要有文档的产出。

实际情况是大多数人都不喜欢编写文档、也不太喜欢研读文档，因此太多的文档只会消耗团队有限的时间，并不能带来多大的好处;敏捷开发照样重视文档的作用，也重视文档的维护。

但文档宜少且精炼，一般情况下建议维护三份文档：

1、《产品需求规格说明书》

也即PRD：定义产品应该具有的功能、边界描述等，它作为产品团队之间共同的讨论基础，并在设计和开发过程中不断的更新维护，并记录所有的需求变更;

2、《系统设计说明书》

开发人员编写的技术设计，包含数据库E-R图，架构设计等：说明产品如何实现，内部之间是什么关系;

3、《测试用例和测试报告》

由测试人员编写：记录所有功能点的测试计划、过程和测试结果;

二、敏捷开发是否需要系统设计?

前面也提到过，敏捷开发对开发人员来讲实质差异不大，只是以小周期代替大周期。

小周期包括：需求、设计、开发、测试、发布，这个过程中的设计环节是指要做产品设计和系统设计;由于做完整的设计需要有相对完整的资料和比较长的时间，与小周期是相对立的。

因此敏捷开发不主张高度细化和完整的设计，提倡做出一个大粒度的框架性设计，一般指架构设计或者系统设计，避免在以后的重构中发生架构级别的变化，然后在逐步实现的过程中逐渐深入展开、细化。

传统的一些设计方法比如结构化设计、快速原型法都是可以融入敏捷开发过程中加以使用的。

三、敏捷开发是否需要项目计划?

敏捷开发只是把整体拆分成许多个体，产品的开发实现过程对产品的功能完整性、稳定性、即时性等都有较高的要求。

它是一种有组织有目标的行为，往往我们都将其作为一个项目来管理，这就是讨论为什么有产品经理的同时还要有项目经理，为什么要求产品经理要有项目管理的能力，因此它需要项目计划。

但这个计划是一个短程计划，根据未实现的功能情况、前一个版本的反馈和组织目标制定开发计划;唯有这样才能不断的融入新的需求变更;

四、敏捷开发的迭代周期大概多长?

敏捷开发的迭代周期没有硬性的规定，结合项目里程碑、目标、功能实现情况、产品稳定性综合决定，如果产品用户活跃、功能实现难度小、维护复杂度低，建议以周为周期。

对于规模比较大、维护复杂度高的产品，考虑以2周-6周为周期发布较为合适;频繁的发布会降低用户的期望并提高用户成本，给用户心理上带来额外的负担：他会认为产品质量低，质量控制不严谨等;

五、敏捷开发为何提倡小版本?小版本有哪些优势?

小版本的目的就是分解复杂度、降低风险，改善团队士气等;小版本有众多优势：

1、总体风险比较少：小版本变化小，总是在上一个版本基础上局部调整和增加，技术复杂度低;由于规划的功能较少，工作量也易于估算，所以其总体风险比较少，常常能如期发布;

2、需求的接纳能力强：由于小版本快速实现并发布测试，然后就进入下一个版本的规划实现周期，这样新需求一旦提出就能快速进入开发视野，就能尽快实现;

3、测试和开发高效协作：开发和测试可以并行工作，当开发实现第一个版本时，测试设计测试方案和用例;发布第一个版本后，开发就进入下一个版本轮次，测试就应用测试方案测试刚才发布的版本，提交Bug;开发在下一个版本结束时修正所有上一轮发现的Bug，然后发布新版本，如此循环往复，开发和测试实现高效协作;

六、敏捷开发为何强调团队人员的参与、用户的参与?

敏捷强调团队成员的高度参与就是要统一认识，把团队的目标变成每个人的工作目标，使之为每个团队成员的认同，形成高度的凝聚力，以达到群策群力、高效协作的效果。

由于没有高度细化的文档，成员之间交换信息的唯一渠道就是面对面沟通，良好的团队氛围和协作关系促进这种沟通，并使消息有效传达。

用户由于缺乏专业训练，无法清晰、准确的表达其意图，导致需求的歧义和模糊;用户的参与使模糊、边界不确定的需求在互动的过程中得到确认和完善;在用户参与过程中，我们常常可以听到这样的话：

“是的，就是这样的”

“这正是我想要的……”

“这里需要修改一下……”

“我的想法是这样的……”

这个过程中，用户承担了一部分测试人员的角色。我们努力做的事情就是实现用户需要的东西，并最终让用户喜欢它，唯有用户喜欢它才能用好它，那么我们怎能不认真听取用户的意见呢?一句话总结就是：用户参与帮助我们做正确的事情!

七、怎么才能评估团队是否已经敏捷了?

由于敏捷开发没有标准的可供参考的实践过程，所以很难通过某个过程而断定其开发过程敏捷了，那么如何来评估团队是敏捷的呢?一般采用的办法是根据团队呈现出来的氛围、项目运作状态、团队成员的感性认识等方面来评估团队和其开发过程是否敏捷，常见评估项目团队是否已经敏捷的方法如下：

? 团队有共同的愿景，并且对这个愿景充满信心;

? 团队有明确的阶段目标并且为每个成员所知晓;

? 团队知晓当前计划：做什么、何时完成、预期效果等;

? 团队任务是低耦合的，并且紧密协作;

发布过程是轻松愉快的，构建版本并不断测试是常态行为之一。

八、敏捷开发能缩短项目时间并提高质量吗?

从我的实践经验来看是可以的，但目前无法提供量化的数据做参考，只能从几个方面评估和推断：

? 用户的参与帮助团队把功能一次性完成并做正确，缩减了返工的时间;

? 不断的重构和测试发布能把问题发现在早期，整体质量显著提高;

? 过程目标导向，使团队高度集中于项目目标，提高了生产力;

? 不断的发布对团队是种正向激励，荣誉感和成功欲使团队保持持续的激情;