敏捷到“末法时代”了吗？

敏捷是一种从2000年之后开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。2001年，敏捷联盟成立( http://www.agilemanifesto.org/ )，17位牛人在某个滑雪胜地讨论“更好的软件开发模式”，激烈讨论后达成了若干共识，作为敏捷宣言和敏捷原则：

• 我们一直在实践中探寻更好的软件开发方法，身体力行的同时也帮助他人。由此我们建立了如下价值观：
• 个体和互动 高于 流程和工具
• 工作的软件 高于 详尽的文档
• 客户合作 高于 合同谈判
• 响应变化 高于 遵循计划
• 也就是说，尽管右项有其价值，我们更重视左项的价值。

敏捷宣言发布之后，敏捷宣言人们聚合成多个公司或工作室，实践和传播敏捷教义，致力于敏捷推广。敏捷传道者-Thoughtworks公司于 2006年在中国举办AgileChina首届大会。在中国的先驱是诺基亚西门子（主要杭州、北京2个offIce），按国外管理层意愿全面执行敏捷。2010年敏捷10周年，敏捷联盟通过一系列的重型活动，Baidu等公司进行了演讲，特别是ThoughtWorks与华为全面分享了敏捷实施经验，坚定了软件公司老总们推行敏捷的决心，敏捷终成大势。据美国某机构调查，敏捷模式占70%以上。如果你不敏捷，你就outer 了。
这个过程，敏捷联盟固化了用户故事、评估卡片、燃尽图、看板、日立会、测试驱动开发（TDD）等各种实践，并融合XP（极限编程）、自动化测试、持续集成等技术实践，形成了Scrum为代表的若干敏捷框架。

 

随着敏捷大潮的涌动，越来越多的人和公司加入。因为敏捷框架的开放性，大家根据自己的理解和实际情况对敏捷进行了剪裁、创新、甚至重构，迄今为止，“敏捷”也没有完整的定义，各个敏捷流派之间的具体名称、理念、过程、术语都不尽相同。中国更是百家争鸣百花齐放，产生了“一千个软件从业者就有一千个敏捷”的现象，有珍珠、也有泡沫和泥沙。个人总结，大致有几种情况：

1、企业根据内部管理的需求对敏捷框架进行了较多改造。在宣贯过程中未阐述清楚其改造的核心原理和考量，该企业的员工从而对敏捷产生认知差异
2、在学习和应用敏捷的过程中望文生义、自行脑补、自圆其说，典型行为是认为采用日立会和看板就是敏捷了
3、培训公司根据片面理解和简单实践，自我标榜、以讹传讹……
4、项目管理工具厂商出于营销目的披上敏捷的外衣……
5、……

我个人对敏捷的理解：自我驱动并关注目标交付的团队，激发极大热情、紧密协作和沟通，通过快速迭代方式来响应用户多变的需求，使软件开发风险最小化，推动团队的成长和持续改进，从而提升生产效率。

目前很多人在讨论敏捷是不是“末法时代”了，主要的原因：

1、应用场景：从敏捷的场景，更多是作为厂商给客户提供软件，目前互联网公司、电商的十分兴盛，更多的是自己开发、自己运营和维护，生产的场景变化了，配套的敏捷实践还需完善，说白了就是“生产力和生产关系”的纠结问题。DevOps的兴起，也是踩在敏捷的肩膀上……
2、敏捷对团队成员要求非常高，要求能自我驱动和持续改进。很多公司的团队成员特别是Scrum Owner和Master，不能够驾驭敏捷，导致了很多问题
3、敏捷的推行，涉及到企业组织结构的调整
4、对企业管理层来说，团队需要持续证明敏捷带来的价值



无论是瀑布、迭代、敏捷，还是DevOps，都是要“生产力和生产关系”的问题：在传统软件行业中抽象为“多快好省”、互联网行业要求“小步快跑、追求极致”等，总之都是
解决客户满意、降低风险、团队成长、提升生产效率、流程高效顺畅等方面，从而提高利润。无论白猫黑猫，抓住老鼠的才是好猫。在各个不同的生产场景下，最适合的模式才是最好的。

你所清楚预见的、热切渴望的、真诚追求的、全心全意争取的，都会自然而然的实现。--保罗麦尔

附：敏捷12项原则：
1、对我们而言，最重要的是通过尽早和不断交付有价值的软件满足客户需要。
2、我们欢迎需求的变化，即使在开发后期。敏捷过程能够驾驭变化，保持客户的竞争优势。
3、经常交付可以工作的软件，从几星期到几个月，时间尺度越短越好。
4、业务人员和开发者应该在整个项目过程中始终朝夕在一起工作。
5、围绕斗志高昂的人进行软件开发，给开发者提供适宜的环境，满足他们的需要，并相信他们能够完成任务。
6、在开发小组中最有效率也最有效果的信息传达方式是面对面的交谈。
7、可以工作的软件是进度的主要度量标准。
8、敏捷过程提倡可持续开发。出资人、开发人员和用户应该总是维持不变的节奏。
9、对卓越技术与良好设计的不断追求将有助于提高敏捷性。
10、简单——尽可能减少工作量的艺术至关重要。
11、最好的架构、需求和设计都源自自我组织的团队。
12、每隔一定时间，团队都要总结如何更有效率，然后相应地调整自己的行为。