让你的故事墙动起来
在敏捷项目中,我们经常提到一个工作流,这个工作流就是故事墙,通过对故事墙的维护,我们可以看到每个迭代当前的状况。
一个成熟的敏捷项目,故事墙具有完全适合于项目的工作流,项目成员会自主的维护故事墙,而敏捷教练基本可以不用过多的关注此类事情。
我也见过很多毫无生机的故事墙,他们放在那个角落里,犹如被人遗弃的街角,墙上还画着过去的涂鸦。下面为大家分享一下我们的工作流故事墙是如何一步一步动起来的。
开始敏捷工作流
当时项目遇到种种困难与问题,我们不得不进行变革,按照当时的情景,借助敏捷工具tapd,我们决定使用敏捷开发,并且得到大家的一致认可。
这时的工作流及其简单,实例如下:
- 新
- 规划中
- 规划完成
- 开发中
- 开发完成
- 测试中
- 测试完成
- 已发布
- 已拒绝
该项目是公司内部的一个后端项目,项目前期主要是进行增量迭代,当时也没有太多规范性东西,所以一开始的工作流比较简单。我们对故事墙也只是简单使用而已。
形成自管理
随着项目时间推移,一个普通的后端项目开始纳入更多的功能,公司全面使用,各种新需求与优化蜂拥而至。后端项目开始升级为业务中台。于是我们经过优化,形成了下面工作流:
- 新
- 规划中
- 原型设计中
- 原型设计完成,待评审
- 原型评审完成,待设计或待开发
- UI设计中
- UI设计完成,待评审
- UI评审完成,待开发
- 开发中
- 开发完成,待测试
- 测试中
- 测试完成,待验收
- 验收完成,待发布
- 已发布
- 已拒绝
产品不停输出,迭代池留存大量功能,同时迭代的版本数量增多,有段时间我们4个迭代版本同时进行。
大家都能切身感受到迭代的增加,故事墙变的丰富起来,如果不及时维护迭代墙就会变得混乱不堪,在敏捷教练的指导下,大家开始自主维护好故事墙。
我们只需要看一下故事墙就知道现在项目的迭代情况,特别是在多个迭代同时进行的时候,可以说每天的故事墙都很生动形象。
慢慢的我们将故事墙设置为首页,进入敏捷工具的第一时间就是查看故事墙,如果遇到有同事忘记维护的,大家都会相互提醒,项目成员已经可以进行自管理。
克隆故事墙
经过敏捷开发的摸索和实践,这套工作流虽然简单,但是展示为故事墙却非常直观好用。
后来新的项目,我们对该敏捷开发模式和工具配置进行复制,并且优化后,做了一套简单的通用规范。
可是每个项目总有自己的特点特色,于是根据每个项目的不同,进行私有化改动,比如我们增加了研发数据库设计评审,测试用例评审等流程。我们不进行限制,只要符合当前项目的,都可以调整。
敏捷教练的作用
不得不说,我们的一个普通团队,要实施敏捷还是比较困难的,所以大多数提议都由敏捷教练提出,由项目成员共同参与讨论,敏捷教练进行指导,最后制定出让大家都赞同的方案。然后经过不断的复盘进行调整优化。
所以如果在项目团队比较弱的情况下,还是需要有人进行指导和督促。
小结
故事墙只是敏捷中的一个板块,有时候看起来可有可无,可是当认真使用起来的时候,真的非常棒,每个人都参与其中,享受敏捷思想在项目中的成果。