敏捷（agile）作为软件开发的一种模式，已经热了有好几年的时间。很多人连敏捷宣言都不知道或者不理解，就开口闭口谈敏捷：
个体和互动 高于 流程和工具 工作的软件 高于 详尽的文档 客户合作 高于 合同谈判 响应变化 高于 遵循计划 也就是说，尽管右项有其价值， 我们更重视左项的价值。
不知道或者不理解这一宣言而去实施敏捷，就好像打仗不讲究战略，只沉迷于战术一样，最终只能走向失败。我司一些team最近开始尝试scrum，每天举行站立会议，将其固定成为一个流程。这忽略了敏捷宣言中的第一条：『个体和互动高于流程和工具』。站立会议很好，是一个让大家保持focus，展示成功，寻求支援，小碎步快速前进的工具。但是，它的前提是尊重个体（亦即让团队中的每一个人都能够得到充分授权，自主发挥），如果一件事有几个婆婆管着，那就算每小时站立会议，也敏捷不起来。
对敏捷宣言的另一个很大的误区是逆反。拥抱敏捷的人往往对waterfall的弊端深恶痛绝，所以他兴奋地看到了左边的部分，认为这就是敏捷的全部；而由于痛恨右边的部分，便以敏捷为借口，狠狠地攻击右边。右边内容的价值在任何时候都很大，敏捷宣言只不过想将人们的注意力放在之前被忽视的左边。一个常见的谬论就是『我们在使用敏捷方法，所以不需要（遵循）计划』。听上去是不是很耳熟？
拥抱敏捷的人们，基本上还会忽略敏捷软件开发的十二条原则：
- 我们最重要的目标，是通过持续不断地及早交付有价值的软件使客户满意。
- 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。
- 经常地交付可工作的软件，相隔几星期或一两个月，倾向于采取较短的周期。
- 业务人员和开发人员必须相互合作，项目中的每一天都不例外。
- 激发个体的斗志，以他们为核心搭建项目。提供所需的环境和支援，辅以信任，从而达成目标。
- 不论团队内外，传递信息效果最好效率也最高的方式是面对面的交谈。
- 可工作的软件是进度的首要度量标准。
- 敏捷过程倡导可持续开发。责任人、开发人员和用户要能够共同维持其步调稳定延续。
- 坚持不懈地追求技术卓越和良好设计，敏捷能力由此增强。
- 以简洁为本，它是极力减少不必要工作量的艺术。
- 最好的架构、需求和设计出自自组织团队。
- 团队定期地反思如何能提高成效，并依此调整自身的举止表现。
看看『可交付』，『可工作』，『可持续开发』出现了多少次。敏捷首要的目标是交付，持续交付，从零碎的可交付功能一直到最终完善的产品。那些使用scrum，把项目切成一个个sprint，但还是半年一次交付的团队，就算团队成员各个都通过了"Scrum Master"认证，也并不敏捷。
敏捷讲究个人的权利和责任，强调对个体的信任和授权，因为这是个体斗志的来源。好的敏捷团队在面对争执不下的设计或者解决方案时，应该是这样的态度：『我保留我的意见，既然这是你的feature，你有权利按照你的想法去实现，并为此承担责任』。『没问题』。
复杂是软件的敌人。复杂同样是敏捷的敌人。过度设计比考虑不周还要恐怖。考虑不周可以在后续的开发中去补救，过度设计则浪费了大量人力物力，拖延了进度，还增加了本不必要的复杂性。
最后讲一点实施敏捷的心得。敏捷是道，实施方法（如scrum）是术，不可本末倒置。定期观察团队的表现，选择适合团队的practice。
我创业的公司使用scrum，开始收效很好。每天站立会议，每两周一个sprint，sprint结束时开会show delivery和安排下个sprint，每个月一次retro，大家干得热火朝天，斗志激昂。但后来随着开发节奏的变缓，各个practice开始变味，尤其是站立会议，成为鸡肋。这时，每天的站立会议已成为制肘，应该两天一次或者变换形式。
