“我听了你的描述，大致了解了你们碰到的问题。刘同学，现在是不是有团队成员对建立模型感到头疼？”徐老师不再卖关子，开始认真分析起刘云鹏团队的现状。
“对，对，确实如此。”
“其实你们遇到的，也是不少刚接触敏捷的团队经常出现的问题，就是太过形式化。敏捷开发，更注重的是一种思想。并不是说，我们画了白板，每天开站立晨会、几种模型一堆，就算是敏捷开发了。虽然敏捷开发比较推荐这些方法，但是这些方法本身并不能代表敏捷。回到一开始我们讨论的那个问题——‘敏捷就是快’，为什么我说它对也不对，因‘快’只解释了‘敏捷’当中的‘捷’——这也是敏捷的目的。那么怎样来达到这个目的？这就要理解‘敏’这个字——就是灵活。”
“灵活？”
“没错。所谓灵活，就是要快速应对变化，针对不同的场景，选择最高效的方法来解决问题。这里的关注点应该聚焦在‘解决问题’上，而不是方法本身。我们选择敏捷方法的目的，是为了实现快速交付。所以只要是对提高效率有帮助的方法，就是好方法。而一旦某个方法影响了开发效率，那只有两种可能：要么就是这个方法本身不适合敏捷开发；要么就是在方法的执行上出了问题。你们现在遇到的麻烦，就属于后者。”
“我有点明白了，老师的意思是，我们对于敏捷方法的运用，过于刻板了。”
“刘同学总结的对。”徐老师点了点头，继续说道，“刚才你也说道，有成员对建模感到头疼，这就是很典型的本末倒置了。敏捷建模不是写文档，我们不推荐、也没有必要对建模进行标准化管理。敏捷建模是一种非常灵活的构造方式。比如一名成员在白板上画了个草图，再配合自己的解释，将软件的某个特征描述清楚了，这就是一次好的建模。敏捷建模不需要多么美观，也不用过多地追求细节。就是随手一画，快速讲解和补充，讲完就擦掉，然后把精力放到下一项工作内容上。通过简单的方式，实现高效沟通，这才是敏捷建模的目的。当然，建模的方式不局限于画白板，这只是举个例子。”
听完徐老师的分析，刘云鹏恍然大悟。一直以来，自己对于这些方式方法的本身的追求太过执拗。说白了，他只是套上了一件“敏捷”的外衣，核心还是传统的、追求标准化的那套思想。敏捷开发之所以推荐那些方法，是因为这些方法能满够足敏捷开发“灵活应对”的要求，并不是说由这些方法而构成了敏捷。自己在没有充分理解敏捷开发的前提下，一味地推行这些方法，这无疑加重了大家的负担，本质上跟让大家加班赶进度并没太大区别。
告别了徐老师，刘云鹏内心无比明朗。问题的症结找到了，身上的压力似乎已经轻了一半。
回到项目组，刘云鹏大刀阔斧地砍掉了不少形式主义的东西。他向所有成员灌输了简单、高效、快速、灵活的工作原则，而不必拘泥于形式。最让大伙欢欣鼓舞的，就是他改变了以往将建模文档化的误区。要知道，程序员最怕的就是写文档了。
除此之外，刘云鹏还露了一手从训练营学来的新招数。这天，又到了规划下一个版本的日子。刘云鹏将大伙召集到了会议室，然后掏出了一副扑克牌。
“老大，你这是要带我们斗地主呢，还是炸金花？”小侯忍不住问道。小侯是一名九零后程序员，性格活泼，还时不时会冒出一些奇思妙想。
“没见识了吧，这叫敏捷扑克。来来来我教你们一种新的玩法：一会儿我给大伙发牌，牌上的数字代表工作量，1就是一个人开发一天，2就是两天，以此类推。然后杨伊青每讲解完一份需求，大家就估算一个工作量，然后把相应数字的牌盖在桌子上，我数一二三大家一起翻牌。出牌比平均数大很多，或者小很多的，要发言说明理由。所以你们都给我认真估，别想捣乱，都明白了吗？”
“那是不是谁出的小就归谁开发？”小侯又问道。
“那可不一定，这只是确定开发量，到一周的工作量估满为止。具体谁负责哪部分，我会根据整体情况分配。所以大家放心出牌，有任何想法都可以随时发言。万一你有问题没提出来，任务又分到了你头上，吃亏的可是自己啊。好了，没问题的话，我们就开始。”
气氛比想象中还要热烈，大家对这种趣味性很高的会议都非常感兴趣，就连平时沉默寡言的成员也开始主动发表意见。分配完任务之后，大家的工作状态也比以往更加积极。一个个都卯足了劲要证明自己估的数字是正确的。这些当然都在刘云鹏的掌握之中，这也正是他推行这个方法的目的。而出乎他意料的是，大家对敏捷扑克的热情异常高涨。每个人都摩拳擦掌，等着每周评估工作量的日子一展身手。这个敏捷扑克，竟还起到了团建的效果。
看着需求池里堆积的需求逐渐开始减少，刘云鹏总算舒了一口气。他很庆幸自己做了一个正确的选择。敏捷管理就像是高手过招，只有将自己的身手练得足够灵活，才能在各种套路下闪转腾挪，真正做到唯快不破。
网友评论