敏捷方式适用于IT部门/团队吗?

敏捷开发的概念从开始到现在已经有近20年的时间了,似乎也深入了人心。市场营销团队借用了冲刺任务的概念,运营团队正在逐渐适应Scrum的管理模式,人事部亦在寻求更多相应人力资源战略上的灵活性。

但IT是否也要转型呢?关于用怎么样的模式来具体执行“敏捷”,实际上是有争议的。从其本质上来说,敏捷只是为顺利完成复杂的大项目而去设定框架和原则的。

    那到底要不要敏捷呢?

通常情况下,一个复杂的IT项目,好比更换收费系统,需要跨部门的通力合作。IT团队希望以迭代的方式快速完成,但由于此类项目会影响到公司业务的方方面面,有时几乎是不可能的。另外,在升级或者更换公司软硬件系统时,IT团队不是一直能用迭代的方式来具体操作。

敏捷不是在项目开始前把需求清晰地制定清楚,也不是一开始就已经明确了工作范围。但是,对一个涉及到整个公司的大项目,我们需要了解最终的需求及项目的结果,否则每个人系统的可能会有问题。所以,能否把敏捷的方式具体应用到这个超大项目呢?

我们想是可以的,但可能不是你认为的那种常规敏捷。

请记得,敏捷并不是每个人都要遵守的“铁律”。它只是一种方法论,一套团队每天努力追寻的原则和价值所在。在软件开发中,很多团队经常使用Scrum或者Kanban这种框架来开展工作,但对于不适合用这种的框架的情况,特别是IT项目的立项阶段,并不意味着敏捷一定不能用。可以简单地参照项目的目标/目的,然后把其拆解成一个个较容易完成的小任务,最后进行迭代,并逐步开始构建。

    在敏捷中注入传统

我们拿很多IT团队面临过的真实案例来说明:替换收费系统。

其中一个可以采取的方式就是一次只专注一个产品:对这个特定的产品的需求来构建系统和功能。团队在摸索过程中学习,把总结的经验带到以后的开发中去。

但问题是,涉及到整个系统的需求是互相关联的,同时有时候是相互矛盾的。可以把它当成打包买了一个产品,然后许可证的费用上就有优惠,或者是从一个商家那里批量采购多个产品。

这些需求什么时候能满足?什么时候为第一个产品建立范围和开发流程?在开发第一个产品满足需求的同时是否要第二个团队的介入?

这种根据敏捷法则衍生而来的以产品为单位的方式就站不住脚了。

业务需求指的是what,而解决方案指的是how。你不必完完全全使用传统瀑布的方式,例如等到所有需求和解决方案百分百地确认清楚了再开始行动,但你需能所有东西整合到一起,用以满足业务和技术上的需求。另外,你需要和所有相关人员进行确认,这就意味着解决方案需要从头至尾地进行彻底的审查,并对关键节点进行压力测试。

对一些受管制的行业,如医疗保健,能源或者制造业来说显得尤为重要。在开始开发后,不按照行业规范来进行的话,后果不堪设想,更别说后续导致的一系列项目延期,预算超支等等。

不可避免地,当你开始开发后,很多事情就会浮出水面。新系统上线后,需求会变,新的法规的实施也可能要对系统进行合规性的调整。因此,在新系统和功能上线为公司业务带来附加价值的同时,项目的开发阶段在不要时可使用敏捷方式来进行。

    放缓会更平稳,更平稳意味着高效率

有时候我们应该停下脚步,考虑未来的前进方向。这样,在未来的道路上才能走的更远更好。在IT部门在帮助公司业务发展的基础上,必须更多的考量如何做出大家都需要的东西。毕竟来说,无论采用哪种方法(传统或者敏捷),最终的核心还是为客户创造价值。

原文链接:https://www.atlassian.com/blog/technology/agile-it