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