敏捷开发之四:主要流程

敏捷开发的目的是为了快速交付,通过精细化的项目管理来保证质量和开发的平衡。一个利用敏捷开发方式进行的项目多半是具有持续性的。 我们经过很多项目的实践的敏捷开发项目的大致流程如下,对于团队搭建、场地准备等先不多说了,这些最好另有专人在立项后决定用敏捷的时候就都准备好,防止后面的忙乱:

  1. 需求讨论。发起人是提出需求的BD、产品经理、研发团队的项目经理和主要的参与人员,包括UED、测试、QA和敏捷顾问(Scrum Master)。在时间资源允许的情况下,尽量早参加产品需求的各类讨论总有益处。需求讨论需要明确这次产品大约做什么功能,大致划分几个阶段。难点是需求和开发在时间上要取得共识。开发时间在敏捷中可以理解为固定的2-3周(一个Sprint),那么这2-3周的产出到底是多少,需要协商讨论。很多时候需求讨论都需要2-3次会议才能完成。需求讨论会议的重要性在于定好一个大的基调,甚至包括是否用敏捷开发方式。开会虽然也耗费资源,但是比起到了开发阶段推倒重来还是划算的太多了。需求讨论之后,产品需求文档、原型图等都要准备好了。
  2. Scrum周期。敏捷开发和瀑布开发在时间控制上不是循序渐进,而是平行开展的。在一个Scrum周期中,得到了确认了的产品需求文档和原型图等资料,就开始进行User Story分拆、UED页面设计、技术方案设计、测试用例编写等工作。因为基于Feature的最小颗粒度,所以分拆和执行的同步不会有太多问题。项目经理现在开始要成为主导,还有敏捷顾问。项目经理负责整个Scrum周期中每个Sprint的细化,敏捷顾问要从方法论上给予指导以及根据实际情况的微调。
  3. Sprint周期。Scrum中有若干个Sprint,在一个Sprint周期中,包括User Story拆分、UED设计、技术开发、单元测试、代码评审、功能测试、测试案例测试、生产测试、用户手册编写、质量评审、上线评审等环节,不一定都要,视情况而定,当然最基本的开发、测试、生产验收、QA、上线是不可能少的。
  4. 每天周期。每天的流程里面,站会(Stand up)是不可缺少的。对于认领任务在目前大部分的项目中都不太具有操作性,因为任务还是研发、测试等经理来派分的,效率还高一些。如果有晚上加班的,建议下午5点左右再开一次站会,避免问题累计。站会的细节之后另外详细叙述。项目经理白天要做大量的审核检查,对于分析、开发中、测试、完成等四个阶段的Issue查看细节,和上游需求提出方保持沟通,为第二天、当前Sprint、下一个Sprint等做各类前期工作。
  5. Issue的生命周期。一个Issue基本上会在四个阶段流转,每个Issue在不同的阶段属于不同的拥有人。测试岗位会产生新的Issue,通常我们称为Defect和Bug,这些Issues中如果是Defect,则会讨论一下是否在当前Sprint修改,Bug的话一般都是要在当前Sprint中解决。这就是为什么看一个Sprint的完成曲线,会在项目中后期进度发生回退的原因之一,因为新开出来不少Defect和Bug的缘故。需求方、产品经理、测试都会在项目过程中给到一些建议,敏捷开发是灵活的,因此对于这些建议是否被采纳,需要根据实际情况讨论,至少可以作为之后Sprint的基础,我们有时候称之为需求池。我是建议需求池中的Issue也先建立到系统中,这样产品经理可以直观的从数量和内容上有控制,敏捷开发中要旨之一就是可以不断迭代,而迭代的源泉这样逐渐出现会比集中完成要更接近实际。技术开发的重构不在上面说的行列,因为技术开发重构优化是为了适应未来需求的变化或者提高处理效率等,不是几个Issue可以解决的。
  6. Sprint和Scrum小结会。在这两个阶段结束,特别是Sprint上线或者发布之后,要开一个全体参加的小结会,时间不用长,半小时就可以了。要超过半小时的话,说明平时沟通有很大问题了。这个小结会是为了反映一些系统性的问题。对于Scrum来说,效率很重要,凡是影响效率的都是问题。在不同的Sprint周期,项目重点会不一样,之后还会说,Sprint完成也不一定是上线看得到,同时Sprint的beta测试等之间还是有一定关系的,一些系统性的问题不解决的,至少会被带到下一个阶段,甚至会被放大。所以小结会上要列出问题并且解决,除了BD、产品经理、项目经理、敏捷顾问等以外,有更高级别的主管参加是有益处的。

 

Leave a Reply