《Agile Adoption Patterns: A Roadmap to Organizational Success》的作者 Amr Elssamadisy 在 Agile2008 上主持了一个话题讨论,重点研讨了在采纳敏捷中遇到的非技术障碍。他说:“随着岁数不断变大,我发现最难的问题是人,而不是技术。”
Amr 向观众提问,请他们回答在采纳敏捷的过程中怎么样算是失败。我们得到了下面这个列表:
- 不能交付业务价值——几乎每个人都同意
- 不开心的客户——很多人都同意
- 相比以前总体上没有改善(质量、生产力……)——部分人同意
- 停止使用敏捷——绝大部分人不支持
比过去交付更多的业务价值,这就是我们定义的成功。有些人认为,这其中暗含着要求,要为大家创建一个愿意工作在其中的环境。也许最重要的,是要在向敏捷转换的过程中,设定业务人员需要的目标。绝大多数人同意敏捷实践仅仅是达到目标的手段。
我们分享了几个关于采纳敏捷失败的故事:
- 有一个组织引入了咨询师。这些咨询师在没有核查目标的情况下,就建议客户采纳 TDD。像往常一样,TDD 用过一段时间之后,质量上升了,而开发速度却下降了。而在这个案例中,质量不是客户的最初目的,因此敏捷的采纳没有达成目标要求。
- 另一个组织引入了一个合同开发团队,并且这个组织有对工作的正式说明。团队使用敏捷的方式开发,而且交付的产品符合客户不断变化的需要。当项目完成后,产品负责人和用户都很满意,但是资深的管理层却并不满意。因为没有满足正式的工作说明——也就是对目标的正式说明——的需要。
Christopher Avery 的“责任流程模型”、Roger Martin 的“责任病毒”和 Chris Argyris 的“推论阶梯”,这些就是 Amr 展示的三种模型,可以帮我们理解这些案例中发生了什么。
“责任流程模型”
Amr 解释说,责任流程使用一系列的故事(来自 Christopher Avery 的“团队合作是一种个人技能”):
- 责怪:早上起来之后,你找不到钥匙。你会转向你的同屋,并询问“你为什么藏我的钥匙?”
- 辩护:你讲了一个又长又曲折的故事,并说这是老天之过。
- 羞愧:我是个白痴,下次我一定可以做得更好(通常没有任何正面作用,只会产生破坏)
- 义务:因为老板刚才的电话,我必须将下一周的时间花在路上。如果我们总是接这样的电话,非得累死不可。
- 责任:我们可以做出选择,我们可以说不而且从中获取力量。
图中横线以下的反应,都是个人内在的反应。一个人只有承担起责任,才能超越自己,成为他人的模范。我们可以承担软件项目的责任。不要接受“我不能做TDD”这样的话,而应将做还是不做视为一个选择。如果人们敢于担当,他们就能将实践掌控于手中。当人们出于义务而采取行动时,虽然此前已经答应要按步骤采纳时间,但他们却很难真正做到一步一个脚印地进行。
Rachael Davies 觉得自己所做的事情与 Virgina Satir 的工作有共通之处,而 Christian Gruber 推荐 Terence Real 的工作成果。
在 InfoQ 以前发布的文章《责任病毒让恐惧削弱了协作的效果》中,我们曾经讨论过Roger Martin 的“责任病毒”模型。参与者也将Kent Beck 的《做自己,创造更多价值》作为引用来源。
最后一个模型是“推论阶梯”,在彼得•圣吉的《第五项修炼》中有所提及。
评论