敏捷实战 QClub个人体会

     2014年10月18日，QClub组织了一次QClub的敏捷实战活动。非常有幸参加，收获不少，以下个人体会仅供参考。
     会议是早上10点开始，先自然分成5个小组，每组不超过10人，每个小组成员相互介绍。然后，进入主题，讲师先大致介绍了一下敏捷开发到底是什么，强调，实战出真知。完全照搬某一套敏捷方法的企业很少（30%一下），大多是参考多个，并且结合企业现状实施的。并且指出，敏捷宣言最核心的是通过身体力行和帮助他人来揭示更好的软件开发方式。所以，敏捷也不是银弹，也不能解决所有问题。接着提出了解决的基础：需求过来时井然有序的。并且举例，欧洲的火车与印度的火车对比。
     然后，开始做游戏，每人都有一副《软件工程核状态卡》的扑克。里面，包含了商机、涉众、需求、软件系统、工作、团队、工作方式。每一项，又分成5到6个子项。然后每个小组排序一次，很快的就形成了一个小组的工作流程。我们小组是最保守的，最接近传统方式的：一定要什么都准备好了，才开始，呵呵。
中午休息一个小时后，下午继续。下午的时候，“来”了一个大项目，需要5个组协作完成。每组分配到了4个任务，并且有些任务是有依赖（dependency)其他任务的，而这些任务大多是在别的小组。然后，排期，跟其他组协调。并且组成了一个项目先后顺序的“蜘蛛网”。讲师再针对这个蜘蛛网，提出了相应的问题，和改进意见。还有一些我们也未察觉的事情。最后，讲师还有一点广告时间，介绍了他们推荐的敏捷方式。16:00左右，会议结束。
     在本次活动中，有比较深刻的体会有如下几点：
     1）敏捷宣言最核心的是通过身体力行和帮助他人来揭示更好的软件开发方式。
     由于公司正在找寻新的、更合适的开发方法，总想找到一个“银弹”，原因为敏捷就是其中一个。现在看清楚了，没有“银弹”，只能博众家之长，结合企业情况，找到适合自己的工作方式。
     2）想要高效的产出，必须先有秩序进入，而且不过载。
     让10个人做100个人的事情，在方法上没有大的突破的前提下，单纯的催促和加班，并不能解决问题，反而会导致问题变得更加糟糕。想想一列火车，到处都爬满了人，只能按照20至30公里每小时的速度前进，他的效率和质量远远低于人数恰当并且井然有序的火车，至少可以开到80至100公里每小时。而且舒适（质量好）。
     3）自下而上，推动主动性。全员开会的好处。
     以往在分配任务的时候，都是自上而下的。但是这一次，是我们每一个组员参与讨论，参与意见，然后相互妥协后少数服从多数的一致结果。大家目标一致，自己制定计划。并且以团队的形式上台讲述，这是一种隐性的承诺。各个组员的责任心无形中增加，即使真的以后无法完成，也会尽力去做。