作为一名敏捷教练，我经常被问到的一个问题是：“我们实施了敏捷，但是为什么它没有起作用？” 问这个问题的人，是真正被困扰的人。我遇到过许多团队，在对团队进行结构重组、职责重新划分、流程重新定义的过程中经历了许多的麻烦，但是令他们感到沮丧的是，经历这些之后他们的生产力和士气甚至都不如从前。 每个组织都有它自己独特的功能障碍类型。作为一名教练，我要让自己深入团队，密切观察和理解他们是如何工作的。但是，尽管每个团队都有自己的独特性，还是会经常出现相同的问题模式。几乎在每个案例里，团队决定采用敏捷是因为他们遇到了现实生活中的问题，比如低的生产力和低的生产质量，他们希望敏捷能够奇迹般地让他们起死回生。他们没有意识到的是，敏捷仅仅是管理软件的一种系统方法。 敏捷可以支撑一些远大的目标，比如“通过满足客户不断变化的需求使客户满意”。看到这些目标后，管理者通常都会很兴奋，并且迫不及待地跳上敏捷这部列车。敏捷的问题是在实施过程中它带来了很多麻烦：每日站立会议，规划会议，和回顾会议。咋看之下，一群人围着一个白板徘徊的景象，可能会让一些天真的管理者认为它起作用了；但是他们没有意识到在缺乏重要的管理和技术支持的环境下，敏捷将无法生存，甚至更糟，团队会背地里开始讨厌这种麻烦，希望事情能够回归到从前的模式。 今年我一起工作过的一个团队就陷入了上面描述的那种麻烦里。它是一个大型团队，被分成了7个scrum团队。你可以想象每天早晨办公室是多么的嘈杂，几乎同一时间召开的scrum会议，之后是scrum of scrum会议。管理部门很高兴；毕竟他们已经为聘请敏捷教练实施敏捷支付好了价钱。 事情开始转变的很快。我连续参加了团队的scrum会议数周，并且特别注意到其中有一个团队，他们已经被同一个技术问题持续阻塞了好几天。团队不能继续向前开展工作，所以他们开始着手其它的事情，但是这导致了大量未完成的代码，不能测试和演示。 在敏捷里，scrum master理应为团队扫除障碍。然而当被问到时，这个团队的是scrum master也非常的沮丧。他说，整个团队里只有一小部分人理解相关的技术细节，但是他们又不在他的scrum团队里。他们被他的经理安排去开发实现另外一种功能了。 下面是软件团队遇到的一些典型问题:
但是这个团队遇到了更大的麻烦。团队经理另外开始开发实现一种单独和私有的功能但是没有一个scurm团队被分配去实现那方面的功能，因此我就不能建立它的进度表。经过进一步的探索，我发现RnD团队和产品经理团队之间互相不信任；产品经理团队“命令”RnD团队去开发一种功能，但是RnD团队却保留了部分资源，开发实现另外一种他们认为更突出的功能。 我与RnD管理团队坐下聊了聊，在白板上画了一张因果关系图： 因果关系图是一种很强大的工具。尽管管理者一直在抱怨敏捷对他们团队没有起作用，但是因果关系图清楚地显示了更深层次的根本原因。因果关系图也有循环，这表明如果根本原因得不到解决，恶性循环将会继续。 虽然这支团队拥有管理层的全力支持，但是仍然并不是所有的事情都运行的很顺畅。特别是，持续集成总是失败。团队在办公室前面装配了一台大屏幕用来显示集成状态，这样当每个人进入或者离开的时候可以看到它。这个屏幕平均每天有1-2小时时间是绿色的。当然，这在很大程度上推迟了团队的进度。有一个规则，除非屏幕是绿色的，否则不能签入代码，但是因为它经常失败，所以有人偷偷潜入（sneaked in）代码。 我们喜欢认为软件开发跟传统的制造业有很大的不同，因为软件开发更“聪明”，而在传统制造环境下工作的工人只需要不费心思地拧上螺母（想到了摩登时代的查理卓别林）。在现实中，软件开发也有一个装配线，所不同的是，这种软件装配线引入了大量用来提高软件质量的迭代。但是，就像工厂流水线一样，如果某一步速度变慢，事情就会堆积起来，整个流水线速度就会减慢。 对于这个团队，装配线在功能级别看起来是这样的: |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
