程序员眼中的敏捷

　　我在上周参加了敏捷之旅(北京站)的活动。以前参加过各种大大小小的培训，企业内训，关于敏捷的一些认证。但是参加类似这种非盈利性的交流会还是第一次。以下对本次活动进行回顾：

　　第一部分：流水账

　　先说一下此行的收获。

　　1、第二次与段念见面，第一次见他大约是两年前，那是他还在谷歌中国，负责测试团队，当时记得当时他给我们讲的是“敏捷测试——简单而可行”。

　　这次见面是段老师以豆瓣高级工程总监的身份来跟大家分享豆瓣的敏捷的实践。我一直很欣赏段老师，这次他带来的“生长出来的敏捷”，果然没有令我失望。

　　2、在会场积极提问提，得到了一本“风骚”的不行的书。。。

　　3、早上免费的麦叔叔套餐、中午吉野家套餐。。。

　　4、下午见到了@乔梁 ，我的敏捷生涯，跟此人有不解的渊源，他翻译的《持续交付》，我读了不知道多少遍，他的那个持续交付的网站，也一直伴随着我成长。

　　5、在 Open Space 环节与段老师一起完成了show time 环节，虽然我在做这个环节有点不自信，但是我还是大胆的去尝试了。

　　6、最最激动人心的是最后的抽奖环节。工作5年左右，每次年会都是仅仅被“阳光普照”，这次，我终于登上了领奖台。。。200元现金“大奖”(由于我是现场报名的，报名费150)……这使我不仅在精神上盈利了，物质上也有盈利……

　　第二部分：关于Open Space分享主题的思考和总结

　　流水账记录完毕，下面进入正题：

　　@Shining 在会议结束时，跟我讲，要我把open space环节整理一下，现在开始做作业。

　　话题#1：“程序员眼中的敏捷是什么样子的”?

　　在做这个话题的时候，段念提出了两个问题

　　你希望在敏捷中得到什么?

　　你希望敏捷的环境是什么样的?

　　由于参加讨论的人员组成并不是单一的开发人员，还有敏捷教练、产品经理，所以讨论出的结果比较有意思，简单的来说：

　　开发人员更关心，自身能不能在敏捷开发中更开心，学到更多的知识等个人问题

　　而敏捷教练、产品经理，更关心的是，团队问题

　　这令我产生了一个想法，在温饱问题没解决的情况下，很难让大家到一种小康水平，敏捷团队建设，应该以人为本，最大限度的满足团队个体需求，才是王道。

　　由于大家的想法不统一，我们把讨论的话题做了进一步的引申，就有了下面的来自于豆瓣的一种文化“吐糟”。

　　话题#2：“吐糟大会”

　　在大会上，我们分别对三种角色进行“吐糟”：

　　做产品的

　　做开发的

　　敏捷教练

　　在吐糟大会上，大家相互吐糟，有的人进行自我吐糟。会议中，大家并没有因为自己的问题被指出而感到尴尬，而是思考。其实在一天的敏捷之旅中，大家多多少少的体会到了一些敏捷的思想。大家有勇气面对自己的错误，大家愿意把问题透明化，大家愿意改进，我看到了敏捷的种子，已经埋入到了大家的心里。当然吐糟的目的并不是仅仅过过嘴瘾，就像乔梁会上说的一句话“Scrum并不能解决问题，它仅仅能发现问题”，但是由于时间限制，我们并没来得及能把大家的“吐糟”解决。其实会议到此结束已经小有效果了，因为团队中的不同角色相互沟通了，我一直相信，一个真正的敏捷团队是有能力“自调整”的，我说的“自调整”指的是团队一起发现了一些问题，这些问题，会在没有做要求或者找到具体对策的情况下，在不知不觉的情况下不复存在。当然，这些是需要长时间的磨合才能办到的。在团队没有到达那种理想情况下，我还是建议能做出一些相应的对策。比如，如果吐糟大会还有时间，我建议大家能做一份“工作协议”，让不同的角色各抒己见，相互监督，自我约束。

　　那么，工作协议是什么呢?我这里来抛个砖，下面就是我所带的一个团队的一份协议(工作协议随时间推移应该是会有调整的)。

　　最后总结一下，敏捷很简单，因为它仅仅是 “沟通，简单，反馈，勇气，尊重”的体现，同时敏捷也很不简单，因为她要求大家做到“沟通，简单，反馈，勇气，尊重”。

　　敏捷，我们在路上。

原文转自：http://www.ltesting.net