敏捷的坏态度
虽然所有软件开发的专业人士都会对这篇文章感兴趣，但是经理、CIO以及软件架构师会对它最感兴趣。这个话题可能会引起许多争议，但我写这篇文章是为了让你了解在敏捷运动中看起来正在日益增长的问题。
你为什么在这？敏捷不需要经理。
以前听过这种说法吗？ 想象一下，如果你听到开发人员认为你这个职位根本就不应该存在，你会感到多么震惊，就好像是你特意为自己搞出经理这么个职位似的。这个话最常应用在项目经理第一次与将要和他一起工作的开发团队碰面的时候。的确，最初的敏捷宣言绝对没有提到项目管理，并且后来的敏捷理论家更进一步，建议调整项目经理的角色变成更多是教练或者支持的角色。
然而，这个观点忽略了现实情况。
的确，小的、非集成的、从属开发项目中可能不需要任何类型的管理，只要你拥有有资质、有经验并且能干的团队就好。然而，越是大规模的项目，越是高度集成的从属项目，越是开发集中度低的项目越是需要一位项目经理去协调、沟通和把握这个整体目标。一个开发部分只占总预算百分之十的项目，可以允许由一位scrum专家来领导开发，但也要向项目经理汇报。
再者，开发团队几乎根本不知道或者根本不擅于管理预算。软件开发需要的时间量让开发团队没有时间顾及其它事情。这使得一些开发人员产生了小盲点，似乎他们开始认为：他们所做的一切就是这个项目，其他任何人都是多余的。
这里的坏态度是指认识不到其他角色和职业的价值，并且严格遵守哲学解释，而意识不到现实需要灵活变通。如果走向极端，在它的陈述中通过把这种观点延伸到所有条件下的一切管理的话，这种态度就几乎能被理解为就是工会主义或者新共产主义。显然，接受这样包含一切的、大规模的企业文化削减以及组织结构扁平化的个人是极端分子。虽然他是对周围环境发出的观点，但是如果他恰恰是这样一个人（一位领导）他的观点能够起作用并且会使开发团队和管理部门之间的关系变得更糟那么就会使项目完成的目标变成管理部门与工人之间的阶级斗争。
是团队运作这个项目，而非经理......我们将决定该完成什么。
这种观点通常是不再需要管理角色这种观念的产物。这种观点是违反事实的：许多决定需要公司中的众多元素一起合作，而不仅仅是开发团队......这也包括软件设计和架构。
在另外的例子中，有这种观念的开发人员恰恰没有意识到项目有其它方面。甚至更糟糕的是，在某些可察觉的故障发生之前，被一次不愉快经历伤得很重的开发者会觉得需要控制这个项目。
无论如何，敏捷变成了这样一种态度的前文和基础，这种态度提出开发团队之上的大多数（即使不是全部的）管理结构都没有用，应该立即剔除掉。依据我的经验，如果让这种态度生根的话，那么通常会导致无休止的重组架构会议、应付预算超支、没有真正结束日期以及因自己使命的幻想破灭而精神分裂的团队。
在敏捷中不存在到期日或者时间表。
我们这些深入了解资本预算和公司财务的人会知道这是多么愚蠢。然而，如果你读过Ken Schwaber写的关于Scrum的书，就会看到那里面谈到为了燃尽图而抛弃甘特图。事实上，燃尽图是一个干净利落的、经过深思熟虑的创新，但有些人却认为这就意味着交付没有时间表......即钱永远花不完。
这对我来说是一次痛苦的经历。 我见过一位能力很强且富有领袖魅力的领导人（我们都向他汇报）带领的团队，为了给客户产出项目管理工作产品，而放弃了基本的时间目标。 任何时间界限都没有了，这个团队到处倾斜。 职业精神极大衰减，或者可以说是荡然无存了。 那些想让产品获得成功的人丧失了动力和干劲。 客户变得不知所措，为什么如此多的重点强加到各种技术架构之上，而特性和产品变更需求却不知所踪？ 燃尽图让他们更迷惑。 他们只想知道的是：这个产品什么时候才能完成？ 而这个团队却只回复说：我们没有时间表。 我们会一直开发，直到我们做完为止。
当有人尝试着设定现实目标时，他们会因反对敏捷而立即被打倒。 当这个团队被告知他们的项目无可救药地超过预算时，他们的双眼充满了困惑和不解。 他们正在做的事情、时间以及最终的花费之间的联系已经消失在那些他们用白板记录的抽象设计样式中了。
现实是......不论是明确的或者模糊的，总是有一个到期日和交付时间表。如果这个开发项目的观念是它永远都不会完成，那么就没有人会把钱投给它。更现实的是，我发现甘特图在协调深度集成或者非敏捷团队与敏捷团队之间非开发方面还是非常有用的。
这种没有时间表态度的产生，主要是因为敏捷技术提出了这样的观念：项目应该继续添加新特性直至把钱花光。这是不切实际的，并且忽略了当开发团队连预算内最低限度的功能都没有完成时会发生什么，此时描述这样的要求毫无益处。这种态度不好的方面是用（敏捷）这种新技术来追踪团队进程、问责并且把这种新技术扭曲成不对交付负有责任的原因。
敏捷编码是自动文档化的。它不需要需求、架构图或者技术规范。
如果你是一位软件架构师或者技术经理，这种态度通常会让你眉头紧锁。这种轻微的、隐藏的攻击是想质疑你的角色、经验以及有人来协调那带来百分之七十八公司收益的两千八百万行软件程序的技术设计的必要性。
当然，提出这种想法的通常是出于无知。可能开发人员构建的两千行web应用近期需要非常少的源码外的再加工，但那是因为规模的关系。你知道，你的管理部门也知道，但是这种不好的敏捷态度取代了你的角色，却不是为了像Scrum那样领先于开发技术。大多数的软件系统需要少数人来监督方向、协调技术愿景，而需要成百上千人来创造。
依据我自己的经验，说来颇具讽刺意味，这种态度来自于那些想成为架构人员的开发者。 通过评论、与技术领导争辩以及介绍他的敏捷技术知识，他感觉领导应该更加尊重他，应该给他那个他梦寐以求的职位。 然而，领导却把他当作令人讨厌的麻烦制造者。 此外，因为他缺少介绍敏捷概念的经验，从而让那些资深的技术领导一想起任何敏捷的事情就会不舒服。
敏捷快速地拥抱变化；所有变化。
我对这一态度的经历来自于一位经理而非一位开发者。原来他把快速拥抱变化解读成了各种各样的变化......而不仅仅是原来敏捷缔造者设想的业务需求。所以，基础的、架构的变更成为了家常便饭，不同开源技术间的不断改换被视作好事，即便这意味着把这个团队带离他们（熟悉）的技术，以及月复一月地推迟项目交付。组织结构方面的实验以及把人们快速放入某个角色并又被快速地从这个角色中拿出也变成了快速拥抱变化。最终的结果就是混乱。
显然，接受来自于客户的变更很重要，但是如果对那些变更没有系统的管理，那么你就是自找麻烦。你需要保存所有需求、变更的轨迹，以及他们对项目交付的影响，以便把这些信息传递给客户。这对于做出有效的项目决策是必须的。如果你不那样做，客户会不切实际地认为，他们要求的东西都会包含到产品中我们都知道这会导致什么样的情况。
所以，这里的坏态度是不加管理的接受变更。对所有事情都绝对自由只能导致虚幻的希望和无法达到的期望。变更是好的，但极端的变更只能是混乱。
敏捷使用的是通才；我们测我们自己的软件。这里不需要测试组。
又是这样，这种观点在哲学解释上是准确的，但我在这个问题上的经验是，特别是大型的软件开发项目，你需要第二双眼睛来盯着开发人员干了什么，干得怎么样。手艺人的自尊很重要，并且应该培养，但有时自尊会变成盲目的接受和防御。这第二双眼睛会让坚强的、很诚实的人认识到他们自己的局限并找出方法来减轻这些问题。
使用通才着重于确认你在一个由具备多种技能的个人组成的敏捷团体中。如果更深入地思考，你会发现这认可了软件开发更多的是手艺而非流水线作业。然而，作为软件开发的领导者，我们不能假设人力资源是完美的，并且忽略事实。我们最好能够看到风险并为此作好计划，历史也证明开发者不会找到他们自己所有的错误。
以我个人的经验，有这种观念的人不喜欢任何人测试他的代码，对建设性的批评也很敏感。 在特殊的情况下我们发现，这里潜在的原因是开发者真的不擅于编码。 我们给了他培训和指导，但经过几个月的努力后，却发现很显然他是入错了行。
所以，使用通才是好的，但如果因为喜欢哲学上的纯粹，而忽略了几十年来的实际情况的话，这种态度就会变得毫无新意。
总结
总之，这些问题在前敏捷世界中也能找到。但是根据我的经验，这些坏态度在这种新的技术中找到了避难所和辩护。而孤立地看，这种新技术可能从来没有打算在这样一个临时的演讲台上演讲。作为软件开发领导，我们在人们掌握敏捷的方法论之前演说这些观点是危险的，并且可能把一场好好的运动给搞糟。敏捷有一个重要的信息，那就是简单化，在产品开发的过程中让客户参与，取得所有权，并且保持联系。如果丢失了这个信息，那将是非常令人失望的事情。因此，你们怎么想的？这些态度在你们那存在吗？你们怎么评论这些态度?希望你们能告诉我。
关于作者
Christopher R. Goldsbury是一位软件开发专家，在他的职业生涯中，担任过的角色有：开发者、架构师、scrum专家、开发经理、项目经理以及质量保证经理。Chris把他的经历和想法都写在了他的博客上。
