作为一名敏捷教练，我经常被问到的一个问题是：“我们实施了敏捷，但是为什么它没有起作用？”
问这个问题的人，是真正被困扰的人。
我遇到过许多团队，在对团队进行结构重组、职责重新划分、流程重新定义的过程中经历了许多的麻烦，但是令他们感到沮丧的是，经历这些之后他们的生产力和士气甚至都不如从前。
每个组织都有它自己独特的功能障碍类型。
作为一名教练，我要让自己深入团队，密切观察和理解他们是如何工作的。
但是，尽管每个团队都有自己的独特性，还是会经常出现相同的问题模式。
几乎在每个案例里，团队决定采用敏捷是因为他们遇到了现实生活中的问题，比如低的生产力和低的生产质量，他们希望敏捷能够奇迹般地让他们起死回生。
他们没有意识到的是，敏捷仅仅是管理软件的一种系统方法。敏捷可以支撑一些远大的目标，比如“通过满足客户不断变化的需求使客户满意”。看到这些目标后，管理者通常都会很兴奋，并且迫不及待地跳上敏捷这部列车。
敏捷的问题是在实施过程中它带来了很多麻烦：
每日站立会议，
规划会议，
和回顾会议。
咋看之下，一群人围着一个白板徘徊的景象，可能会让一些天真的管理者认为它起作用了；但是他们没有意识到在缺乏重要的管理和技术支持的环境下，敏捷将无法生存，甚至更糟，团队会背地里开始讨厌这种麻烦，希望事情能够回归到从前的模式。
管理问题
今年我一起工作过的一个团队就陷入了上面描述的那种麻烦里。
它是一个大型团队，被分成了7个scrum团队。你可以想象每天早晨办公室是多么的嘈杂，几乎同一时间召开的scrum会议，之后是scrum of scrum会议。
管理部门很高兴；毕竟他们已经为聘请敏捷教练实施敏捷支付好了价钱。
事情开始转变的很快。
我连续参加了团队的scrum会议数周，并且特别注意到其中有一个团队，他们已经被同一个技术问题持续阻塞了好几天。
团队不能继续向前开展工作，所以他们开始着手其它的事情，但是这导致了大量未完成的代码，不能测试和演示。
在敏捷里，scrum master理应为团队扫除障碍。然而当被问到时，这个团队的是scrum master也非常的沮丧。
他说，整个团队里只有一小部分人理解相关的技术细节，但是他们又不在他的scrum团队里。
他们被他的经理安排去开发实现另外一种功能了。
下面是软件团队遇到的一些典型问题:
问题一
每个敏捷倡导者都可以从积压的工作中捡起任何任务，但是在现实中，只有几个人理解一些晦涩的技术。很难激励其他人学习并熟知这些技术，尤其是那些跟不上时代发展的人。
即使你成功激励了他们，当面对大量积压的工作的时候，也很难抗拒处理其它事务，使积压起来的工作看上去很少的冲动。
问题二
敏捷scrum master理应移走团队面前的大山，让他们无阻碍地前行。
在现实中，scrum master经常缺乏这样做的权利。
这种权利通常存在于管理者手中，正如大家所知，权利很容易上瘾，并且很难放弃。
在实践中，如果管理者有抵触情绪，我也不会催促组织改变管理的角色。
如果某个管理者能够胜任敏捷scrum master，可以安排管理者承担scrum master的一些职责：
常常管理者在获取资源和处理矛盾方面更有经验，尤其是与其它同行者之间的矛盾。
但是这个团队遇到了更大的麻烦。团队经理另外开始开发实现一种单独和私有的功能——但是没有一个scurm团队被分配去实现那方面的功能，因此我就不能建立它的进度表。经过进一步的探索，我发现RnD团队和产品经理团队之间互相不信任；产品经理团队“命令”RnD团队去开发一种功能，但是RnD团队却保留了部分资源，开发实现另外一种他们认为更突出的功能。
我与RnD管理团队坐下聊了聊，在白板上画了一张因果关系图：
因果关系图是一种很强大的工具。
尽管管理者一直在抱怨敏捷对他们团队没有起作用，但是因果关系图清楚地显示了更深层次的根本原因。
因果关系图也有循环，这表明如果根本原因得不到解决，恶性循环将会继续。
技术问题
虽然这支团队拥有管理层的全力支持，但是仍然并不是所有的事情都运行的很顺畅。
特别是，持续集成总是失败。团队在办公室前面装配了一台大屏幕用来显示集成状态，这样当每个人进入或者离开的时候可以看到它。
这个屏幕平均每天有1-2小时时间是绿色的。当然，这在很大程度上推迟了团队的进度。
有一个规则，除非屏幕是绿色的，否则不能签入代码，但是因为它经常失败，所以有人偷偷潜入（sneaked in）代码。
我们喜欢认为软件开发跟传统的制造业有很大的不同，因为软件开发更“聪明”，而在传统制造环境下工作的工人只需要不费心思地拧上螺母（想到了摩登时代的查理·卓别林）。
在现实中，软件开发也有一个装配线，所不同的是，这种软件装配线引入了大量用来提高软件质量的迭代。
但是，就像工厂流水线一样，如果某一步速度变慢，事情就会堆积起来，整个流水线速度就会减慢。
对于这个团队，装配线在功能级别看起来是这样的:
这个装配线有很多的反馈回路。反馈回路越短越好，因为校正错误的成本更低。
从“演示”到“需求”和“开发代码&本地测试”步的反馈回路太长；理想的反馈回路应该从“开发代码&本地测试”步开始。
然而，因为总会遗漏bug，所以我们依赖自动化和QA测试提供反馈。
但是，在这个团队里，构建-部署-自动化测试过程存在严重的麻烦，并且有些人无视规则，随意签入代码甚至堵塞装配线，这一事实进一步加剧了过程的复杂性。
我向团队明确了装配线的概念，他们很快就想出了解决方案，理顺了装配线，比如加强代码审查和强制执行无签入规则。
然而，在自动化测试问题上，意见产生了分歧。
有些人认为目前的自动化测试是完全不可维护的：代码的合约商早已毫无踪影，并且修复测试代码的bug时间要超过修复通过测试代码发现的bug的时间。
其他人认为，即使自动化测试是坏的，但是有总比没有好，并且重新编写自动化测试代码对QA来讲成本太高。
我要求团队进行快速计算，以确定自动化测试的优势：
通过自动化测试发现bug/所有回归bug
自动化测试发现bug/所有回归bug
结果是有些自动化测试还是相当不错的，尤其是一些单元和组件测试，但是UI端到端的自动化测试结果却惨不忍睹。
结论很明确：没有必要为如此少的利益花费如此多的工作量。
同时我还指出，开发和维护自动化测试不仅仅是QA的职责。
UI端到端的测试代码完全依赖生产代码。在面向服务体系结构中，服务拥有定义明确，常常是多方协商后的API，如果一个服务想要变更它的API，他将要（应该）通知与其相关的服务，这样他们可以做出相应的变更。
UI测试代码完全受生产代码的支配：因此如果如此多的比如ID或者UI元素的名称在生产代码中发生变更，那么UI测试就有可能会失败。
为了实现自动化测试的健壮和灵活，自动化框架必须经过精心设计。
雇佣临时合约商是无法保证这一点的，而让QA工程师编写又需要依赖QA的专业技能和类型，可能也不好。
对于这个团队，很明显大部分QA工程师都是功能性测试人员，并不具备架构一个框架所需要的高级的架构技能。
因此我们决定让Dev tech负责人开发自动化框架，让Dev和QA一起开发和维护UI自动化测试。
该协议还包括Dev不能随意更改ID和UI元素名称的规则。
你可能认为所有的这些都发生在一个轻松愉快的会议上；
事实上，让这些成为现实得到了大量的管理支持，并且前后花费了近三个月才完成了自动化框架，实现了其快速、稳定、易于编写测试代码的功能——这就是我们解决现实生活中的问题的方法。
敏捷是一种管理软件的系统方法
我们需要回到原点，找出敏捷的精髓。在2001年，17名软件大师提出了敏捷宣言，但是敏捷宣言并没有规定怎么做：
个体和互动高于流程和工具
工作的软件高于详尽的文档
客户合作高于合同谈判
响应变化高于遵循计划
他们还提出了12条原则，其中的一些规定了做什么（比如业务人员和开发人员面对面的交谈传递信息）。
但是，大部分还是跟价值观念有关。如果我们仔细分析这12条原则，我们可以看到它实际上构成了一座金字塔。
在最顶端的是“通过满足客户不断变化的需求使客户满意。”
我们通过“经常地交付可工作的软件”实现这一目标。
但是为了交付可工作的软件，需要重要的技术和管理支持。确保变化的需求不会破坏系统和延缓开发进程是最重要的一个技术问题：如何设计一个灵活的系统和如何构建可以确保变化不会破坏系统的自动化测试。
为了在团队里培养高级专业技能，团队需要积极从错误中学习并进化自我。
向敏捷过渡并不是一场容易的旅程。
如果它不起作用，就仔细的看一看，想一想。它可能暴露了你团队中的一些根本性问题。
你可以转向白板，找出是什么减缓了你团队前进的脚步，使用精益工具比如因果关系图和五个为什么发现根本原因，解决它们，之后你将会收获敏捷的全部好处。
作者：ChenPing，ChenPing在中国的上海生活，2005年获得计算机科学硕士学位。从那时起，一直就职于Lucent和MorganStanley。目前她在HP担任开发经理。
5815
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
