剖析短迭代
敏捷教练Dave Nicolette提出：我们应该如何设定迭代长度？是要根据发布周期的时间么？使用短迭代又有哪些好处？
新闻
采纳敏捷时，过于滥情会造成障碍
作者 Mark Levison译者 郑柯 发布于 2008年8月10日 上午8时57分
《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的《做自己，创造更多价值》作为引用来源。
最后一个模型是“推论阶梯”，在彼得•圣吉的《第五项修炼》中有所提及。
查看英文原文：Touchy Feely Impediments to Agile Adoption
.gif)
没有回复
回复