2013深圳敏捷之旅

        今天刚参加完2013深圳敏捷之旅，有幸在一天收获那么多敏捷知识，听那么多大牛分享管理经验，真是非常不错。

        今天的议题比较多，吴穹老师的自动化测试，华为胡伟分享的打造自组织的敏捷团队，李小波的coding dojo，最后腾迅两个项目经理搞的ball-point游戏，还有中国平安的单超分享的敏捷经验都让我印象深刻。

        吴穹老师的演讲恢谐幽默，同时内容也是非常丰富，把自动化测试比做防弹衣非常的贴切。敏捷开发中很重要的一个实践是持续集成，而持续集成中最重要，最核心的就是自动化测试，没有自动化测试的CI，就是一个空壳子，而没有持续化集成的敏捷也是不完整的。我们目前的CI就是一个空壳子，仅仅是编译打包，跑跑sonar检查而已。但是不是我们不想自动化测试，而是真的太难。搭建自动化测试首先需要稳定的测试环境，这个我们没有，甚至我们在本地完全就不能测试，必需部署到staging环境才能真正跑起来，这是硬伤，另外自动化测试对测试人员的要求也很高，至少他们要有一定的开发能力，能够写测试脚本，而不只是写几个case然后像用户一样手动的去测试我们的功能。关于自动化测试，吴老师给我们分享了一些很重要经验：

      1. 自动化测试是防弹衣，是用来守护核心程序的，不是守护所有的程序，就像防弹衣，只是用来保护最重要的部位，如果全身都保护，那就没有办法运动，成本也会过高。所以我们应该对我们最核心的地方做自动化测试，其它部分还是可以继续使用人工测试。

      2. 自动化测试不是为了节省人力成本，不是说写了自动化测试就可以少用一半的测试人员的，这是不正确的观念。

      3. 不要相信录制回放神话，不要使用商业软件，现在的开源软件足够好了，而且更轻量极。

      4. 分层测试，分为UI， service接口层，unit层，最难的其实是单元测试，这通常需要很好的设计或是重构，service接口层也不容易，所以最好是从UI层开始做黑盒测试，通过少量的UI黑盒测试就可以覆盖大部分的功能，因此有自动化的UI测试可以保守你核心的功能可以正常运行，然后才是逐步的进行service层测试，单元测试，这应该是一个金字塔形。

      5. 好的测试工具，selenium, robot framework.

      华为胡伟的分享是如何打造自组织的团队，在他的分享中核心的部分就是他总结的6要素

      1. 目标 - 共同的团队目标，清晰化

      2. 承诺   -  PO与team, SM与team之间的相互承诺

      3. 可视化   -   白板，燃尽图，尽量让任务，进度等更透明

      4. 辅导     -    每个新人都有一个师傅

      5. 授权    -    主人翁精神，每个人都有责任感，有权力和义务，充分的授权，大家才有积极性去一起解决问题

      6. 团队   -     团队精神

       除了这些，胡伟讲的他们的经历也是让我感慨万分的，他说他最初到华为的时候，华为是没有敏捷的，那时候他们刚刚接触敏捷觉得很有意思于是就在团队内部偷偷玩敏捷，而且很投入，这种精神是很值得学习的，这是一种对新事物的探索精神，一种不守旧的开拓精神，更重要的是能坚持玩下去。我一开始接触敏捷的时候，公司也没有推敏捷，我就想带着团队自己做，可是最终没有坚持下来，一是没有公司强推，没有执行力，二是带动不起大家的兴趣，这可能还是我的组织能力不行。

      

       平安的单超分享了他们在金融行业的敏捷经验，很值得我借鉴。我现在做的国泰航空的项目和他的有很多类似的地方，比如项目大，项目老，结构复杂，没有本地环境，是中间系统要和很多外部系统交互，需求变更麻烦。以前我总在想我们这样的系统如何做敏捷？在本地没法测试，结构复杂，不重构也无法单玩测试，跑完整个流程要和很多外部系统交互，需求都是客户零散的发给我们，给一个改一个。平安的做法是付出大的成本在本地搭起环境，这个投入是必要的，其次使用看板，使得任务透明化。因为有了本地环境，他们可以测试前置，测试更容易了。再者就是任务拆分，他们将所有需求交给一个有12年经验的老员工来拆分，拆分是依赖他的业务和技术经验的，这样的好处是比较公平，以他的为标准，对大家来说相对就公平，而且拆分出来的任务大小也都差不多，容易评估和管理，我觉得这也是有局限的，不是每个公司都有这样的人，而且他的个人经验我想也是有局限的，如果没有这样的人，也许大家可以试试功能点估算，重要的是要收集估算数据，慢慢的形成经验数据，这样以后就有了参考。再一个是回顾会议，要有一个轻松的回顾会议，大家愿意提出以前的不足，需要的改进，还有总结出以前做得好的，继续发扬和改进。心情曲线是他们回顾会议上一个挺有意思的东西，就是每个人回想自己在迭代的每个阶段的心情，绘制出一条曲线，这可以看出大家在这个迭代的整体状态，如果大家心情都不好，那就要看看是什么因素导致的，如何消除。

       另外还有敏捷教练王威讲的产品决定成败，里面有讲到敏捷的三个假设：1. 假设人是有能力的; 2. 假设人是有责任感的; 3. 假设知道产品应该做成什么样。也就是说敏捷是有要求的，特别是对人是有要求的。一个团队如果有人不适应敏捷，或者达不到要求，我们可以辅导和帮助他，但是他不上进，不学习，不改变，那么我们一定要把他清出去，如果不这样，整个团队都会被拖跨。

        最后是腾迅两个项目经理带来的ball-point游戏，游戏是说将一个球从一个人传给另一个人，不能传给相连的人，但是每个人都要拿到球一次，最后放到一个盒子里得一分，看2分钟内整体团队能够得多少分，关于游戏的详细大家可以到网上搜一下，我就不详细讲了，我只讲讲我们大家从这个游戏中获得的体会。我们有50多人一个团队来玩，一开始大家都想用什么方法可以得到最高的分数，有人想到分小组，有人想到站成两排，最后一致认为两排比较靠谱，于是用这个方法，但是一开始因为人多没有充分沟通，球经常传到一半就出问题，最后第一次迭代居然只得了2分，第二次迭代，大家统一了一下传球的方法，但是因为协作不够，最后只得了10多分，第三次我们的目标是50分，但是这次虽然我们整体协调了很多，在半路依然出现很多球掉到了地上的情况，另外主持人不断的在给我们心理压力，比如大声的提醒时间，叫大家不要犯规，催促大家快点传球等等，就像是PM在大声的叫嚷，制造着噪音来干扰大家，最后只拿到30来分。第四次我们的协调更进一步，中间掉的球少了，最后拿到了50多分，第五次，我们发现中以一次传两个球，而且不再使用抛的方式，而是采用给的方式，掉球率更少，传得更快了，最后得了80多分。通过这个游戏，我们总结出来很多宝贵的经验:

       1. 团队过大，沟通就成问题

       2. 在敏捷开发中，我们不一定要等到找出最佳的方案，等到团队更融合才开始做事，我们可以尝试，在尝试中大家不断的磨合，不断的成长

       3. 我们一开始想到的分小组就像是组织型结构，后面平行两排就像是扁平化的结构，而这更易沟通和协调

       4. 团队成员如果都可始思考整体团队的问题，并试图去解决发现的问题，整体团队就会一起进步，只有大家一起努力，一起朝着同样的目标，最后才能形成自组织的团队

       这是我参加这次敏捷之旅的一些心得和总结，希望以后能有更多这样的活动大家可以一起交流学习。