敏捷开发时间迭代实施流程

从4月中旬开始，我们部门进行了破天荒有史以来第一次敏捷项目实践，两周的时间虽然 不长，但是整个团队感觉无论从技术上，还是沟通与合
作上，都有很大收获。当然，还有很多我们事先没有想到的纰漏和问题，经过与团队每个成员的面谈，我为后续的迭代整理出了下列的优化流程。
说明：
◇在下面的流程中着重迭代开始的规划和迭代中，开发团队与测试团队的协作过程，对PO的review会议和回顾会议没有做详细阐述
◇本流程仅针对我们目前特有的项目，有些特征不具有一般性。
◇其中使用到的一些缩略用语
        PM: 项目经理/项目负责人/项目协调人
        US/us: user story
        PB: product backlog
        PO: Product Owner
1.      PM根据上个迭代的结果，对已有的PB做修正，添加需要修正的BUG，未完成的us等，并提交给PO作为参考
2.      PO根据PB和自己的业务需求，并根据优先级 顺序，提出本次迭代希望完成的us和PB； 并对这些us和PB的细节部分进行整理
3.      PO将整理后的us和PB提交给PM
4.      PM提前一天将po提交的文档作为planning meeting会议提纲的一部分，分发给项目团队
5.      项目团队成员仔细研究PO的需求，并记录自己针对业务需求和逻辑的想法或疑问
6.      PRODUCT PLANNING会议
  a)    参与者：PO，PM，开发团队、测试团队
  b)    过程
    i.  项目团队对PO提出的需求进行讨论， 并由会议记录人记录每个us的细节
    ii. 涉及到某个业务细节，讨论的时间不超过5分钟， 并且最终拍板权在PO手中
  c)    会后
    i.  由会议记录人负责，将本次迭代涉及到的us 其描述和相关细节，直接建立在部门内部的 wiki中
        记录形式：所有的us按照迭代的周期不同 放在不同的page中，每个us以 panel相包裹
7.      ITERATION PLANNING会议
  a)    参与者：PO（可选），PM，开发团队、测试团队
  b)    过程
    i.  根据us和记录的PB，对本次迭代的任务进行 拆分和估算
    ii. 要考虑各个任务之间的前后逻辑关系， 以确定优先顺序
         注意：估算时，应该把DEBUG的时间也要考虑在内
    iii.        如果估算的时间超过了本次迭代的可用时间，那么PM找PO进行协调，请求放弃不能完成的US和PB
   c)   会后
    i.  会议记录人负责将会议中最后确定的任务分配情况提交给PM
       ii.      PM在jira中建立任务并分配到人
        使用us作为jira中的COMPONENT
        同时使用us作为一个task的名称，将与该us相关的任务作为subtask作为us task的子问题
8.      DBA 可以开始考虑在数据库中进行建表等操作了
9.      ITERATION DESIGN会议
  a)    参与者：PM，开发团队、测试团队
  b)    过程
    i.  根据本次迭代要完成的任务，开发团队与测试团队确定每个us和PB 要验收测试所涉及到的代码接口
    ii. 开发团队使用类图、顺序图等uml工具，对 代码中的一些接口和调用方法进行名称的定义
    iii.        可以使用照相手机等工具，把白板上绘制的简要图表拍摄下来，并上传至部门的wiki中
10.     PM准备一个项目变更日志，用来记录迭代中，某时间点发生的变化，包括下列内容
  a)    数据库字段的变化
  b)    us的细节的补充
  c)    ......
         注意：对该日志的访问必须方便和直观
下面进入开发阶段
11.     开发团队
  a)    采用tdd的方式，完成各自的任务
  b)    每当一个任务中的细小任务完成，并确认在 本地编译无错误，而且单元测试都可以通过后， 才允许上传到ci服务器
  c)    上传完成后，开发人员要注意即时监控ci服务器的反应， 如果有问题，马上进行解决
  d)    当开发人员确认自己的任务完成后，对应的sub task可以解决， 并且记录工作实际完成时间
  e)    每个任务的完成，都有可能触发一次CODE REVIEW的过程
    i.  如果发现问题，或者需要对代码进行重构， 在完成后，负责人要修正任务的实际工作完成时间
  f)    团队针对一项任务的CODE REVIEW结束，并且负责人修改完成后，该负责人可以针对自己剩余商未开始的任务，调整估算的时间，
12.     测试团队
  a)    负责维护测试库
  b)    并且要根据与开发团队定义好接口， 撰写针对每个us的自动化测试脚本， 准备自动化测试的TEST SUITE
13.     PM
  a)    当一个us相关的任务都完成后，PM修改jira中的us task的状态，变更为"等待集成测试"，并通知相关的开发人员和测试组 马上对
该us进行集成测试，并在测试完成 后，马上进入修正阶段
14.     在这个过程中，如果任何人发现US有任何不完整的地方， 都应马上与PM和PO进行协调和沟通，如果需要马上补漏的， 发现者应该对wiki中
的相关us进行补充。如果不需要在本次 迭代中进行考虑，那么PM应该记录到项目变更日志中
15.     开发人员仍然要坚持每日立会，每日立会后，PM更新BURNDOWN CHART
16.     项目中用到的一些特殊的技术，可以考虑在某日立会之后， 用半个小时左右的时间，该技术的掌握者向整个团队分享该知识
进入迭代收尾阶段
17.     所有的us都已经完成（测试团队完成验收测试，开发团队修正完毕并且无误）
18.     PO REVIEW 会议
19.     团队回顾会议

上面的任务分析过程中，每个分拆出来的任务，我认为都应该有对应的us，理由如下：
◇ 如果没有，那么这个任务对于PO的业务价值在哪里体现呢？
◇在任务分析时，发现了某些隐藏的而又是必须完成的任务，那就说明，还有隐藏的us没有发现。这就需要找PO进行沟通，看这些隐藏的任务是否对其有价
值，如果有的话，那么就分析隐藏的us，并根据当前迭代的任务完成和分配情况，进行本迭代应完成的任务和us的调整
◇没有对应的us，没有与PO讨论，PO可能在将来经过缜密的思考后，提出的要求，目前的解决方案可能不能够满足，就增大了返工的几率
◇没有对应的us，测试组没有参与，那么一些验收测试的细节就很难得到充分的发掘；
◇除此之外，还有可能造成系统切分的粒度过粗，从而增加了这些没有us的功能代码和与其相关的功能代码之间的耦合度，由此可能带来的一系列后果：
   ◆针对这些无us的代码，没有自动化验收测试的脚本；测试组需要等到与这些代码相关的us的功能代码提交后再进行测试，从进度上讲,会延迟测试组
和开发人员的协同合作的时间，并延迟一些问题的暴露时机（我们都知道：问题暴露的时机越早，解决起来成本越低）。
   ◆针对这些无us的代码，大家的关注度和思维的缜密性可能不如有us的代码，那么在这对这些代码做tdd和debug的时候，投入相对较小，出现
纰漏的几率就变大了。当我们在开发或调试与其相关的代码的时候，对于发生的问题的定位，这些代码就会造成一定的困扰

bryanzk 2007-05-18 13:19 发表评论