敏捷适用于 IT 团队吗？

敏捷适用于 IT 团队吗？

先别着急回答，让我们一起看完这篇文章再给出你的答案。

敏捷宣言发表近二十年了，似乎“敏捷”已深植于全球每个团队。 市场营销团队正在试验冲刺，运营团队正在采用  Scrum，而人力资源团队正在寻求为其战略带来更多灵活性。

但是 IT 团队呢？

关于哪些框架最适合“敏捷”其实存在很多争论，但从本质上讲，敏捷的原则和出发点实际上是帮助解决大型且复杂项目。

IT 团队是否该选择敏捷？！

通常，复杂的 IT 项目，比如更换计费系统，需要跨职能部门进行协调。IT 团队希望快速执行并迭代，但真正执行一个几乎影响整个企业业务系统的项目以及考虑所有项目进程是，会觉得敏捷的方法是不适用的。因为 IT 团队并不总是能够在更新公司的基础架构或执行系统更换时使用迭代方法。

敏捷不是明确定义的需求，也不是在开始之前就知道工作的全部范围。但是对于一个大型的跨整个公司的计划，需要理解端到端的需求以及最终的执行结果，否则可能每个人的系统都会崩溃。那么，有没有可能将敏捷方法论应用于这样一个庞然大物呢？

我们认为是可以的，但这也许不是常规意义上你所理解的敏捷。

请记住，敏捷并不是每个人都必须遵循的规范性规则。这是一种方法论，一套团队努力追求的原则和价值观。在软件开发中，团队经常使用 Scrum 或 Kanban 等框架来指导他们的工作。但是对于那些框架不适合的场景，并不一定意味着不适用敏捷，特别是对于 IT 项目的构建阶段。它可以简单到如查看项目的目标，将其分解为一个小的可实现的工作块，然后从那里进行迭代和构建。

瀑布+敏捷工作法

不如我们就拿许多 IT 团队面临的现实场景：更换企业计费系统来举例。

团队可以采取的一种方法是，一次只采购和更换一种产品，构建特定产品要求所需的系统和特性。团队在执行进程的过程中学习，把这些经验教训带到每个产品更替的下一轮构建中。

但这也带来一个问题：有时公司在采购时可能一次性选择全套产品或整体解决方案，这些产品有些是相互依存的，有些甚至和原有系统是相互矛盾的。我们可以根据敏捷原则，从单一产品入手，一个产品一个产品的打破僵局。

业务的需求是 What，解决方案的需求是 How。在这个项目中，我们可以使用瀑布的方式，但不一定是从头至尾只用瀑布方法，比如要求必须所有业务要求和所有解决方案要求都 100％ 签署才开始编写第一行代码，但我们需要能够将所有内容拼接在一起，了解业务和技术要求的端到端解决方案。我们需要确认可以获得所有利益相关方的支持，这意味着解决方案需要被严格审核，并对关键任务进行压力测试。

如果你属于传统行业，如医疗保健，能源或制造业，瀑布方法很重要。在不遵从合规性和监管的情况下就开始构建阶段将可能导致灾难，更不用说项目被延误以及预算超支。

但无论我们在前期考虑的有多周全，当项目开始实施时，很多计划外的事件可能会随时发生，需求也可能会发生变化，外部因素如法律条款的变更也可能对合规性产生影响。因此，在项目的实施阶段可以在需要的时候在瀑布和敏捷之间进行转换，以创造最大价值。

慢，即是快

有时候，我们要学会放慢脚步，多花些时间进行规划和思考，这样才能保证正确的方向和行进的速度。随着 IT 团队的转型，IT 越来越多的帮助业务的增长和发展。因此，我们需要更多地思考如何用正确的方法做正确的事情。毕竟，无论采取哪种方式，敏捷还是瀑布，最终的核心都要为我们的客户创造价值。