2013敏捷之旅成都站
趁着周末，去参加了2013敏捷之旅的成都站活动，还是收获了不少。活动现场，有经验丰富的开发人员、管理人员以及很多敏捷实践者。
上午是两个专场演讲，一个是ThoughtWorks首席咨询师郑晔讲的一些该更新的开发知识。从这个十多年开发经验的人的演讲中，还是接触了很多新概念，比如列表转换、反IF、反For等等，他熟悉很多语言的一些新特性，例如C++、Java以及Rails等等..推荐我们通过不断的学习去使用一些新特性解决我们的问题，可能新语言并不会成为我们工作中的主要媒介，但可了解行业发展方向，对于解决遇到的一些业务问题是有很多益处的。另外一个插曲，当你20岁的时候想，30岁适合做程序员吗,这样到了30岁，你想..40岁了还适合做程序员吗；郑晔，我认为就是这样的实践者。
另外个是一个来自上海的康仕成公司的创始人Ethan. 也是十多年的开发经验，以前的硅谷程序员，他用自己的国际视野给大家讲解了敏捷的一些概念和内涵，以及大家应该如何去学习敏捷，康仕成是一家从事敏捷转化或者说敏捷培训的咨询公司，也有点类似ThoughWorks。通过他的演讲，让我了解到敏捷并非自己所认识的那么简单，也不只是我认为的那些形式。最近两年，在部门的工作中，我也想去实践敏捷，这得益于前任技术经理的卓识，不过自己所做的只是敏捷的一些边角，例如举行例会，缩短迭代周期、注重过程减少文档等方面。通过Ethan的演讲，明白了敏捷里的一些分支和流派，比如Technical Mastery、Business Mastery等，想在敏捷的道路上走下去方向是很重要的。在PPT上，有个章节很有意思，在敏捷实施前，一个测试人员说:我没啥可测的。实施敏捷以后，测试人员说:今天没啥可测的，明天也没啥可测的。另外一点，说到了团队推动敏捷的问题，一种是技术驱动型、另外一种是问题驱动型，现场也让一些同行来分享了经验，部分人认为敏捷能解决的具体问题还不够明确、另外部分觉得敏捷推动起来比较困难。从我的经历来看，推行敏捷需要资源的支持、同事的知识更新、方向和目标明确，不然会出现，你抛出一个改进意见，可能会得到3个反对意见，而不是3个改良意见。
下午开始的时候，在David33的组织下，大家做了个小游戏，每人心里想了一个0-99的数字，然后需要整个会场的人闭眼按照从小到大的顺序围成一个圈。这个活动还是挺有意思，随着一声天黑请闭眼，大家开始蠕动，我最开始考虑的问题是会不会摔倒，然后想到如何去其他人协作，然后考虑如果完成最后的结果。整个会场花了11分钟完成了整个游戏。然后是大家的分享交流，最赞同的是这样一段话: 闭眼后，部分人站着不同，有的开始积极交流，然后形成了一些各自的小圈子，有的圈子认识到自己的问题，去寻找这大圈子，有的小圈子则认为自己就是大圈子，不愿意加入别人的圈子.. 这个场景可能和一些技术团队比较类似吧，如何打破壁垒去进步和成长是每个团队或者公司都会遇到的问题。
接下来是分会场，三个分会场面对了不同的方向，大概是职场、创业、开发。我去了开发的那边，第一个是个code dojo,通过数字打印英文的sample，以TDD+结对的方式让大家参与进来。。我旁边除了蒋大神，还有个西科大的女同学，这让我一阵小激动，他们一群同学一早从绵阳过来，学生时代真是牛气哄哄激情四射啊。在小朋友面前，好多数字的英文写不来啊..万万没想到她写不来JAVA，在旁边还能一个劲的出主意，取余再加减巴拉巴拉，我感觉亚历山大，哈哈..不过，不要在意这些细节，这不重要，最后还是完成了简单的DEMO，通过TDD的迭代方式的确是很好的，这里重点是迭代。在这个分场后来的交流阶段，我提出了个关于测试用例的管理和数据组织问题，得到一个大哥的指导，也解决了自己一个一直踌躇的问题，最后的结论是，单元测试本身的数据已经由自己来管理，而不出现交叉，单元测试相互之前也不应该出现耦合的情况，这样单元测试是可控、可丢弃可完善和改进的，当然在不熟练的情况下，这样的单元测试需要花费一定的时间去做，如果开发时间是1的话，加上单元测试的时间就是2-2.5了。
第二个小分场是一个关于持续集成问题的，是叠拓的同行做了演示，具体的内容就是基于JIRA+BamBoo以及Stash的持续集成流程，看了演示后还是了解不少，新版的JIRA在和Git的配合下很好的完成分支创建到开发、review、git合并的处理..后面的bamboo通过tomcat manager或者类似的shell脚本可以很好的完成部署，据说还能通过一些标识，将版本部署到多个环境。和目前自己团队使用的持续集成环境来比，提供了更少的人工干预支持和友好的操作界面..还是不错的，不过这些货是按人数收费的吧，所以有点坑。
最后，通过今天的活动，收获还是不小，对于我这个半宅男来说，和大家交流是件愉快的事情，明确了几点信息
·敏捷开发的水很深，非21天就能搞定
·目前开发人员需要承担测试角色，完成自身模块更加专业的测试，既单元测试。
·单元测试需要独立
·代码评审团队由团队的高级开发人员来担任，但频繁代码的评审会议可能会阻碍敏捷。 能否进行代码评审也应作为高级开发人员的考核之一。
·持续继承部署流程化、智能化会被越来越多的团队实现。