We’re now the 3rd times hosting and facilitating the Global Day of Coderetreat in Hangzhou, China. Compared with Jim Hurne coordinating the globally events, be frankly, our work is easier. Yes, it’s easier, but I do not think it’s not important. It always request the host and facilitator spends much more effort to prepare and continuiously improve. Personally, beside those Global Day of Coderetreat (GDCR in short), we still spended much time hosting and facilitating such like coding dojo, coding rally etc. which help programmer to practice their software design, coding skill and agile engineering practices. Here I’d like to share what I learned from coderetreat.

Prepare as earlier as possible

Even coderetreat’s organizing is lightweight compares what’s conference. But prepare as earler as possible makes sense. What’re you have to prepare:

• Keep the connection with coderetreat.org, and keep you can touch the global organizer via email, if you hosted the GDCR in last year, you mail will be record in historial host naming lsit. So that, you can received first hand news from coderetreat community, about the schedule, host and faclitate guideline, experience sharing, some issues discussion. This is great opportunity to learn from expereienced person, also it’s great time to build your reputation.

• Join regional GDCR community. Regional community can help you prepare your event better, most of members in regional community are expert or activator in they lived city, they are more experienced in community hosting and facilitating, they can give you suggestions, their lesson and learn is indirect knowladge to you. You can copy their way of working, even share the local sponsors.

• Look for the sponsors. GDCR is day-long event, and programmer deserved free lunch and snack, so we need sponsor supply the money and place. As an activity organizor, you can help the sponsor’s branding. And involve more people from their company to join the community. Another way to find the money is connecting with other communities who has activity budget. For me, that’s always not a problem, since we can align our activity with our belonged company’s business value, boss buying our idea, and sponsor it.

• Prepare the topic and constraits. As we know, the problem topic is always Game of Life, I’m not going to explain why we choose Game of Life in this post. We haven’t changed the problem topic in our three years GDCR, personally think the problem topic is not a problem since most of participants are different in different year, instead, we have to consider the contraits more carefully, and we think that, the most excited part is the constraints adding.

• Facility. Prepare some funny video such like “Delete your code, Yes, You” and the movie clip of game of life, some different color post-it for the retrospective of each session, check the network connecting works well with other cities. If there is no official video channel providing, establish some hangout will be fine.

• Advertise the event. twitter, facebook, meetup, WeChat, Weibo, and G+ such social network will be good place to market the event to audience. eventbrite, google form can be good tool for event enroll. Don’t forget do some pre-survey to know the participants knowladge and skill level clearly.

Facilitating

There is a video sharing for the GDCR facilitating. And thanks for GDCR global organizors, they supply the the guideline for your hosting and facilitating. In the first year we hosted and facilitated the event, we strictly follow the guideline and rules what the session shall be in 45 minutes, and then remove all code in next session. But we found that, there might be some problems for example, since all implementation has been removed, some programmer lack the sense of achievement, and each session’s restrospetive cost a lot of time. So in this year, in the first two sessions, we let the programmers try their best to finish the basic implementation. And from the third session, we strictly require them to remove the source code, and we give a time-box for each person to share the feeling and learn and strictly to follow the rules. We also change some constraints, to practice our engineers OO design, and also give some funny contraints making a happy event.

After each session, we facilitator will give brief introduction about why we add the constraints, and what’s the essential behind the constraints, and how do we adapt good practice in daily work, such sharing will help people learn more from just experiened.

Summary and retrospective

After finish the sessions, we will gather all programmers, and do a quick retrospective of this event, 10 persons in a group, and select an A0 size paper, to draw 3 circle in the same center. give them each person 3 green color post-it, and answer this question: What’s your feeling about this event, write 3? And let them write down and paste on the outside circle, and share the feeling each other in they belonged group. and then, every one has 2 yellow color post-it, and write down the answer for this question: What’s you learned from event, write 2? and paste the answer around the middle circle, and then share each other. At last, every one has 1 red color post-it, and write down the answer for this question: What’s you next action which is related this topic, write 1? And paste the answer around the inner side circle.

As a host and facilitator, we can clearly get the feedback from their sharing, for example, if the feeling is boring, there might be some facilitating problem, LOL.

Have a nice summary will help us to record what we did, like now, write down a post, and create a picture album, that’s good choice. Have a fun.

-EOF-

今天是”双11”，据说这个词已经被注册了商标，不知道这里用会不会侵权啊。这样的日子里，连上班早高峰都不堵车了，传说都是昨晚伤得，大家起不了早。这不，我的搭档都伤得要去买膏方了。

在这样的成双成对的日子里，让我想到了软件开发的结对。(这个引子太牵强了，LOL)在讨论结对开发的时候，我们很容易想到XP中提到的navigator与driver的形式的结对开发。那么结对开发还有其他形式吗？答案是有的。

我们认为，结对开发是用于团队的ramp up的利器之一。团队建立，先分析人，结对开发是一种加强团队成员彼此了解的好机会，这是一种交换学习的形式，设想一下，团队里有7位同事，如果大家都曾彼此结对工作过，大家彼此的了解会更深入，哪些人擅长什么都很清楚。

以老带新的形式进行结对，或者以交换学习新知识和新技能的需要进行结对。需要注意的是，结对的时候，两个人的能力水平差距不宜过大，这样会影响结对工作的效果。多鼓励团队成员自发结对工作，当然，做为经理，可以对结对进行调整，如job rotation的形式等等，多创造一些结对工作的机会。如两个程序员一起结对，程序员和测试人员结对，tutor跟newcomer结对等等。

我们会问，如果大家结对，有没有什么形式来保证大家在开发过程中不会走错路？其实这个问题跟结不结对没有关系，一般来说，架构师会做一个全局的考虑来避免走错路，另外，在daily meeting上也可以通过对任务的更新来发现并避免走错路，每次会议，都问一句能力比较强的同事：有没有什么建议或不同意见？

采用这样的结对方式，可以有效地提高团队的能力，达到团队能力的最优，我们需要的是团队能力的最优，而不是单个个体的最优。如果我们在结对的过程中发现团队的合作或配比不是最优，我们可以打乱团队，重新洗牌。

能不能做到结对开发，这是文化的问题。我们可以通过对能力比较强的同事设定这样的KPI来解决，如，考核该员工结对培养了多少人，另外做360度feedback来考核员工，他所曾经结对过的同事给他反馈。所以我们建议，针对刚成立起来的团队，必须做到100%的结对工作，越是关键，越是困难时期，越是要快速的将团队整体的实力进行提升，而提升的过程必须是learning through work，而结对工作就是一个比较好的手段。我们可以给团队建立一个结对工作图，只有之间有结对工作，将两者之间用线连接起来，以此来跟踪团队结对工作情况。

是不是所有工作都应该结对？很显然，不是，结对工作的目的如果是想做团队的能力培养，那么结对的工作内容应该是那些可以让一部分能力强的员工帮助这一块比较弱的员工的工作，如对某个业务模块的编程，测试用例的编写等等，而那些适合独立思考的任务，则给员工留足独立思考的空间吧。所以，员工之间可以达成一个agreement，比如，每天下午的13:00 - 16:00之间会用于pair work，而其他的时间留给各自吧。

为了保证团队建设的可持续性，我们建议直线经理的关注点做如下分配，50%的时间用于团队人员相关事务，30%用于项目相关的事务，而20%的时间则用于hands on的团队工作，如跟团队成员以结对的形式进行工作。这样的直线经理，才能对团队的动态进行洞悉。

其实结对工作可以让参与者完全投入，并能产生积极的工作压力，从这个角度来说，是有助于工作效率的提升，谁也不知道一个看似独自努力工作的人是不是在努力工作，但是，两个在一起努力工作的人肯定是在努力工作。当然，在这样的过程中，做为直线经理，需要关注并影响团队的负面情绪。做为结对开发的推广，我们可能通过KPI考核方式的改变，如考核合作这一块，鼓励尝试使用好的方法，双向推进，真下而上去educate你的经理，自上而上的要求你的团队成员。

通过结对开发，我们可以有效保证产品的质量和开发效率的基础上，做好团队整体能力的提升。

-EOF-

其实，我有自知之明，我并不是最合适回答这个问题的人，因为现在大师有很多，不管是李奎也好，李鬼也罢，反正就是很多。也因为真假莫辩的原因，搞得圈里圈外各种叽叽喳喳。这不，要想在圈里圈外出个名什么的，要么旗帜鲜时的挺个流派，或者倒个敏捷，或挺或倒，一定要言辞凿凿，越激烈，越极端，就越容易博得点击量，当然，这是有风险的，要么名声大振，要么声誉扫地。其实我是挺偑服那些人的，多有勇气啊，而我就不行，只能闷头干活，不敢过多言语，为什么？怕讲错啊，万一被哪个神经病缠上，就我这压力承受能力，还不直接被K.O了。况且，就我这水平，能让自己搞明白就已经不错了。

可是，可是…由于工作的原因，最近我常常遇到不明真相的群众，直呼我张老师，然后请教诸这般那般。其实叫我张老师，我应得也自然，因为曾经当过老师，也乐得学生这么叫我。就我个人而言，我更愿意广义意义上就敏捷这个基础上就事论事。

讨论敏捷，肯定会提到敏捷宣言等等各种资料、引用、权威著作等等。但是这里水太深，一般人一时半会儿还真理解不了。那么，我想从我个人的理解试着说说，如果读者朋友觉得我说错了，也请给个comments，提醒一下，当然以后就称我为编程教练好了，如果你赞同的话，那以后就叫我为敏捷教练好了.

我觉得在敏捷里一个比较重要的概念就是Inspect&Adapt，检视并适应。如果理解了这个概念，顺着往下理解，就很容易了。这里举个例子，有汽车驾驶经验的人一般都知道，从一个驾驶新手到熟练驾驶这个周期不会太长，一般每天上下班开车的话，一两个月就够了。作为在全国第二拥堵城市开车的我来说，从新手，到自认为老手，也就不到两个月，为什么会这么快呢？前两个月还战战兢兢，过两个月就敢跟别人卡车位，原因出在上班路上有太多的锻炼机会，从家里到单位，红绿灯几十个，十字路口N个，加上咱们国家特有的着急文化，路上状况百出，极其复杂，这样，给了我们学习足够的频度进行锻炼。另一个原因，汽车驾驶中，从做出每一个驾驶动作，到驾驶员获得反馈时间非常短，这样一个高频度和快反馈让我们很快获得了汽车驾驶能力的提升，因为，我们在驾驶过程中不停地做Inspect和Adapt。另一个例子是驾驶海上货轮，学习成本明显比汽车要高出许多，加上海上也没见多少红绿灯啊，频率低，货轮入港时的转舵，反馈周期长，也些原因决定了学习轮船驾驶要比汽车驾驶困难许多。由于不确定性因素，根据不断变化的情况，对反馈进行检视，然后对下一步的行动做出调整，以适应后续发展，快速的反馈减少我们应对单一反馈周期里的成本。应对不断变化的不确定因素，反馈是获得改进的唯一方式，这就不难理解”别人给你feedback是对你好”这句话了。

以此，我们对应软件开发中，软件开发常常碰到的问题是不确定因素很多，客户随时可能改变需求，这有点像开车，路况总是处在变化中，软件研发团队提交产品给客户，而客户将反馈给研发团队。如果想有效地应对来自客户的变化，那么保持一定频率的反馈及快速的反馈时间将有助于及时让团队做出调整，这样，不断的调整改善，对团队而言，就是一个持续改善的过程。我们试着问，要不断从客户那边获得反馈，前提就是要可持续地提交产品给客户，就这引入了Continuous Delivery的概念（我们不再这里深入更多细节），要做好Continuous Delivery，我们必须做好持续集成Continuous Integration，要做到持续集成，我们可以通过ATDD保证需求是可迭代的持续验证，并且同时做好测试自动化。要做好持续集成，咱们得做好持续开发编译，要做好持续开发编译，咱们都做好TDD，Pairing… 随着一步步向下挖掘，我们发现，可以将很多工程实践，放到里头，如果想保证这些事情能够顺利地做好，我们定义了不同的角色，不同的check list，backlog，这样就很容易地顺着这个思路去自圆其说了，:p。当然，这时还一个概念就是迭代周期，迭代周期就是开发团队用于Inspect & Adapt的节奏。迭代周期多长合适呢？

从产品开发的这条线走，如上所述。那么要开发产品，团队很重要，从团队角度又可以引申到哪些概念呢？如团队建设要做到Continuous Improvement，那么我们是不是得做好Retrospective，然后是Daily Meeting， working agreement …

把这些想通了，再去顺着想别的概念就容易多了。当然，这不是敏捷的全部，否则做个大师就太容易了。这里只是想写个引子，帮助大家站在自己的角度来思考问题，希望能对大家有所帮助。对了，写到这里，我是不是得问几个问题：

1. 敏捷的开发方式好，还是传统瀑布模型好， 为什么？
2. 如何在硬件研发中使用敏捷，为什么？
3. Lean与看板是什么关系，为什么？
4. Scrum好，还是Kanban好，为什么？
5. 极限编程又是什么东西，为什么？
6. 自组织是敏捷的前提还是结果，为什么？

是不是觉得这些问题经常遇见，那为什么呢？习惯问为什么，并顺着往下想，下一篇博客你来写。

注：文中图片是用keynote画的，只是个草图，如果有兴趣，大家帮忙给规整规整

祝好