问题

  问:传统的团队如何转化为敏捷团队(步骤,要点,注意事项等)?

  问:如果使用敏捷开发,在公司组织架构上有没有什么建议?

  分析

  在谈到何为敏捷团队之前,先看看传统团队的问题,不要把团队转化完了,问题还存在;换言之,解决问题是目标,转化团队是手段。

  1、各部门打架严重

  来自于分工中的灰色地带 / 各自目标和绩效的不一致。

  典型的是开发/测试团队,扩展而言,还包括市场/销售团队。

  后两者也很关键,很多时候开发和测试团队和谐了,联合起来和销售团队打架,公司的整体效率仍然上不去。

  不过,如果没有在市场/销售团队的工作经验,或管理他们的经验,谈论和过问与他们跨职能的难度很大。但这不等于这个问题不存在,可以请公司更上层的人去关注这个问题。本博客未来会提到市场/销售/开发团队的跨职能问题。

  2、各部门流程/文档繁杂

  为了解决打架问题,需要流程和文档来规范接口。

  常常被过度写作的需求文档和设计文档,是因为要跨过多个部门,才需要被“签字”“确认”“协调一致”,所以其写作的水平,往往超过“以能编写出软件为准”,而是达到“能交给下一个部门,让他们看完以后能编写出软件”为准。

  跨职能团队是敏捷开发提出的团队模型(自组织是跨职能的产物,下面会看到),通过消除部门分割,来解决上面的两大难题。

  直接方案

  直接方案是那些几乎不需要其他实践,能直接使用的方案,虽然他们也有一些先决条件。

  世界上没有无条件的事,也没有生下来有条件的人,所以很容易把喜欢找借口胜过方法的人卡住。如果下面这个事情仍然觉得很难办,那么多半还没有到谈论团队转型的阶段,请继续努力吧!

  3~5人规模的小组内实现跨职能(小组长可推行)

  这个是无需行政授权,小组长能做的事情。

  本人非常推崇通过1-3-9团队形成L型代码结构(文后有链接),局部的“部门”打架和文档问题迎刃而解。

  139团队中,整个小组的目标是一致的,而且成败都由师傅负责,因此他会成为跨人员的桥梁,把整个团队的事情当作自己的事情,解决个人的打架问题。

  L型代码结构可以有效降低文档量。当积木代码基本形成后,所有功能大致只有界面和业务逻辑的设计,经常一个功能只有50行代码左右,很多设计都可以因此省略。