敏捷方式适用于IT部门团队吗
敏捷开发的概念从开始到现在已经有近20年的时间了，似乎也深入了人心。市场营销团队借用了冲刺任务的概念，运营团队正在逐渐适应Scrum的管理模式，人事部亦在寻求更多相应人力资源战略上的灵活性。
但IT是否也要转型呢？关于用怎么样的模式来具体执行“敏捷”，实际上是有争议的。从其本质上来说，敏捷只是为顺利完成复杂的大项目而去设定框架和原则的。
那到底要不要敏捷呢？
通常情况下，一个复杂的IT项目，好比更换收费系统，需要跨部门的通力合作。IT团队希望以迭代的方式快速完成，但由于此类项目会影响到公司业务的方方面面，有时几乎是不可能的。另外，在升级或者更换公司软硬件系统时，IT团队不是一直能用迭代的方式来具体操作。
敏捷不是在项目开始前把需求清晰地制定清楚，也不是一开始就已经明确了工作范围。但是，对一个涉及到整个公司的大项目，我们需要了解最终的需求及项目的结果，否则每个人系统的可能会有问题。所以，能否把敏捷的方式具体应用到这个超大项目呢？
我们想是可以的，但可能不是你认为的那种常规敏捷。
请记得，敏捷并不是每个人都要遵守的“铁律”。它只是一种方法论，一套团队每天努力追寻的原则和价值所在。在软件开发中，很多团队经常使用Scrum或者Kanban这种框架来开展工作，但对于不适合用这种的框架的情况，特别是IT项目的立项阶段，并不意味着敏捷一定不能用。可以简单地参照项目的目标/目的，然后把其拆解成一个个较容易完成的小任务，最后进行迭代，并逐步开始构建。
在敏捷中注入传统
我们拿很多IT团队面临过的真实案例来说明：替换收费系统。
其中一个可以采取的方式就是一次只专注一个产品：对这个特定的产品的需求来构建系统和功能。团队在摸索过程中学习，把总结的经验带到以后的开发中去。
但问题是，涉及到整个系统的需求是互相关联的，同时有时候是相互矛盾的。可以把它当成打包买了一个产品，然后许可证的费用上就有优惠，或者是从一个商家那里批量采购多个产品。
这些需求什么时候能满足？什么时候为第一个产品建立范围和开发流程？在开发第一个产品满足需求的同时是否要第二个团队的介入？
这种根据敏捷法则衍生而来的以产品为单位的方式就站不住脚了。
业务需求指的是what，而解决方案指的是how。你不必完完全全使用传统瀑布的方式，例如等到所有需求和解决方案百分百地确认清楚了再开始行动，但你需能所有东西整合到一起，用以满足业务和技术上的需求。另外，你需要和所有相关人员进行确认，这就意味着解决方案需要从头至尾地进行彻底的审查，并对关键节点进行压力测试。
对一些受管制的行业，如医疗保健，能源或者制造业来说显得尤为重要。在开始开发后，不按照行业规范来进行的话，后果不堪设想，更别说后续导致的一系列项目延期，预算超支等等。
不可避免地，当你开始开发后，很多事情就会浮出水面。新系统上线后，需求会变，新的法规的实施也可能要对系统进行合规性的调整。因此，在新系统和功能上线为公司业务带来附加价值的同时，项目的开发阶段在不要时可使用敏捷方式来进行。
放缓会更平稳，更平稳意味着高效率
有时候我们应该停下脚步，考虑未来的前进方向。这样，在未来的道路上才能走的更远更好。在IT部门在帮助公司业务发展的基础上，必须更多的考量如何做出大家都需要的东西。毕竟来说，无论采用哪种方法（传统或者敏捷），最终的核心还是为客户创造价值。