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