敏捷的几个常见误区，您中招了吗？

昨晚公司年会，酒喝的很嗨（就这么点出息...）感谢大佬们和小伙伴们对我的信任和支持，感激并喝大之余，摸摸自己做流程质量的奶..啊不，良心！自问用敏捷的项目越来越多，然而敏捷究竟发挥了多少作用呢？结果是彻夜难眠...

于是想分享点浅知拙见，希望能抛砖引玉，引发大家多多思考。

常见agile误区：

1. 出于错误的原因使用agile（比如政治任务，盲目迷信流行，客户爸爸要求等等）而不考虑项目本身的特点

2. 为了轻松方便而使用agile（比如客户只是希望团队快速交付而不清楚自己的责任，团队希望能更轻量的工作免去文档等等）导致实施过程中必要活动的缺失或者不完整

3. 缺乏原则，太过频繁的改动和尝试（比如迫于上线压力牺牲质量检查相关工作，忽略sprint前的需求梳理活动，等等）

4.关门自嗨，缺少组织级的帮助和指导（丧失跨项目组敏捷经验分享，缺少帮助和必要的监督）

正如我和很多朋友常提起的，敏捷的“形”其实很容易，“神”往往缺乏深思熟虑导致没有产生应有的价值。

举个几个栗子，每日站会 - 真的有识别出问题和风险吗（而不是所有人依次向TL汇报工作，彼此并不关心，全靠TL的最强大脑和火眼金睛）？

用story来承载的需求 - 真的有真实的优先级（而不是都是最高优先级），足够清晰（不是客户爸爸大笔一挥寥寥几句看起来像是story然而团队并不能确信真的该实现什么）足够小能完成（如果最高优先级的story需要一个sprint来完成，这个story很有可能交付不了，而且基本可以肯定其他story都是摆设了）交付出去有价值且可验证（客户爸爸很可能是技术大牛，拆你几个task当story先做，至于上线么，一个月以后再看吧）吗？

story point - 您确定它真的可以独立于工程人员水平并且和工时间没有换算关系？

为敏捷带顶安全帽：

敏捷活动的“形神兼备”不仅需要对敏捷的深刻理解，更需要系统性的工程管理框架作指导，比如CMMi （哎～就这么强硬的插广告）有朋友可能会疑问，提出敏捷不是因为CMMi太heavy吗，用敏捷就是为了取代CMMi啊？非也非也，具体解释查看历史文章

《天书经文二十卷，不入凡间只做尘 - 用坏了的CMMi》

，这里只举几个“安全帽”的简答栗子：

为保持一致性，还是拿CMMi过程域VER的“同行评审”peer review举例，敏捷团队可以不开代码同行评审会议吗？只要你满足了同行评审的设定目的就可以啊！比如有采用结对编程pair programming吗？结对编程玩的咋样？

CMMi v1.3的同行评审有3个具体实践（注意，CMMi对具体实践是expected，而不是mandatory! 啥意思？具体实践来自业界最佳实践，墙裂推荐！)“1准备同行评审”，“2执行同行评审” 和 “3分析评审数据”，如果结对编程能在团队中顺其自然（1准备ok）的进行（2执行ok）并且结对编程的有效性可以被客观的认识（3分析ok）那么这样的结对编程就可以取代传统的代码同行评审会议。

所以您看，通过参考CMMi，敏捷的活动是不是考虑的更周全了呢？（很多团队有满足“执行”，较少团队满足“计划”，满足“客观分析”的团队就更少了）而且CMMi还有一个“institutionalize”的概念，在我们的例子中，组织有给结对编程提供足够的指导和参考吗？组织中关于结对编程的实践中的经验教训有反馈到组织级从而帮助其他团队吗？

所以，敲黑板划重点！CMMi并没有阻碍团队执行有效的敏捷活动，相反它提供了更高成熟度的支持。

类似的还有CMMi的PMC(Project Monitor and Control), MA(Measurement and Analysis)等等过程域提高scrum的每日站会daily standup meeting，回顾会议retrospective meeting的成熟度等等。

Take Away Message:不谈责任的权益都是耍流氓，在享受敏捷活动的轻量时请不要忽略其背后深刻的意义，如果您对当前的敏捷活动不放心，欢迎参考CMMi