敏捷基础篇
昨天下午,是我个人第一次给别人讲敏捷agile。实话说,对敏捷的认识还是自打来到目前的公司后逐步形成的,一是公司主推这个;二是自己也确实想领略一下这个时下非常流行的咚咚,看看与自己研究蛮久的UP有什么异同,有什么可以互相借鉴的。
昨天的这次培训,针对的是一个全新成立的团队进行的,有些人来自己不正规的公司,也很大部分来自做CMMI很久的公司。他们在培训中提出的问题其实还是很有代表性的。我先说两个。
第一个是关于保证执行力。敏捷是一个轻量级的过程。所谓轻量级就是说没有那么多繁文缛节,搞文海战术。敏捷里面反反复复提到的就是团队,抢夺人与人之间的互动、沟通和协作。从这点上,不是每个人都适合敏捷的。因为有些人天生就是陀螺,不抽不转。而敏捷无论从评估,计划,挑选任务。。。等等日常活动,都强调的是自觉以及平等,开放。没有人强迫你一定要干什么。所以在这种氛围下,一个团队可以走向两个极端,一种是积极的,那就是每一个人都把团队里面的事情看作自己的事情;另一中相悖的就是消息的,反正没人管我,我慢慢做就好了。一个团队的风格是靠领导有意识的去形成的,首先是部门的整体氛围,比如就是学习型的,活跃型的。。。然后到团队,团队的氛围也是由领导和成员共同形成的。在一个积极向上的氛围你,那些懒惰的人要么会被感化,要么会被淘汰,是自然淘汰而非人为淘汰。因为大家都在唱四四拍,就你一个人慢半拍,自己听着也会别扭,哪怕别人不说你。当然,敏捷的绩效判断也越来越成熟,我见过一些组织的很好的雷达图,可以从不同纬度对一个组织的敏捷能力做出成熟度判断。所以,以我2年多,运作3个团队的敏捷经验来看,敏捷化的团队做事和别人是不一样的,通常是热火朝天,沟通的时间很多。
第二个就是软件和文档的关系。在敏捷的观念中,你做什么和不做什么,非常容易判断。一切都是客户价值导向。当然有个前提是在限定的时间范围内。既然时间有限,那么把软件做出来,比把各种文档写的很漂亮一定重要很多。这里的文档不是说用户手册之类,而是规格说明,设计啊之类用于内部交流的文档。让文档说话,不如让软件说话,让BA把图画出来,还不如BA和DEV直接合作,把原型直接做出来,然后截个图。设计文档,通常只捡重要的画,画的目的一定是为了搞清楚一件事情,而不是为了锻炼自己的UML能力。有了这个价值观,团队里决策一件事情应该会轻松很多。甚至于QA的测试,完全都可以在没有case的情况下完成。因为写case就是跟我们做设计一样,是为了加深对系统的理解,而我们目前跟是写case跟执行case通常是一个人,写case更加不用着急。QA完全可以在没有case的情况下,凭借自己的理解,向大家拍胸脯说,我觉得这个story没问题了,可以done了。那觉得是OK的。等到下一个冲刺的时候,遇到DEV长周期而QA是短周期的情况下,再回头去补case。
敏捷其实会比别的流程更加好玩一些,听培训稍显无聊,等到真正去做的时候,一个新人肯定会有点手足无措,因为每个人都被赋予了一定的领导权力和责任。