在线项目管理工具 Proof Hub 开发工程师 Nandini Sharma 表示，调整某些事情的方法有时候可以彻底改变这么做的原因。方法论本身就试图重新想象意义。
在很多时候，由热情驱动的工作通常陷入困境，而方法驱动的工作在努力实现目标的同时不断寻找前进的道路。在本世纪初引入敏捷方法就是帮助软件团队提高生产力的一个例子。
Sharma 表示，作为软件行业的一员，当她第一次听到非软件团队对敏捷方法表示欢迎时，她认为，“非常可行！”
而在毕马威公司一项调查中，77%的受访者表示在IT职能之外使用了敏捷项目管理。此外，59%的受访者在其营销和销售流程中采用了敏捷用例。
敏捷确实具备团队明智的管理资源所需的要素。圣何塞市政部门工作人员采用敏捷来提高生产力和效率，因此对于这一点不要感到惊讶，很多行业也可以这样做。对于开发软件，Sharma 和其团队使用了几种项目方法和团队管理软件来保持工作正常进行。
虽然非技术团队可以自由使用，但这里有一些非技术的方法，可以让世界各地的非技术(软件)团队适应敏捷方法的技术特性。
敏捷对于非软件团队来说是什么？
敏捷最初是为软件团队开发的，它是一种方法论，致力于优先考虑团队协作而不是孤岛运营，将动态变化置于严格规划之上，并让利益相关者积极参与项目。
对于非技术团队，采用敏捷方法的核心原则如下：
•团队所有成员全面讨论手头的任务，互相分享想法。并不是每个人都只做他们自己的事情。
•更多的关注点是付诸行动，执行实际工作，而不是在精心策划上花费时间。
•让关键的利益相关者（主要是客户）积极参与该过程，以对正在取得的进展进行不断的反馈。
•为更改、修改和重新考虑留出空间，以便将其整合到开发中。
•工作在可管理的时间内完成，并具有明确的任务优先级。非技术团队不会同时承担所有任务。
人们可以自由地将这些想法应用到认为合适的工作流程中。由于不专注于编写代码，因此这些想法在实现上会有所不同，同时保持其本质。
需要记住，敏捷是一种意识形态，而不是指令。最好的做法是吸纳这些想法，而不是创建用户手册。
敏捷对非软件团队有什么好处？
敏捷工作方式旨在克服软件团队面临的某些项目管理挑战。但是，如果了解这些概念，对几乎所有计划采用它们的团队都有深远的好处。
以下是敏捷为非软件团队提供的一些好处。
（1）反馈管理
几乎所有类型的团队都需要来自内部组织（员工）或外部消费者（客户）的持续反馈，以使工作与期望的标准保持一致。如果反馈没有被正确吸收或没有一致地分发，其输出可能会变得不规则。Sharma 将其称为“质量不合格”。
在敏捷过程中，工作通常被划分为持续 1～3 周的阶段。在每个阶段结束时，主要利益相关者将对工作进行审查，以便及时指出问题。
因此，非软件团队可以通过遵循敏捷方法，建立以反馈为中心的文化，以保持结果符合预期。
（2）更快的推进
敏捷团队通常可以更快地交付项目，因为团队成员积极学习如何确定工作的优先级，并节省时间。敏捷方法要求团队成员每天进行沟通，并不断了解正在取得的进展。这样，任何需要进行的重大更改都会被及早发现，并作为流程的一部分进行处理。
由于可以及时解决问题，因此避免了长时间的来回修订。项目不会延迟，交付速度也会得到积极影响。
（3）管理不确定性
在任何项目中，真正的交付并非简单的执行计划，而是管理不可预见的事情。任何有经验的项目经理都会认同“无论做什么都会出现不确定情况”的说法。而墨菲定律告诉我们，“项目问题不可避免”，无论计划有多好都会出错，因为它必定会出错。
敏捷方法旨在有效地应对不确定性，因为它不是建立在严格的时间表之上的。团队成员可以灵活地调整项目流程，并在需要时适应变化。
（4）明确的工作流程
大多数敏捷框架都带有旨在保持项目进度高度组织的工作流。需要注意的是，这些工作流程并非旨在进行微观管理，而是为整个团队创建参考点。
最常见的例子是看板框架，它包括“计划实施”、“正在进行”和“完成”等阶段。许多Saas 应用程序提供基于看板的工作流程。
这样做是为了在每个任务从一个阶段转到另一个阶段时，为项目提供系统的任务生命周期。工作流程的存在确保了项目的灵活性可以通过安全栏得到补偿。
（5）客户端集成
敏捷方法强调在项目的每个阶段都要让客户参与进来，而不是在 6 个月后才让他们参与。客户集成在主要问题出现之前解决。服务行业工作的团队很清楚，当客户在投入大量时间之后表示反对意味着什么。
当客户积极参与每周会议、项目更新并清楚地了解项目的发展方向时，就会有更大的成功机会。
敏捷适用于企业吗？
事实上，敏捷适用于企业。以下了解一下敏捷可能不起作用的项目。
（1）当要求明确时
如果客户或项目有明确定义的期望，并且不确定性最小，那么项目可以采用常规的方法。
由于企业不需要大量的客户反馈，并且团队成员必须遵循线性路径，因此敏捷方法的核心原则不会有很多好处。
大多数软件项目在本质上都是探索性的。随着项目逐渐成型，每个人（包括客户）都会弄清楚他们想要什么。如果已经知道项目的结果和方向，敏捷就不会有太大的帮助。
（2）当团队不愿协作时
协作是运行敏捷项目的关键。如果团队不愿协作，那么敏捷可能会适得其反。
显然有一些方法可以改善团队内部的沟通，例如团队沟通工具和小组活动，但说起来容易做起来难。如果觉得团队沟通并不是很大的挑战，那么没有敏捷也可以做得很好。
（3）当可以避免创新时
并非所有项目都需要创新。敏捷开发的目的是让创新轻松融入工作方式。如果项目是一个简单的任务列表，可以标记完成并向前推进，那么可能不需要敏捷方法。
非软件团队的敏捷方法
既然知道了使用敏捷的方法好处和注意事项，那么了解非软件团队如何将敏捷方法融入他们的工作中。在这里需要关注 Scrum：敏捷框架为充分利用敏捷制定了一套规则。
同样，这里只讨论使用 Scrum 的概念性方法，而不会深入探讨机制。
（1）什么是 Scrum？
Scrum 是敏捷方法的可实现版本，在其中讨论科学术语、工作协议和定义的团队角色。从非技术角度上来说，它可以概括为以下几点：
•客户或企业拥有的分析师提出业务需求，这可能是需要完成的材料产品或过程。
•团队了解需求，并开始在设定的时间间隔内自行编排工作，通常需要 1～3 周的时间，在此期间他们将完成一小部分需求。
•在这个时间间隔结束时（比如第三个周末），团队与客户或分析师坐下来，向他们展示他们取得的成果，并确定是否令人满意。
•如果工作达标，则计划实施下一个任务。如果工作需要调整，团队将努力整合更改并相应地计划未来 1~3 周的任务。
关键要点：
•将工作分成几个小部分。
•在固定的时间内处理每个部分。
•审查每个部分取得的进展。
•让关键利益相关者（客户或分析师参与审查）参与进来。
•关注“什么最有效？”，“这就是我们所设想的吗？”等问题
（2）Scrum 团队结构
Scrum 有一个明确的团队结构，以便顺利地协调工作。它可以帮助分配角色和职责，而无需使用确切的标签。
①产品拥有者
•角色：要实现的目标的客户或分析师。
•责任：找出需要解决的问题，仔细了解需要什么样的解决方案；产品负责人制定期望，并验证进度是否朝着正确的方向发展。
②Scrum 主管
•角色：监督 Scrum 流程的关键人物。
•职责：Scrum 主管充当产品负责人和团队之间的纽带。他们管理沟通、确保协作，并确保有效地遵循 Scrum。
③团队
•角色：执行任务的实施者。
•责任：团队负责吸收需求并自行管理可执行文件。他们在彼此之间分配任务，并协作以保持生产力。
非软件团队敏捷的行业示例
（1）Lonely Planet 公司
澳大利亚 Lonely Planet 公司是一家拥有 49 年历史旅行书籍出版商，该公司推出了一个下载量超过 10 万次的移动应用程序。
①面临的挑战
•Lonely Planet 公司的法律团队在管理日常需求方面面临问题。
•法律文件修改较多，工作重点未确定。
•团队成员感到压力过大和不满。
②他们如何变得敏捷
•团队采用看板来为基于“待办事项”或“待处理”的任务提供结构。
•团队使用类似 Scrum 的框架来管理修订反馈，并轻松管理成员的工作。
•如果没有 Scrum 主管，团队成员会自行管理，确定任务的优先级，并确保工作量不会变得不堪重负。
③结果
Lonely Planet 公司的法律团队能够将生产力提高 25%，并减少工作环境中存在的整体混乱。
（2）荷兰国家艺术博物馆
荷兰国家艺术博物馆是荷兰最古老的博物馆之一，建于 1885 年，收藏着荷兰艺术和历史的精美作品。
①面临的挑战
•该博物馆需要根据它们所属的历史时间来管理和展示其文物。
•由于管理所需的大量工件和专业知识，任务变得繁重。
②他们是如何转向敏捷的
•在博物馆工作的团队将自己组织成自我运作的小组，并对历史上出现的文物进行分类。
•他们在完成任务的几个小组之间建立了强有力的沟通，并积极合作以实现目标。
•该方法是非线性的，因为团队在进行中改变了他们的团队结构、方法和速度。
③结果
该团队能够高质量地完成任务，并采用这种敏捷流程来随着博物馆流量的增长，不断改变博物馆的陈列和展示方式。
（3）美国国家公共广播电台
美国国家公共广播电台是一家拥有 50 年历史的广播电台，在美国拥有 1,000 多个联合广播电台。
①面临的挑战
•美国国家公共广播电台向制作广播节目推销创意，但他们很难想出一个看似成功的节目模式。
•美国国家公共广播电台节目的构思过程具有风险、成本高昂，并且通常需要进行多次更改。
②他们是如何转向敏捷的
•美国国家公共广播电台通过创建小型迭代“试播节目”，采用敏捷的方式推销创意，并与当地团队、地区项目主管和社交媒体上的听众一起进行测试。
•与带有不确定性的成熟节目相比，这些试播节目虽然成本不高但也不容易传播。
•他们利用各种来源的反馈，积极了解观众最喜欢什么，作为他们完整制作节目的基础。
③结果
该团队使用敏捷的方式来管理节目的编排，以减少不确定性，并整合来自多个渠道的反馈，从而实现经济高效、快速、高质量的制作。
结论
如果项目的不确定性、不完整的需求和模糊的愿景是项目的一些特征，那么应该尝试一下敏捷原则。
它在使软件团队获得更大成就方面有着良好的记录，并且对其他团队也具有巨大的潜力。本文是理解敏捷方法的一种尝试，虽然可能无法完全理解这一点，但可以将本文作为入门介绍。
毕竟，这一切都归结为如何提高生产，这需要花费更多的时间来掌握。
