如何打造敏捷组织？向组织引入敏捷流程如何打造敏捷组织？向组织引入敏捷流程，团队敏捷转型的不同阶段团队敏捷转型的不同阶段
在本文中，我想讨论向组织引入敏捷流程。自Kent Beck的《极限编程解释》发布以来，敏捷流程管理就在软件工程届变得越来越受欢迎。敏捷流程允许在整个开发周期中变更需求，并强调软件开发人员与客户之间的协作以及早期产品交付。 “敏捷宣言”为这些流程建立了一个共同的框架：个体和互动高于流程和工具；工作的软件高于 详尽的文档，客户合作高于合同谈判；响应变化高于遵循计划。最常被认为是实践了敏捷的流程包括极限编程（XP），精益开发，Crystal，和Scrum。 在Scrum中，项目在一系列为期以月为周期的迭代中进行，称为sprint。开发团队在每个sprint之前与客户或产品所有者会面，以确定要完成的工作的优先级，并选择团队在即将到来的sprint中完成的任务。 在冲刺期间，团队通过举行简短的每日会议保持正常。在每个sprint结束时，团队提供可能的可交付产品增量。Scrum非常适合具有快速变化或高度紧急需求的项目，例如互联网项目或新市场的产品开发。 在过去的四年中，我们向七个组织介绍了Scrum。一些项目很复杂，他们涉及分布式团队。其他团队则很直接，包括小型、共处一地的团队。然而，即使是一个简单项目，也需要跨多个部门或职能部门才能实现。没有吧敏捷过程应用于任何一个领域都会对项目的结果产生负面影响。 通过反复试验，我们发现了几种成功向组织引入敏捷流程的方法。 开发者 大多数开发人员都会采用怀疑主义、热情、谨慎乐观的复杂态度来回应敏捷流程的建议。然而，其他开发人员要么在没有经过深思熟虑的情况下抵制敏捷变革，要么过分热衷于进入敏捷变革。这两种反应都可能导致问题。 阻力 一般而言，敏捷流程比被计划所驱动的流程更重视代码编写。在计划驱动的流程中，开发人员可能会将统一建模语言设计和其他非代码项视为优先级最高的工件。但是，在敏捷过程中，这些行为通常仅用于支持代码编写。 在向各个项目团队介绍Scrum时，我们发现喜欢制作「非代码成品」的程序员远远多余愿意承认的程序员。我们还遇到了一些程序员，他们根据参加的会议数来衡量他们对项目的贡献。这些程序员超越了“分析能力丧失”，并积极寻求将自己的正式任务添加到敏捷流程的机会。 例如，一位程序员创建了一个正式的文档类型，并试图强迫他的同事为数百个案例生成文档，当时可能有十几个案例。在这种情况下，最好不要干预。其他团队成员可以快速评估这些活动的价值，如果他们无法帮助整体开发工作，则不会采用这些活动。 微观 很多开发者将使用敏捷流程视作一种微观管理的尝试。由于像Scrum和XP这样的方法可以加快项目周期，由于scrum和xp等方法加快了项目周期，开发人员通常更频繁地与他们的管理人员进行交互，但时间较短。在一个「计划驱动」的流程中，经理可能一周内并不会和特定的开发人员交谈，但在大多数「敏捷流程」中，日常联系是正常的。 将「敏捷流程」视为“微观管理”的开发人员倾向于将与项目经理的互动视为关于截止日期和错过截止时间的讨论。为了避免这个问题，项目经理应该不断地展示他们的愿望，以尽快消除障碍，而不是在一个任务需要太长时间的时候去抱怨。为了避免这个问题，项目经理应该不断表达他们的预期希望，以便尽快消除障碍，而不是抱怨任务需要太长时间。当被告知任务花费的时间比原先想象的要长时，管理人员可能会惊讶，但不应该对此动辄品头论足。 从重量级的「计划驱动」流程过渡 我们遇到的一些开发人员更喜欢重量级的「计划驱动」流程，因为他们认为这会使得他们的简历上看起来更好看。因为这些人对这个过程的价值没有深刻的信念，他们最终会被同事的意见和行为所左右。 从重量级到敏捷过程的逐步过渡可以使开发团队更容易地进行更改。有些团队，当第一次被引入Scrum时，由于没有一天一天的甘特图指导他们的工作，变得无所作为。 我们通过定义一组sprint类型帮助团队轻松进入Scrum： 原型制作， 需求捕获， 分析和设计， 实施，以及 稳定。 然后，我们与团队一起定义将由每个冲刺类型产生的工件。使用sprint类型引入了足够的形式，团队可以更清楚地看到他们在项目中的位置。随着团队对敏捷过程的非正式性越来越熟练，他们逐渐放弃了Sprint固化的概念。 分布式开发 使用敏捷流程的团队倾向于比计划驱动的团队更快地做出决策，依靠更频繁（通常是非正式）的沟通来支持这一步伐。 我们曾经有一个失败的尝试 ，在一个团队人员相距2000公里的项目中使用敏捷过程。这个失败经验告诉我们，组织应该在启动敏捷过程后的前两个或三个月内抵制分布式开发。公司发起了这个项目，需要合并式解决他们的政治和文化问题，然后开发者才能在多个城市共享一个项目。 如果必须组合分布式团队，那么在项目的第一周或两周内尽可能多地召集人员可以增加成功的可能性。我们已经成功地在多个分布式项目中使用了这种方法。 对顶级人才的需求 Barry Boehm的顶尖人才原则：“使用更好、更少的人”，是敏捷过程的核心。敏捷流程从项目中剥离不必要的活动，使开发人员有更多的时间进行开发。 虽然团队中最佳和最差程序员之间的生产率差异可能超过10：1比率，但当程序员处理软件交付必不可少的任务时，生产率差异最为重要。当程序员从事非必要活动时，生产力差异无关紧要。 当开发团队完全参与并熟悉敏捷过程时，它的移动速度非常快。太多的工作慢的人要么放慢整个团队的速度，要么最终被比他们工作快的人落在后面。 过分热心的团队 我们一起工作的一个团队对移入XP过于热情。在项目开始时，团队成员通过编写用户故事，规划迭代和配对编程任务，积极地开始记录需求。 敏捷过程并不意味着在没有预先考虑的情况下做出决策。 他们甚至搬出现有的空间，进入一个更适合XP的废弃建筑。他们这么快就完成了所有这些工作，以至于组织的其他成员都不知道他们在做什么，从而导致了一些问题。 虽然敏捷流程一旦到位就可以提高生产力，但在团队学习新技术的过程中，生产力可能会降低。由于没有预料到生产力的下降，该团队选择在发生这种情况时加倍努力。 敏捷过程并不意味着没有事先考虑就做决定，这是一个过分热心的团队在追求速度和敏捷时忽略的区别。对于这个团队来说，贝克的建议“在需要的时候投入你需要的东西”意味着他们只需要提前一个小时考虑。他们没有xp所要求的规则，而且，在口头上说xp的时候，他们实际上只做了黑客攻击。 过度的热情也导致团队分裂成两个阵营：过度热情的团队成员和一个知道决策速度太快且常常错误的团队。就像乌龟和野兔一样，这两个子团队对项目的追求也不尽相同。在项目失败之后，花了一段时间说服两个团队共同追求敏捷过程，尽管这个过程比那些狂热的成员最初想要的要“不那么敏捷”。 测试人员 编写源代码是任何开发过程中的主要活动，但在敏捷过程中尤为重要：“代码是开发绝对不能缺少的一个工件。” 敏捷过程没有单独的编码和测试阶段；相反，在迭代期间编写的代码必须在迭代期间进行测试和调试。与其他过程相比，测试人员和程序员在敏捷过程中的工作更为紧密。因此，测试人员和其他非编程人员必须小心地集成到他们参与的任何敏捷项目中。 最初，测试人员甚至比程序员更倾向于将敏捷过程视为微观管理。在采用敏捷过程之前，许多测试人员（尤其是那些没有独立和专用测试组的组织中的测试人员）没有受到管理者的太多关注。测试活动通常被降级为项目计划中的单个行项目。 我们遇到了一些测试人员，他们秘密地想成为程序员，并使用项目的早期迭代来潜入一些编程。我们还与测试人员合作，他们要么是自愿的，要么是被迫为程序员编写单元测试的。 尤其是在项目的早期迭代中，您应该阻止测试人员进行这种不适当的活动。首先，如果测试人员对编程有足够的了解，并且您需要另一个程序员，请雇用测试人员。第二，为其他人编写单元测试可能会导致一个有用的测试，但它几乎肯定会失去自写单元测试固有的一些白盒优势。 上级管理部门 对于希望向敏捷流程移动的组织，高层管理人员往往增加了挑战。高层管理人员的担忧通常分为四类： 我们如何向客户承诺新功能？ 我们如何跟踪进度？ 敏捷过程将如何影响其他群体？ 项目什么时候结束？ 许多管理人员，特别是那些较高级别的管理人员，不愿意放弃甘特图和其他计划驱动的流程工件给他们的控制感。同样，开发组承诺在指定日期提供确切数量的功能，即使他们知道该组将无法这样做，他们也会感到安慰。 客户承诺 担心敏捷流程意味着他们无法做出产品承诺的经理必须明白，任何过去的项目计划都暗示对交付日期，成本和功能的保证是错误的，严重填充的，或两者兼而有之。 在具有错误项目估计历史的组织中，可能并不难说服高层管理人员敏捷过程值得尝试。但是，如果软件组具有准时交付记录，则必须说服上层管理人员使用敏捷流程可能导致项目更快或更少资源完成。10-12 绘制典型的成本，日期和特征三角形通常可以说服高层管理人员这种承诺是一种幻想。一旦上级管理层意识到过去的承诺主要是好运和填充估算的组合，他们就会对任何承诺提高效率的流程产生浓厚的兴趣。 对于管理者，他们担心敏捷过程将意味着他们不能做出产品承诺的，他们必须理解，任何过去暗示了对交付日期、成本和功能的保证的项目，要么是错误的，要么是被大量填充，要么两者兼而有之。 在有错误项目评估历史的组织中，说服高层管理者敏捷过程值得尝试可能并不难。但是，如果一个软件团队有按时交付的记录，那么您必须说服高层管理人员，使用敏捷过程可能会导致项目更快或更少地完成。 绘制一个典型的成本、日期和特征三角形通常可以说服高层管理层，这样的承诺是一种错觉。一旦上层管理层意识到过去的承诺主要是运气和补充估计的组合，他们就会对任何保证更高效率的过程非常感兴趣。 跟踪进度 「计划驱动」的流程吸引了许多高层管理人员，因为它们有助于进度跟踪。管理员可以通过简单询问是否已生成必要的文档来跟踪导致大量文档的过程。 如果要求软件测试计划，则当管理器验证其存在时，可以进行第一级跟踪。当经理称重文档时，可以进行第二级跟踪，如果管理者读取，则可以进行第三级跟踪。 为了说服高级管理人员敏捷流程允许充分的项目跟踪，我们通常完全基于组织正在考虑的敏捷流程项目的虚构数据创建两个或更多模型状态报告。报告描述了一个虚构的两到四周的项目周期。 Scrum流程项目的典型状态报告包括关键日期列表，项目状态的2到5段评论，比较计划工作进度的燃烧图表，关键指标（流程缺陷，测试通过百分比，以及等等）适合项目的当前状态，以及关键风险列表。我们与之合作的上层管理决策者发现这种状态报告令人满意。 对其他群体的影响 一些高层管理人员表示担心，虽然敏捷流程可能会使开发小组受益，但它可能会对其他群体产生不利影响。当另一个团队的流程对开发团队的工作产生负面影响时，这种担忧会变得不健康。 例如，一个软件工程组想要使用Scrum，而提供所有规范和要求的产品管理组希望继续使用重量级瀑布方法。首席执行官认为让每个集团都采取独立战略都没有问题。结果是2000页的详细产品规格被纳入了一个开发过程，需要在长达一个月的单位中优先考虑工作。 软件工程小组必须从产品管理小组的三到四个月任务列表中猜测优先级。然而，一旦软件工程组习惯于Scrum，他们就会比其他组编写新需求更快地完成需求。 在向组织引入敏捷流程时，高层管理人员必须理解并同意这将如何影响开发组之外的组。如果他们不这样做，如果他们不能就如何解决意见分歧达成一致，那么大多数努力都可能会失败。 项目完成 最后，高层管理者通常担心项目会永远持续下去。大多数管理者都习惯于一个模型，在这个模型中，项目预算得到批准，并且项目仍在预算范围内。当他们被告知只要客户或客户代理继续识别高优先级、高价值的工作，项目迭代将持续存在时，他们就不太舒服。 模型状态报告有助于说服高层管理层敏捷过程允许适当的项目跟踪。 围绕项目进行预算和战略规划活动可以解决这些问题。例如，我们估计一个商业项目需要9到15个月的时间——这是一个相当不精确的估计，因为我们不知道完成的系统将包含什么特性。然而，无论客户想要多少华丽的点缀，我们都合理地确信，在九个月内将提供合适的初始版本。因此，我们说服上层管理层为9个月的开发工作提供资金，并同意在该期限结束时讨论额外的资金。 人力资源 你可能认为人力资源部门对一个群体向敏捷开发流程的过渡不感兴趣，但事实并非如此。在一个正在转向XP的项目中，两位程序员向人力资源部门提出了关于结对编程的抱怨 - 两个程序员共享一个键盘和监视器并一起编写代码 - 当然，这对HR来说听起来很奇怪而且没有效果。因为我们没有告诉人力资源部门有关流程变更的问题，所以我们立即处于难以解释为什么对编程有意义的问题。 另一次，一小部分程序员向HR抱怨他们不喜欢项目的管理方式。投诉源于他们不愿意考虑或尝试任何新的或不同的东西。程序员熟悉计划驱动的流程，其他任何东西看起来都太乱了。这是在1999年，在敏捷联盟成立之前，当Scrum刚刚开始被记录之前，XP已成为一个有趣的流行语。 当一个小组过渡到敏捷过程时，必须告知人力资源部门。然而，当被告知时，人力资源部门可能会提出自己的担忧，集中在敏捷流程的不可交付的可交付成果和动态目标上。许多人力资源部门要求制定纠正措施计划，其中列举了具体的可交付成果和期限，如果不满足这些要求，可能导致员工离职。 很难将XP迭代或Scrum冲刺中的任务变成确定性的纠正措施计划。但是，我们发现，通过积极主动地与人力资源部门合作，我们可以充分定义既能满足人力资源又能让项目遵循敏捷流程的任务和期限。 如何将敏捷流程引入组织将极大地影响流程变更的最终成功。任何新流程都可能会吸引一些开发人员，他们很乐意成为第一批尝试它的人。同样，这种新颖性也是反对改变的开发者的障碍。 敏捷过程在过去四年中不断发展，在一个案例中起作用的方法在另一个案例中没有起作用。随着在20世纪80年代末和90年代初将对象技术引入公司的经验导致发现引入该技术的最佳实践，我们期望在未来几年内对敏捷过程产生理解。 关于作者 多丽丝·福特是精密项目的总裁。她目前的研究兴趣包括软件项目管理、项目度量开发和跟踪方法。福特获得了里吉斯大学的工商管理硕士学位。她是项目管理学院的成员。联系她：dtford@yahoo.com。 原文：https://www.mountaingoatsoftware.com/articles/introducing-an-agile-process-to-an-organization 参考 1. K. Beck，Extreme Programming Explained，AddisonWesley，2000。2. K. Beck等人，“Manilesto for Agile Software Development”，2001年2月; www.agilemanifesto.org。 3. M. Poppendieck和T. Poppendieck，Lean Software Development，Addison-Wesley， 2003。4 . A. Cockburn，Agile Software Development，Addison-Wesley，2002。5 . M. Cohn，“Scrum开发过程”; www.mountaingoatsoftware.com/scrum。 6. K. Schwaber和M. Beedle，敏捷软件开发与Scrum，Prentice Hall，2002年 7。B. Boehm，软件工程经济学，Prentice Hall，1981年 8。F. Brooks Jr.，The Mythical Man-Month，AddisonWesley，1975年 9. B. Boehm，“为谨慎行事做好准备”，计算机，2002年1月，第64-69页。 10. A. Cockburn和J. Highsmith，“敏捷软件开发：人为因素”，计算机，2001年11月，第131-133页。 11. M. Cohn，“缩小规模的好处”，软件测试和质量工程。，2003年1月，第18-21页。 12. Shine Technologies，“敏捷方法调查”; www.shinetech.com/agile_survey_results.jsp，2003年1月。
