敏捷性
敏捷性是指团队或组织通过以简短、可检验的周期组织工作并获得直接反馈,从而快速应对变化的能力。
"敏捷性"一词可追溯到2001年为软件开发提出的《敏捷宣言》。作为对交付周期漫长、僵化的瀑布式规划的回应,敏捷性主张采用短小、可重复的周期,而不是一份只在最后才被检验的固定计划。其核心在于随着新信息或客户反馈的不断出现而持续调整需求的能力。因此,敏捷性与其说是一种具体方法,不如说是一种思维方式:变化被视为常态,而非干扰。
在实践中,敏捷性体现为具体的工作习惯:短周期的工作阶段(通常是持续一到四周的Sprint迭代)、团队定期同步会议,以及团队回顾自身工作方式的固定复盘会议。常见的框架包括角色和仪式明确的Scrum,以及使用可视化任务看板并限制在制品数量的Kanban。跨职能团队更多地自行做出决策,而不是等待冗长的审批链条。目标是让每个周期结束后都能产出可用的成果,并从中学习。
敏捷性并非在所有情况下都能取代传统的项目管理。对于需求固定、几乎没有不确定性的项目,例如工期较长的厂房建设项目,详尽的前期规划往往能带来更高的确定性。敏捷工作方式同样要求纪律性:如果没有明确的优先级排序,短周期很快就会沦为忙碌却无实质进展的空转。当需求在起始阶段尚不明确、并且持续学习能够优化通往目标的路径时,敏捷性最能发挥价值。
实用示例
一家中型制造企业的12人IT团队将内部订单软件的开发切换为两周一次的迭代(Sprint)。团队不再采用最初计划的为期九个月的一次性大版本发布,而是每两周交付一个可用版本,由来自生产一线的三名测试用户直接评估。第四个迭代结束后发现,项目原计划的一项功能几乎无人使用,于是团队将其舍弃,腾出两周的产能去解决更紧迫的问题。六个月后,软件已正式投入生产使用,比最初瀑布式计划预计的时间提前了三个月。
Leanshift 如何提供帮助
敏捷性与KATA思维方式的核心是一致的:以计划、尝试、检验的短周期方式工作,而不是遵循一份僵化的总体计划。你所经历的PDCA节奏本质上就是一次Kaizen式的Sprint,每一轮都会产生新的洞见,使下一次迭代更加精准。这里的改善并不意味着做得更快,而是意味着变得更善于学习,从而让每个周期都能培养出更多有能力去改善的人,包括你自己。
常见问题
敏捷性等同于Scrum吗?
不是。Scrum是一种角色和仪式都有明确定义的具体框架,而敏捷性是其背后更宽泛的思维方式。Kanban、极限编程(Extreme Programming)以及各种自定义的混合方法同样属于敏捷工作方式。
敏捷性在软件开发之外也适用吗?
是的。市场营销、产品开发以及越来越多的制造业都在运用短周期、定期复盘等敏捷原则,并根据自身情境加以调整。
采用敏捷工作方式意味着规划工作更少吗?
不是的,这意味着规划方式不同。敏捷工作不是用一份计划覆盖未来数月,而是在每个周期开始时进行更细致的规划。这往往需要更强的纪律性,而不是更少。