本节书摘来华章计算机《软件工艺师：专业、务实、自豪》一书中的第2章 ，第2.6.1节，［英］桑德罗·曼卡索（Sandro Mancuso）著 爱飞翔 译, 更多章节内容可以访问云栖社区“华章计算机”公众号查看。
2.6.1 转型不彻底
这些年我见过许多向敏捷转型的项目，而且也参与了其中一些。很多公司都高调宣称自己要采用敏捷开发，但却没有做出实质努力，他们并没有变得更加敏捷。他们把敏捷开发想象成一套预先定好的步骤：只要跟着做，结果自然会好。今天，很多公司和团队都说敏捷开发不管用了，因为他们经历了向敏捷转型的过程，但转型过后却发现情况并未改观。可他们恰恰忘记了一点：软件项目的首要目标是交付软件产品本身。
我见过的所有转型过程几乎都存在转型不够彻底的问题。软件公司通常会请咨询机构与敏捷教练帮助公司改变开发流程。然而，这些咨询机构与敏捷教练从来不会，或很少告诉员工应该如何写出质量更高的软件。总体来看，敏捷转型关注的是流程，而不是技术原则，这也就意味着，转型对提升开发者水平所起的作用非常小。敏捷教练实际上并未改善运营人员、产品服务人员及QA人员的技能。大部分公司在向敏捷转型时，基本上都完全忘记或忽视技术原则。某些水平不高的敏捷教练会有一种不够专业的看法，他们认为：公司里的开发者已经可以写出好的代码了，只需要令他们融入Scrum框架即可。由于公司已经有了优秀的软件交付能力，所以开发者需要做的只是改善流程、提升沟通能力、扩大参与范围而已。这样一来，敏捷教练就会觉得只要改进了流程，其他所有事情都会好起来。在他们眼中，那些开发者无需改变原有的习惯，就能依照新流程制作出优秀的软件。编写代码只是个简单的细节问题，不是吗？你只需要改善流程就够了，对吧？不，完全不是这样。
敏捷转型主要致力于改善流程、扩大员工参与范围、简化繁琐的规章制度、防止浪费、排定任务优先级、使工作进度更加直观，以及改进信息流。这些当然都是迫切需要解决的严重问题，公司在重视并改进这些问题之后会大有改观。不解决这些问题，软件项目就很难成功。然而，公司却忽视了敏捷开发背后的原则。他们把流程看得比磨炼技术还重要，而涉及流程的每种敏捷开发方式，恰恰都需要卓越技术的支撑。公司管理者和准备不够充分的敏捷教练经常会忽视这一点。
敏捷社团与精益社团中的许多人都喜欢谈论丰田公司的成功经验，诸如他们改变了流程、减少了浪费（或者说降低了库存）、限制了正在制作中的产品（Work In Progress，WIP）数量等等。敏捷教练与咨询机构也喜欢向不知情的客户兜售这种“丰田之梦”。我首先要说的是，造汽车和做软件完全不同。你不可能驾驶一辆尚未完工的汽车。你也不会在买了车之后跑回制造商那里，要求加装车门或把引擎从前面移到后面。
谈论丰田公司的辉煌事迹时，这些人很少会问：“这些车如果做得不好会如何？会不会根本没人来买？要是车身脆弱，每月都要送修怎么办？”丰田之所以成功，除了生产流程很好之外，还有个重要因素，那就是车的质量很高。
顾客之所以买丰田车，是因为其做工精良、质量可靠。他们觉得花钱买这种车很值得。他们信赖高质量的丰田车。
开发流程要奏效有个前提，那就是必须以提升产品质量为目标。为此，需要一套能涵盖各个层面的良好反馈系统。而这套反馈系统若要奏效，又需要有技术高超且态度积极的专业人员，这些人必须很重视自己的工作，当他们觉得某件事出了错或者还可以改进时，会勇于提出自己的看法。假如只关注流程，而把软件开发看作一条生产线的话，那么开发者就成了按部就班、朝九晚五的流水线工人了。这种做法使得反馈系统效率低下，进而损害整个项目。
敏捷教练
每个行业里都会有高手和庸人，敏捷教练也不例外。有的人完全能领会敏捷开发本意，他们在指导公司或团队进行敏捷开发时，一般会同时强调良好的流程和卓越的技术。尽管大部分时间都在关注流程，但他们会和自己的同事协作，或推荐其他同事去帮助客户理解敏捷开发背后的技术原则。反之，比较平庸的敏捷教练缺乏技术专长，所以只会强调流程（这会误导客户），而且通常根本不提技术。
向公司高管推销流程要比谈技术问题容易得多，公司高管很难明白技术的重要性，也很难理解为什么需要督促员工努力提高技术水平。高层管理者很容易就能理解流程的重要性，但却不明白开发者在写代码之外参与其他事务究竟会给公司带来什么好处。他们也不懂得代码质量的重要性。只要开发者写出的代码能运行，就够了。
非技术人员出身的高层管理者很容易被蹩脚的敏捷教练误导。采用了几个月或几年敏捷开发之后发现效果不佳，敏捷教练和管理者经常会指责开发者。有时候开发者的确做得不够好，但敏捷教练和管理者也应该反思这样一个问题：如何通过敏捷转型来帮助他们做好。
抗拒技术实践
但还有一种情况，那就是优秀的敏捷教练与咨询公司在尽力帮助客户，而到了该采用极限编程的时候却出现了问题。许多客户立刻反对两个开发者结对编程这种做法，他们认为这完全是浪费资金。他们也坚决反对提前编写测试用例并采用测试驱动开发（Test Driven Development，TDD）。他们会说：“要是用了TDD，那我们的QA团队怎么办？开发者根本不该浪费时间去做测试。我们付钱给亚洲那家公司，就是为了叫它帮着我们做测试的。”
有时这种抗拒情绪来自开发者。他们不理解结对编程的好处。有些人觉得这会暴露自己在某些领域的知识缺陷。他们不愿意这样做。他们也看不到编写测试用例的好处，因为他们觉得优秀的开发者不会犯错，只有平庸的开发者才需要写测试。
如果不编写自动化的测试，那么持续集成的意义何在？只为了确保代码能编译吗？此外，那些客户也不接受简洁设计与集体享有权（collective ownership）等理念。管理者眼中的资深开发者，就是那种懂得好多种模式，并且能设计出复杂架构的人，除了这位开发者之外，别的开发者都不明白系统的工作原理。
在这种情况下，如果抗拒来自公司高管，那就应该展示强有力的证据，告诉他们关注软件质量的重要性。抗拒若是来自开发者，则应该经常派一些有经验的极限编程者与之结对，通过范例来引导他们进行极限编程。如果还不行的话，那就考虑用一些新人来替换某些开发者，把热衷于学习新技术和新做法的那部分开发者留下。
软件项目管理的误区
这些年来，我见过很多不恰当的软件项目开发方式。有些公司认为，软件项目的成功，就在于请一位业务专家撰写需求，叫一位技术主管绘图并编写文档（这位主管不参与编程），然后再叫一位经理过来督导项目（也就是对项目进行微观管理）。等这些角色都就位之后，廉价雇用几个开发者就行了，通常他们会把雇用工作委托给职业中介或人力资源（Human Resources，HR）。他们太急于求成了——把几个月前就准备好的一大堆技术文档和需求文档堆在开发者面前，然后盼着软件赶紧完工。一年之后，开发者就会把软件交给业务人员，大家看到软件后都非常满意，并把这款没有bug的软件部署到生产环境中去。一切似乎都这么完美，这么轻易。遗憾的是，这种方法根本不可行。
根据我参与瀑布式开发项目的经验来看，这些项目不接触实际用户、不与业务人员协作，也不建立迅速的反馈回路，于是，其测试阶段会变得比前面所有阶段加起来都长。如此漫长的测试阶段，使我紧张、苦恼，而又失望，但还有更糟糕的情形。我至少见过两三个公司把整个项目都外包给远方的开发者（offshore outsourcing，离岸外包），在这种情况下，管理者还能指望什么呢？把一堆文档扔给从未见过的开发者，在既不知道其招聘过程，也不了解其技能水平的情况下，怎么能指望做出来的软件会完全符合需求呢？有了那几年不愉快的经历，我开始怀疑：这种工作模型对于公司来说，是否真的很实惠。
另外一个常见的问题是，软件项目的主管通常对软件本身非常陌生。许多主管要么不是技术人员出身，要么很多年都没有写过一行代码。在没有技术人员参与的情况下所做的决策，很可能会引发严重后果。软件项目要想成功，就必须有优秀的软件开发者参与协作，这些开发者不只善于打磨软件，还能帮助业务人员达成他们的业务目标，给他们提供建议、反馈以及建设性的批评。
包括敏捷开发在内的每一种软件开发流程都需要卓越的技术。若没有高超的技术，任何软件项目都将经历痛苦而沮丧的开发过程，并使公司付出昂贵的代价。
