时间过得飞快,转眼间C项目已经来到了第五个迭代。在第五个迭代,C项目的情况如何呢?答案是还在磕磕绊绊。
对很多人来说,这种敏捷实施的成果是难于接受的,实施这么久了,还在磕磕绊绊。实施敏捷看起来就像一场运动,人们总期待实施敏捷有个结束的时间,但是这就是敏捷,实际的敏捷。(敏捷不仅是马拉松,它还永不结束。)
记得以前听Scrum的讲座,敏捷的三大支柱之一就是透明性。意思就是,敏捷本身不解决问题,它能在实施过程中让问题不断的暴露出来。敏捷社区有个形象的提法,“水落石出”。
解决问题依赖于组织自身。然而对大多数组织来讲,都没有做好不断面对问题并解决问题的准备,实施敏捷磕磕绊绊甚至失败也就是意料中事了。
当前状况
在第五个迭代进行到一半的时候,项目组又开始报告坏消息了。因为API无法及时提供,估计难以达成本次迭代的开发目标。
取得的进步
客观上讲,在五个迭代中,项目组取得了不小的进步。
1. 团队基本形成
由于以前过细的分工和瀑布式的流程,团队组建之初基本上是人人各自为战。不愿主动暴露信息,等任务、等协调等等待比较突出。
而现在,整个团队都团结在一个准确的目标之下,我们需要交付迭代目标。在这个共同目标之下,内部协调变得轻松,人员也比较积极主动。
2. 工作流程开始顺畅,建立了基础的集成环境
在迭代交付的压力下,团队也很快形成并习惯了工作流程。
团队分为开发团队、需求团队。所有的工作都列在白板上,由团队成员领取。开发团队负责按Feature/Bug进行开发测试发布,形成了一个快速的开发流程。需求团队负责外部需求协调与需求细化,形成开发团队下一迭代需开发的Feature列表。
3. 技术基本掌握
经过几次迭代后,团队通过结对编程、单元测试等实践,已经基本掌握了工作所需的技术。
4. 持续交付成果
虽然磕磕绊绊,团队每个迭代都在持续交付符合质量标准的工作成果。遗憾的是,没有一个迭代是符合迭代目标的交付。
当前存在的困难
在之前团队已经解决了大多数影响工作的问题。那么在当前有什么困难将团队难住,导致磕磕绊绊呢?说起来也很简单,就是API问题。
本团队依赖的API来自于美国的架构师,该架构师是多个团队的共享资源。但是该架构师与本团队的工作优先级次序不相同,并且不存在工作承诺。这导致团队经常出现等待状况,而这种等待状况只是偶尔得到上级的重视,予以解决。