敏捷基础篇

  昨天下午，是我个人第一次给别人讲敏捷agile。实话说，对敏捷的认识还是自打来到目前的公司后逐步形成的，一是公司主推这个；二是自己也确实想领略一下这个时下非常流行的咚咚，看看与自己研究蛮久的UP有什么异同，有什么可以互相借鉴的。

  昨天的这次培训，针对的是一个全新成立的团队进行的，有些人来自己不正规的公司，也很大部分来自做CMMI很久的公司。他们在培训中提出的问题其实还是很有代表性的。我先说两个。

   第一个是关于保证执行力。敏捷是一个轻量级的过程。所谓轻量级就是说没有那么多繁文缛节，搞文海战术。敏捷里面反反复复提到的就是团队，抢夺人与人之间的互动、沟通和协作。从这点上，不是每个人都适合敏捷的。因为有些人天生就是陀螺，不抽不转。而敏捷无论从评估，计划，挑选任务。。。等等日常活动，都强调的是自觉以及平等，开放。没有人强迫你一定要干什么。所以在这种氛围下，一个团队可以走向两个极端，一种是积极的，那就是每一个人都把团队里面的事情看作自己的事情；另一中相悖的就是消息的，反正没人管我，我慢慢做就好了。一个团队的风格是靠领导有意识的去形成的，首先是部门的整体氛围，比如就是学习型的，活跃型的。。。然后到团队，团队的氛围也是由领导和成员共同形成的。在一个积极向上的氛围你，那些懒惰的人要么会被感化，要么会被淘汰，是自然淘汰而非人为淘汰。因为大家都在唱四四拍，就你一个人慢半拍，自己听着也会别扭，哪怕别人不说你。当然，敏捷的绩效判断也越来越成熟，我见过一些组织的很好的雷达图，可以从不同纬度对一个组织的敏捷能力做出成熟度判断。所以，以我2年多，运作3个团队的敏捷经验来看，敏捷化的团队做事和别人是不一样的，通常是热火朝天，沟通的时间很多。

  第二个就是软件和文档的关系。在敏捷的观念中，你做什么和不做什么，非常容易判断。一切都是客户价值导向。当然有个前提是在限定的时间范围内。既然时间有限，那么把软件做出来，比把各种文档写的很漂亮一定重要很多。这里的文档不是说用户手册之类，而是规格说明，设计啊之类用于内部交流的文档。让文档说话，不如让软件说话，让BA把图画出来，还不如BA和DEV直接合作，把原型直接做出来，然后截个图。设计文档，通常只捡重要的画，画的目的一定是为了搞清楚一件事情，而不是为了锻炼自己的UML能力。有了这个价值观，团队里决策一件事情应该会轻松很多。甚至于QA的测试，完全都可以在没有case的情况下完成。因为写case就是跟我们做设计一样，是为了加深对系统的理解，而我们目前跟是写case跟执行case通常是一个人，写case更加不用着急。QA完全可以在没有case的情况下，凭借自己的理解，向大家拍胸脯说，我觉得这个story没问题了，可以done了。那觉得是OK的。等到下一个冲刺的时候，遇到DEV长周期而QA是短周期的情况下，再回头去补case。

  敏捷其实会比别的流程更加好玩一些，听培训稍显无聊，等到真正去做的时候，一个新人肯定会有点手足无措，因为每个人都被赋予了一定的领导权力和责任。