敏捷中的不良观点

受众：

所有软件开发专业人员都会在本文中找到感兴趣的地方。而经理、CIO 和软件架构师将会对本文篇文章最感兴趣。这一话题可能会引起许多争议，但我写这篇文章是想深入剖析敏捷运动中日益严重的问题。

“你在这干嘛？敏捷不需要经理。”

之前曾听到过这样的话么？想象一下，听到开发人员认为你的职位根本不应该存在，是多么的让人震惊…好像你作为经理的贡献仅仅是创造了这一职位。在项目经理初次遇到即将一起工作的开发团队时常遇到这种情形。可以肯定的是，敏捷宣言原文中完全没有提到项目管理，并且后来的敏捷理论者们更进一步，建议把项目经理调整为教练或是支持的角色。

然而，这一观点忽略了现实。

可以确信，对于小型无集成依赖的开发项目，只要拥有一个能胜任的、有经验且能干的团队，或许只需对项目进行很少的监管就行了。然而，项目越大，项目中的集成依赖越多，且开发在项目中所占比重越小…需要项目经理协调、沟通和指导的总体投入就越多。在一个开发只占全部预算 10% 的项目中，可以考虑让 scrum master 来带领开发，同时向项目经理汇报。

此外，开发团队几乎从未注意到或是擅长于管理预算。在软件开发上所花的时间越多，花在其他事情上的时间就越少。这让一些开发人员产生了一种缪见，他们会开始认为他们所做的一切才是项目，而其他人在做的则无关紧要。

这里所说的不良观点是指不认可其他角色和专业的价值，并顽固地坚持于哲学性的解释而丝毫不考虑现实中所需的灵活性。如果这种观点进一步发展，把这种观点扩展至各种领域内的所有管理层，那这种观点几乎就像是工会主义或是新共产主义了。显然，把公司文化和组织结构采取大幅度的全面裁剪至扁平化水平是过激的。他的观点是片面的，但如果他处于某个合适的位置（一名领导者），他的观点就会得到支持，并使开发团队和管理层的关系恶化；把完成项目的目标变成管理层与工作者之间的阶级斗争。

“是团队在运作项目，而不是经理…我们会决定要做什么。”

这一观点通常是从认为不再需要管理角色的观念中产生。这种观点无视事实的真相；许多决策需要公司中许多部门的合作才能做出；而不能只由开发团队来做出…包括软件的设计和架构。

在其他情况下，如果开发人员忽视了项目的其他方面，也会产生这样的观念。更糟糕的情况是，开发人员曾在不良的项目经历中备受煎熬，并因此认为在一些可察觉的问题发生前就应该“采取行动”。

不管怎样，敏捷成了这种观点的借口和基础，认为多数（如果不是全部的话）开发团队之上的管理结构毫无贡献，并应该立刻去除对他们的投入。以我的经验看来，让这种观点占主导的话，通常的结果是无止境的重新架构会议、严重的预算超支、永无截止之日，并导致团队对自身任务大失所望、士气低迷。

“敏捷里没有截止日期或是进度表。”

我们中对资本预算和公司财务有深入了解的人都知道这有多傻。然而，如果你读过 Ken Schwaber 关于 Scrum 的书，其中确实谈到抛弃甘特图而选用燃尽图。的确，燃尽图是个简洁而深思熟虑的创新，但有人会就此认为这意味着没有交付时间表…即，钱永远也花不完。

我有这么方面的惨痛经历。我观察过一支团队，领导这支团队的技术负责人很强，并颇具魅力，我与该团队都向这位负责人汇报。为了给客户开发一个“可工作的产品”，他会放弃任何基于时间的目标。没有任何时间限制，团队处于完全失控的状态。职业道德下降或者根本就不存在了。希望产品获得成功的人失去了所有动机和动力。客户变得迷惑，尽管产品特性和变更请求陷入了混乱，为什么还要如此重视各种技术架构。燃尽图让他们更加迷惑。他们想要知道的是，产品什么时候能够完成？团队只能回答： “我们没有时间表。我们将继续开发，直到完成为止。”

当任何人尝试设置可行的目标时，他们会立刻被扣上“反敏捷”的帽子。当团队被告知他们的项目严重超支时，他们的眼神黯然而迷惑。他们做的东西、时间还有经费之间的联系迷失在画在白板上的抽象设计模式之中。

现实是…总会有个截止日期和交付时间表，无论是显性的还是隐性的。没人会把钱投入到一个永远不会完成的开发项目上。更现实的是，我发现在非敏捷团队和敏捷团队之间协调深度集成或非开发方面的工作时，甘特图仍然很有用处。

产生敏捷没有时间表的观点，主要是由于敏捷方法提出的见解：项目应该不断加入新的特性，直到钱花完为止。这有点理想化，并忽视了一个事实：当开发团队无法在预算内完成最起码的功能时，开发出来的应用程序是毫无用处的。这种观点最不好的地方是，有些人会选择新的技术来跟踪团队进展及责任，并把它作为逃避交付责任的理由。

“敏捷的代码本身就是文档。没必要有需求文档、架构图或是技术规范。”

如果你是名软件架构师或是技术经理，通常要面对这种观点。这种几乎不加掩饰的攻击意在质疑你的角色、经验和存在协调者的必要性——协调某个创造公司收入的 78%、有 2800 万行代码的软件项目的所有技术设计。

当然这种观点通常是由于无知导致的。或许开发人员最近写的一个 2000 行代码的 web 应用程序，除源码外很少需要其他工件，但规模大了就会需要了。你知道这点，你的管理层也知道，但这种不好的敏捷观念认为，如果公司跟上诸如 Scrum 之类的开发方法，你这种角色根本就不需要存在。多数软件系统需要由少数几人监督方向、协调技术愿景，同时需要很多人去实现它。

以我自身的经验来看，讽刺的是，这种观点来自来想成为架构师的开发人员。他用批评，与技术负责人争辩，提出他对敏捷技术的认识来让人感觉到他的存在，认为这样他人才会更尊敬他，会给他渴望的职位。相反地，大家觉得他很讨厌，是个麻烦制造者。此外，由于在提出敏捷概念时不够机智，使得高级技术负责人员对任何敏捷事物都没有好感。

“敏捷迅速地拥抱变化；拥抱所有变化。”

我从一名经理那里了解到这种观点，而不是从一名开发人员那里。原来他把“快速拥抱变化”理解成了各种变化…不只是最初敏捷创立者们所指的业务需求变化。这样，基础架构的变化成了常事，在不同的开源技术中转变也被视为“好事”，即使这些变化意味着让团队彻底远离他们的技能并推迟项目交付好几个月。组织上的实验和人员角色的快速变化也变成了“快速拥抱变化”的一部分。最终结果就是一团糟。

明确地接受客户提出的变更很重要，但没有系统去管理这些变更的话，你就是自找麻烦。应该有人去跟踪所有的需求和变更以及它们对项目交付的影响，以便拿它们与客户进行沟通。这对做出有效的项目决策是很有必要的。如果你不这么做，那客户会有不切实际的想法，他们的任何要求都将被纳入项目…我们知道这会导致什么后果。

因此这个不良观点是：接受变化，但没有对变化进行管理。绝对的自由只会导致希望破灭和无法满足的期望。变化是好的，但猛烈的变化会造成混乱。

“敏捷使用通才；我们自己测试软件。不需要 QA 部门。”

同样，这一看法在哲学上的解释是正确的，但我的相关经验，特别是在大型软件开发项目上的经验是…需要有另一双眼睛盯着，看开发人员开发出了什么，它们是否能良好地工作。为自己的技术水平感到骄傲，这很好，应该鼓励。但有时骄傲会变成盲目的接受和抵触。这需要有一名强有力且非常可靠的人来识别出他们的局限，并找出缓解的办法。使用通才的关键，是要确保你的团队由一群精干的多面手组成。反思这种想法，它把软件开发更多地看作是工艺而非流水线生产。然而，作为软件开发负责人，我们不能假定人力资源十分完善而忽略事实。最好正视风险，做好应对规划，历史证明开发人员无法找出他们自己的所有错误。

以我自己的经验来说，抱有这种观点的人不喜欢任何人测试他们的代码，对任何建设性的批评都大为光火。特别是在某个案例中，我们发现了根本的原因，那名开发人员确实不擅长编码。我们为他提供了培训和指导，在数月的努力之后，我们发现很显然他不适合这一职业。

因此，使用通才挺好，但为了追求哲学上的纯净而忽略这几十年来的事实真相，这种观点就是过时的。

总结

总之，这些问题在前敏捷（pre-agile）世界中也会出现。但根据我的经验，这些不良观点会在新的开发方法中寻找庇护和辩解理由，但独立地看，这新方法或许从未有过这种意图。这些观点可能会控制敏捷方法并把健康的敏捷运动弄糟，作为软件开发领导，在此之前设法纠正这些观点很重要。敏捷包含了一个重要的要点：简化、产品开发期间客户的参与、承担责任、保持联系。丢失了这一要点会让人极其失望。那么你的想法是什么呢？你有这些观点么？你如何对付它们？我很想听听你的意见。

关于作者

Christopher R. Goldsbury 是名软件开发专业人员，在整个职业生涯中他担任过开发人员、架构师、scrum master、开发经理、项目经理和质量保证经理。Chris 把他的经历和想法写在他的博客上。

查看英文原文： Bad Attitudes of Agile

感谢石永超对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家加入到 InfoQ 中文站用户讨论组中与我们的编辑和其他读者朋友交流。