Gepiu的博客

有点想法很好,有点行动更好

树欲动...


使用禅道进行任务驱动的Scrum开发

最近团队的工作模式逐渐稳定,稍微总结下目前的任务驱动模式
不论什么样的工作,最根本的还是人,所有的任务都需要人的参与
所以,无论什么模式、概念、行动,都不能脱离人这个重要的因素
以下5项是我们团队的核心内容

  • 角色
  • 项目
  • 迭代
  • 测试
  • 文档

角色

人是核心,所有的工作都需要人来参与完成。没有任何工作能脱离人而单独存在,无论是进行中还是向后相关,必然会有人的参与(真正意义上的自动化、人工智能现阶段是不存在的)

能力关系是人的两点重要属性!

个人的能力对于团队来说是至关重要的,一个小组内能力高的人多就会带动整个team越来越牛;而一组能力很弱的人注定不会高效。团队和人一样都是有相性的,圈子和围城是确实存在的事实;一个能力很弱的人(相同或相似年纪),也注定无法融入到一个很强的团队中。

人与人的关系也是影响团队能力的因素,比如两个能力都很好的人,但是关系很差,甚至到了互相使绊子的程度,那么效率可想而知。现在国内比较成功的小团队,如coding,都是以几个非常出色的领域大牛为核心组件的小团队,互相配合、相互提携运作的。
技术能力高且愿意分享的人,是团队中最受欢迎的;当前能力一般,但非常喜欢学习研究的人,是团队的中坚力量,也是团队的未来;而个人魅力十足,很有亲和力、人际关系非常好的人,在团队中的作用往往比技术大牛更重要

项目

说道目的自然就会想起目标,我们要实现什么?要实现到什么程度?什么时候实现?
需求是项目的基础,需求描述了场景功能、边界样式周期等项目的关键资源

需求的管理是项目管理的重中之重,需求的前期准备直接关系到开发的进度、项目的成败;另外,对于需求变更的管理是否正确也是项目成功最为关键的因素。

需求管理的目的是在客户和处理客户需求的软件项目组之间建立对客户需求的共同理解

需求管理的目标有两个:
1、使软件需求受控,并建立供软件工程和管理使用的需求基线
2、使软件计划、产品和活动与软件需求保持一致

在需求管理过程,为实现第一个目标,必须控制需求基线的变动,按照变更控制的标准和规范的过程进行需求变更控制盒版本控制;为实现第二个目标,必须就变更和软件项目各小组达成共识,对软件项目计划作出调整,其中包括人员的安排、用户的沟通、成本的调整、进度的调整等

迭代

迭代是Scrum模式的一个术语,是指把一个复杂且开发周期很长的开发任务,分解为很多小周期可完成的任务,这样的一个周期就是一次迭代的过程;同时每一次迭代都可以生产或开发出一个可以交付的版本

任务则是迭代的核心,没一个迭代中,我们有很多个任务需要完成,只有完成了这些任务,当前迭代才会关闭;迭代是有周期性的,每一个迭代要完成的任务都是从与当前迭代关联的需求分解出来的。 与其说迭代需要完成多少个任务,不如说迭代需要实现哪几个需求

每个迭代在开始后,关联的需求就不会再改变,但任务的数量却不是固定的,在迭代进行的过程中,持续从需求中分离出新的任务也是常见的

测试

测试分为两个部分:用例Bug管理

测试用例针对的是需求,每个需求都要有对应的大量测试用例来进行全覆盖的测试(测试用例的编写是一个相当枯燥乏味的工作),当一个迭代完成,相关联需求的测试用例就会被测试人员拿来测试

测试中一定会发现各种各样的Bug(没有Bug的程序不是存在的...),发现的bug一定要进行管理;开发人员需要确认bug是否能重现,并解决掉bug;测试人员在开发人员确认并修改完bug之后要重新按照测试用例进行测试

Bug管理在Scrum模式下异常的重要!

文档

很多人说敏捷开发就是不需要文档,大家边说边做。 也许3、2个人,1、2个周的工作你可以这么做(但是后期的维护一定是个坑)
我要强调的是,文档很重要,真的非常重要!敏捷开发提倡的绝对不是什么文档都不需要。很对文档不论是在开发过程还是在维护阶段,都是必须的。当然,传统瀑布模式下的文档我是不喜欢的,过于详细

在Scrum模式下,文档中应该描述的是流程、结构、思路等信息,像文字大小、颜色、位置这种详细的东西体现在原型文档中,用视觉图形来代替详细的文字描述

UML图,99%的开发人员都知道它,但是却很少人有用它
用例图、时序图、类图、对象图、构件图、部署图
这是我经常使用的几类UML图,其实画UML图并不需要非要使用什么工具,word、excel、ppt都可以的
UML图比单纯的文字描述更容易让人理解

小结

现在我们使用禅道来进行Scrum模式开发管理

需求调研阶段
项目开始后,所有的需求都会登录到禅道的需求管理中;刚登录的需求一般都比较简单,可能就是用户的一句话或这个关键词,在与用户的不断深入交流中,需求会逐渐丰满(需求的一生都会有存留);最终会给各种需求确定重要度、优先度;并按照预想的阶段指定粗略的实现计划

开发实现阶段
当需求完全确定,就会进入开发过程,会按照预想的安排将需求分散到很多的迭代中(迭代的周期在1-2周为最佳,即使不产生新的版本可以作为一个阶段Tag存在);然后启动第一个迭代,将此迭代相关的需求拆解为一个个任务(这个过程应该team全员一同进行,让所有人了解需要完成的目标,并设定合理的预计工时)
在任务驱动模式下,不是通常的派发任务,而是领取任务;每个人每天需要领走不小于当天工作时间的任务;而最终完成的所有任务的预计工时合计也将成为奖励的参照(多干多得!);燃尽图是每天全员需要check的,它直观的展示了当前迭代的进度是否存在问题

测试修改阶段
当一个迭代的任务完成之后,当前迭代的测试就开始进行;发现的bug会在Bug管理中登录,并等待开发人员的确认(正常的测试方式是在指定的测试环境进行测试,整个测试过程中不能重新发布新的版本,直到本次测试全部结束);开发人员确认bug之后会在开发环境进行修改,当测试人员完整的测试一遍之后,开发人员会把所有的bug修复然后重新在测试环境发布新的版本;之后测试人员再重新进行测试,直到没有Bug出现