一、工作

2011，我离开了工作5年半的公司ThoughtWorks。我最年轻的时光24-29岁都是在ThoughtWorks度过。在此期间，工作去过的城市有：西安、厦门、悉尼、旧金山、深圳、伦敦、广州、北京等。我以前和朋友聊天，总结在ThoughtWorks有三件事情必须要做：1、开发。在TW，很多国外同事有非常丰富的软件设计、开发经验，公司也有专业和系统的设计培训。所以，要学会真正软件开发和设计，同时能够Coach自己的团队。2、国外工作。TW是一家为数不多没有完全本地化的外企（至少以前是这样），有很多去国工作的机会，去国外工作半年以上，是一段非常酷的人生体验，特别是和很多国外大牛们一起共事。3、咨询。没有做过敏捷咨询的Twer，不是一个真正的Twer。

以前，有个好朋友想找我去一起去创业，我拒绝了。我的理由是：我觉得自己是一个“挖井”的人。刚毕业之后，我在一家公司工作从来不超过1年，虽然学到了很多东西，但是不够深入，我讨厌这中状态，所以我下定决心，不要再做一个“挖井”的人。我必须要挖一口井，直到挖到泉水才会做新的打算。现在，这三件事情我都已经完全胜任。同时，厌倦了整天出差，为别人做项目的生活（为她人做嫁衣裳）。于是，下定决心离开，找一个做产品的公司，验证自己的能力和实现自己的想法。

我先去百度工作了三个星期，后来就去了腾讯──搜搜。在这里不想对百度做任何评论，它是一家很优秀的公司，但不是我喜欢的公司。去腾讯入职第一天，我能感觉到这是一家我喜欢的公司文化，“物以类聚，人以群分”。这时，职业生涯开始了一个转变。在腾讯，负责搜索部门的项目管理工作，堕落的不再写代码了。在腾讯的这大半年，最大的变化就是完全以管理的视角来解读软件这个行业，来思考敏捷开发方法。我的演讲《敏捷项目管理──如何改变软件思维模式》就是这方面的总结。

在腾讯，带了一支7个人的PM团队，经历了一个小小酸甜苦辣的适应期。欣慰的是，团队在项目中磨练和快速成长，现在慢慢的是一支很强的队伍了。2012，我们有明确的目标和方向，可以在公司一展伸手。我的理想是把团队打造成为国内互联网公司中最强的一支项目管理队伍！

二、知识传播和分享

2011，做过很多的分享和培训。擅长的领域从技术开始转变到管理。培训内容，也从敏捷方法方面转变到能力提升方面。下面简单的做个盘点：

1. 为新员工定制的培训《腾讯–搜搜优秀开发人员的十个习惯》。是这些年我做开发的经验总结。在所有新员工的培训课程中，得分第一。

2. 在2011 scrum gathering上海的演讲《进度的压力之下如何使用敏捷》。这是一个自己带项目的真实故事，一个遗留系统，在进度压力之下，如果搞定客户，如何快速上线，如何使用敏捷方法等。

3. 敏捷中国2011的演讲《如果有效的提升团队的开发和设计能力》。这是对我咨询的时候，提升客户员工软件开发和设计能力的总结。敏捷开发实践分论坛听众反馈最好的一场演讲。

4. 2011敏捷之旅，我的分享是《敏捷项目管理──如何改变软件思维模式》。里面是我在腾讯搜搜工作之后，对敏捷的新思考和观点。大家对演讲反馈也是杠杠的。

5. 公司部门管理沙龙的分享《我们如何解决问题》，这是一个关于如何系统思考的分享。

6. 腾讯TAM训练营，我的新课程《探索需求》，是对软件需求表达能力的总结和提炼。

7. 还有一个重大的事件就是和北航计算机学院做了一个合作，为北航带了一门《敏捷工程实践课》。一共10次课，每次课程3个课时，周末授课。也就是说几乎连续10周我都是一个没有周末的人。呵呵，现在想想还有点小心酸。课程有100多学生，我采用的是苏格拉底式教学，其中每次课都有现场的练习、讨论，甚至是小游戏。有时间可以把授课过程单独的总结一下。

三、生活和爱情

结婚，这是我2011年发生的最重大的一件事件。我认识一个女孩，我们相知相爱并且结婚。没有求婚，也没有任何的婚礼仪式，我们就这样做着一个小蹦蹦，去了民政局，领了结婚证。我还记得那天领证之后，做地铁从通州去东直门上班，一路还很恍惚，这就算是结婚了。当然，这半年婚后的生活还是小幸福的。感谢老婆，每天下班给我做晚饭，让我的体重从56公斤（自从大学毕业之后一直是这样的体重，从没有变过）变成了60公斤。

还有就是把完成了房屋的装修。2011的夏天都是在装修中渡过，周末基本上都是在跑建材市场，其中的体会，参与过装修过的朋友们都会懂的。以前，亮亮和我说：没有装修过的男人，不是真正的男人。那么现在我是真正的男人了！据说很多小俩口在装修的时候都会吵架，甚至闹离婚。我们结婚到现在几乎没有吵过架，有几次不开心都是因为她纠结于我以前的一些情史。哎，以前的邮件都没有删除掉掉，结果被老婆查到了。年轻的朋友，可以以此为戒，及时的毁灭证据，比如：邮件、图片、视频等。。。。。哈哈

附录

这是我2011一些演讲视频或录音：

• 《腾讯──搜搜优秀开发人员的十个习惯》 http://www.howzhi.com/course/tenhabits/lesson/1119
• 2011敏捷之旅北京站演讲：《敏捷项目管理──如何改变软件思维模式》音频 http://www.tudou.com/programs/view/1R78GZWuQKc/?fr=1

本人一向不喜欢阅读比砖头厚的书。但是，这几周每天早上在班车上或晚上回家吃过晚饭，都迫不及待的拿起《Steve Jobs》这本比转头还厚的书。刚开始看的时候，觉得不过就是另一本励志自传而已。可是，当给我看到乔布斯1997回归苹果之后，凭借自己对更好产品的偏执追求，一步一步把苹果公司从市值不到40亿美元，一直做到2011的3000多亿美元，14年的时间上涨了70多倍。这14年，乔布斯把自己所有的热情、心血和生命，都献给了自己热爱的产品和公司。

有人说成功是偶然的，乔布斯的成功是赶上一个好的时代，而我却说：成功是必然的，只是他在不同的时代，成功的方式不一样。我从软件项目管理的角度，思考和总结了乔布斯成功的八个要点，和各位同事共勉：

一、 用心——激情和想法

乔布斯的激情是要打造一家可以在世的公司，这家公司的人动力十足的创造伟大的产品，其他的一切都是第二位的。因为这样的激情，乔布斯会用心体验产品端到端的每一个细节：产品的硬件，外形，软件，零售店的装修和用户体验，广告，产品包装，甚至产品发布会的一个灯光细节，等等，每一个地方他都花费心思琢磨。2009年，乔布斯癌症复发，在医院做手术接受治疗。同事来病房向他汇报进展，他就情绪高涨，会花一个小时讨论新一代iPhone的命名——他们商定叫iPhone 3GS——以及“GS”两个字母的字号和字体，包括是否应该大写和是否斜体。

团队的成员是否用心，是一个项目成功的根本。你可以不用像乔布斯那样把所有心血甚至生命投入到项目和公司。但是，只要每天在班车上思考着如何简化业务流程，如何更好的用户体验；刷牙和睡觉的时候，想着如何优化一段代码，如何重现一个Bug。如果你用心工作，把心思都放在项目上，那么你就已经走在通往成功的路上。

二、 清晰的管理模型

乔布斯1997年回归苹果，大刀阔斧地砍掉了各种不同型号的产品，很快砍掉了70%的产品。他回归的第一年，裁掉3000多员工。在产品战略会议上，他在白板上画了一个四格表：消费级和专业级，台式和便携，他们的工作就是做这四个伟大的产品。

项目经理的主要职责是“Plan Good”。计划并不是Excel里面的任务和时间列表，真正的计划是想清楚项目的目标和方向，同时能把目标进行工作分解，然后让不同的成员配合完成。我们要求团队要有明确的：半年目标，季度目标，月度目标和周目标。项目管理的一个重要任务是范围的管理。一个团队要成功，首先就要必须要专注。如果只是追求数量和进度，那么结果就是做出了很多的山寨货，并且会成为自己的库存和累赘负担。

三、 开放的产品文化

读这本书，我最喜欢的一句话就是“不是杰作，就是狗屎”。很多人都知道乔布斯的缺点：对人苛刻，经常骂人，脾气暴躁。我到不觉得这是缺点，他把自己所有的心血都投入到了公司和产品，对大家期望很高，他发脾气是因为他很在意（当然，表达方式可以更友好，如果那样他也就不是乔布斯了），愿意表达自己真实的感受和情绪。

他自己也在传记里面说过：“我不认为我对别人很残暴，但如果谁把什么事搞砸了，我会当面跟他说。诚实，是我的责任。我们相互诚实到残酷的地方，任何人可以说我是一坨狗屎，我也可以这样说他们”。

Nice并不是开放的文化。如果有不同的观点，但是因为照顾对方的感受，为了表示nice而不去指出别人的错误，这才是失败。开放的产品文化，允许任何人，在任何时间和地点，谈及产品的任何好与坏。可以在会议室里面，激励的争论，互相吼叫，只要确保大家是讨论具体的事情，而不是相互指责。

四、 反馈作用

苹果有一个神秘的设计工作室。伟大产品的设计都是在这里完成的。房间有几台铸型机，可以把电脑屏幕上的设计制成发泡材料模型，可以喷漆，让模型看起来更逼真。乔布斯有时间就会去工作室看一看。当时设计iPhone的时候，乔布斯会搬一个凳子做在那里，把玩桌子上不同的模型，用手去感受他们，评价哪一个才是他最喜欢的。他不喜欢看复杂的图纸，他需要亲眼见到并感受这些模型。这样才能得出正确的反馈。

软件开发，更像是在打一个活靶。目标是一个动态的过程，如果要能够打重靶心，必须及时从各个层次获得反馈，调整自己的方向和步伐。项目开发过程中的迭代计划游戏，灰度上线，界面原型，功能演示，自测，回顾会议，甚至是单元测试，都是在进行反馈。是否能驾驭自如一个项目，关键是看团队的反馈和调整能力的强与弱。

五、 简约设计

iPod项目开始，乔布斯每天都投入其中。他最主要的要求就是：“简化！”他会浏览用户界面的每一个页面，并且会作严格的测试：如果要找某一首歌或者某项功能，按键次数不能超过3次，而且按键的过程要自然。如果他觉得导航不清楚，或者需要按3次上他就会非常生气。乔布斯不喜欢幻灯片，因为他觉得：如果你一定要用幻灯片来讲，那说明你不知道自己想讲什么。

简洁不仅仅是视觉上的，也不仅仅是吧杂乱无章的东西变少或者抹掉，而是要挖掘复杂性的深度。要想获得简洁，你就必须挖得足够深。打个比方，如果你是为了在产品上不装螺丝钉，也许最后可能会制造一个极其繁琐复杂的东西，这不是简洁。真正的简洁是理解产品的每一个部分，以及它是如何制造的。你必须把握产品的精髓，理解它的本质，从而判断出哪些部分的部件是可以拿掉的。

现在互联网应用，技术早已不再是瓶颈。产品开发其实是一个解决问题和复杂度的过程。这是为什么要做软件的设计，为什么要做自动化测试，为什么要做自动化的构建、部署等。任何一个团队都可以做一个产品，但优秀团队做出的产品，一定是简约有力──有内而外。

六、 不要听客户的

乔布斯开发产品时没有做任何的市场调研。因为他觉得，有时人们不知道自己想要什么，直到你把它摆在他们的面前。福田曾说过：“如果我最初问消费者他们想要什么，他们应该是会告诉我‘要一匹更快的马’”。所以乔布斯的理念是：我们的责任是提前一步搞清楚用户将来想要什么。

我非常认同乔布斯的观点，不要听客户的。如果要开发出一个客户满意的产品，一定要想的比客户深，比客户远。用心思做好产品，能打动自己的，也一定能打动客户（当然，先要确保自己要有更高的品味）。

七、 跨部门合作

乔布斯带领苹果，从计算机公司进军到到数字领域。发布了数字产品iPod，后来又开创了在线出售音乐的服务。一致处于数字领域领先地位的Sony，这时却为苹果提供了一个典型的反面教材：他们的消费电子部门能制造出时髦的产品;音乐部门也签约了当红的艺人。但是每一个部门都在竭力保护自己的利益，它的硬件部门、软件部门以及内容部门永远无法统一步调，所以整个公司无法合作推出端到端的服务。

乔布斯没有把苹果公司分割成多个自主的分支，他紧密的控制着他所有的团队，并促使他们作为一个团结而灵活的整体一起工作，全公司只有一条“损底线”。乔布斯的一个商业原则是：永远不要害怕内部相残。他说：“与其被别人取代，不如自己取代自己”。所以，即使iPhone的出现会蚕食iPod的销售，或者iPad影响了笔记本电脑的销售，都没有阻碍他的想法。

从项目管理角度看，索尼的反面教材就好比是模块团队（甚至是一个系统的前台和后台团队）。乔布斯走的是功能团队的路线。现在公司很多的抱怨都是来自各个团队或者部门的配合方面，一个项目/产品应该是一个完整的端到端的交付。模块团队，或者前后台的分割让都是在削弱公司的战斗力。

八、 真正的敏捷

乔布斯刚接管苹果的时候，产品的库存期超过两个月，库存周期对利润造成5亿美元的威胁。到1998年初，乔布斯把两个月库存缩短到一个月。后来雇佣了熟悉精益制造蒂姆.库克（康柏计算机公司的采购和供应链经理），同年9月底，库克把库存期缩短到6天，下一年的9月，这个数字已经达到了惊人的2天──有时，仅仅是15个小时。另外，库克还把苹果计算机的生产周期从4个月减少到2个月。

IT公司的库存就是没有上线使用的代码。敏捷并不是庸俗的快。敏捷是一种能力──消除所有不必要的冗余和浪费。敏捷是通过提升组织和团队的能力，让过程和测试完全自动化，在保证质量的前提下，减少软件产品的生命周期。

总结

这本书让我最有感触的一句话是：“不是杰作，就是狗屎”。我会用这一句话来要求自己和团队，在自己的团队中建立开放的产品和工作文化氛围。任何人都可以走过来，评论我的工作是狗屎，只要他能给出Reasonable的理由。当然，我也可以用这样的话来评论他们！！

1. 敏捷是整个团队围绕着圆桌一起工作，没有任何沟通障碍
2. 敏捷是正确理解和挖掘需求，按照业务进行分解，并且有优先级的排列
3. 敏捷是所有的需求和开发任务都全部贴在墙上，完全可视化管理。需求和任务的细节部分统一在Wiki上记录、维护和整理
4. 敏捷是每个人都可以自由去墙上领取工作，大家只有一个目标，那就是把项目做好
5. 敏捷是业务被合理的建模，同时代码被很好的设计
6. 敏捷是代码每个方法在10行左右，能够表达业务意图，没有重复，遵循开闭原则，修改尽可能在一个地方
7. 敏捷是代码集体所有制，每天早上做Code Review，大家都有能力修改所有的功能模块
8. 敏捷是大部分功能都有自动化测试保障，如果测试失败，那么必须第一优先级修复
9. 敏捷是系统界面简洁，好的交互设计，稳定可靠，良好的性能
10. 敏捷是自动化编译、打包、部署、升级
11. 敏捷是不断交付可用的软件，周期从几周到几个月不等，越快越好
12. 敏捷是团队每周一次learning session，大家追求卓越，互相学习提高，对技术精益求精，对设计不断完善
13. 敏捷是大家肩并肩地工作，互相尊重、信任、欣赏和协作

1. 从第一天开始就要告诉客户，如果要做好一个项目一定需要你们的配合、支持和反馈，否则项目一定会失败

2. 有规律的给客户做项目Show case，频率最好保证在1-3周左右

3. 如果想要引导客户，首先团队要有自己的主见。要主动思考和琢磨，想的比客户远，思考的比客户深，看的比客户全

4. 每次客户开会的时候，需要整理会议记录。讨论问题的时候，尽可能在现场决策。如果现场无法决策的问题，指定一个具体的Owner

5. 团队需要维护一份需求列表和Issue列表。对每一项需要有来源、优先级和Esitmate

6. 实体的卡片墙是效率最高的项目管理工具，但还是需要维护一套电子版的需求和Issue列表

7. 当团队规模大了，或者有分布开发团队的时候，物理墙也许无法满足要求了，这时候需要选择Mingle之类的工具

8. 每次迭代或发布，一定要制定一个目标。比如：第一个次发布的目标是：销售经理职位可以在线提交简历和考试。

9. Share responsibility，让每个成员Take一部分责任，让他们感受到自己在团队中的价值，这才是最重要的激励

10. Share responsibility的前提是Share information。把项目邮件抄送所有的成员，和大家分享每一个项目的决定。

11. Iteration 0是有必要的，让团队搭建开发、测试的框架和环境，熟悉技术和业务，做一些开发和Spike

12. 项目开始的2-4周会比较紧张，因为这时候大家对技术和业务都不熟悉，必须要很多额外的付出才能保证团队有一定生产率

13. 开发节奏很重要，一般原则是先紧后松。当然，如果团队每个人都很牛，确实可以一直很从容，但这样的团队也是非常昂贵的。

14. 回顾会议是很有效的Team Building，让每个人敞开心扉的交流。一般2周左右举行一次

15. 成功的项目，一定要有5顶帽子：客户的帽子、PM的帽子、Tech Leader的帽子、QA的帽子、公司的帽子。每顶帽子对项目的成功都有各自的定义，他们互相牵制和影响，配合得当，项目就会很健康并且容易成功

My mind to your mind. My thoughts to your thoughts…

– Mr. Spock

什么是结对辅导

在前面的两篇敏捷咨询工具箱中，我分享了如何做读书写代码活动和OO训练营。认真的做好这两项活动之后，团队的开发设计能力会提升一个台阶。对于有经验和有能力的团队，他们可以直接把这些技术和思想直接应用到项目中。但有一些团队还需要进一步的跟进。那我们如何进一步的跟进，保证大家能把这些技术应用到项目中呢？

这 对一个敏捷咨询顾问是一个很大的挑战。在很多人眼里，顾问就是那些能说会道，把事情说得天花乱坠，但都是只会纸上谈兵，站着说话不腰疼，为团队带来麻烦， 却不解决实际问题的人。我承认，顾问的好名声就是曾经被这样的人给败坏了。那顾问如何才能深入团队，解决他们的真正问题呢？答案是把顾问放到一个具体的项 目团队里面，为团队成员提供结对辅导。那什么是结对辅导呢？

结对辅导来源于极限编程的一个开发实践──结对编程：
“结对编程，就是两个开发人员用一台电脑一起编程。一个人操作键盘和鼠标，充当驾驶员的角色。另一个人在旁边观察和思考，提出建设性的意见，充当着领航员的角色。同时，两个人会频繁的进行角色互换。”
我 们把这项实践运用到咨询中，我会去一个项目团队，和大家一起工作，用结对的方式对团队中不同角色的人进行辅导。我会和开发人员一起结对，指导他们如何做开 发和设计;我会和业务分析师一起结对，指导他们如何做写用户故事，如何做需求分析;我会和项目的经理一起结对，指导他们如何管理项目和团队，如何系统思 考，如何主持各种会议等等。下面分享我是如何对开发人员进行结对辅导，指导他们在真实项目中进行TDD开发和设计。

如何辅导一名主开发人员做TDD开发和设计

我在一个客户那里，结对辅导了一个主开发人员。我们一起用了三周时间，完成了一个完整的用管理功能模块，这个功能大致分为6个左右的用户故事。我们是在C语言的开发环境下，使用TDD的编程方式。下面将分享我是如何做的结对辅导。

梳理需求

在结对开发开始之前，我和她花了一天的时间，从下面几个方面对需求进行了梳理：

• 以前是否有用户管理功能，它的业务流程是什么样的？
• 为什么要做一个新的用户管理功能？
• 新的用户管理流程会是什么样的？
• 每个需求的内容是什么？它的功能范围是什么？背后的价值是什么？
• 有哪些验收用例，这些用例是否全面和具体？
• 测试人员如何验收？这些需求是否可以端到端的进行完整测试？

通过这样的提问和交流，我们完整的把这些需求梳理了一遍。同时也把遇到的一些不合理用户故事做了重新划分。

纠正错误的编程习惯

第 二天，我们开始结对编程。刚开始结对的时候，发现她已经从别的地方拷贝了一堆代码，修改了一些，可以编译通过。她想在这碓代码的基础上开发，这也是典型的 复制&粘贴式的开发方法。我们花了很长时间讨论了这个问题。复制和粘贴是邪恶重复代码产生的根源之一，这显然是错误的编程方法和习惯。可是她却习 以为常，并不觉得有什么错，按照她的话说：有现成的代码，拷贝过来修改一下有什么错。激烈的讨论之后，最终以双方的妥协和各自让步达成了一致：

• 这些代码是有价值的，它只是用来做Spike，验证一些功能是否可以实现
• 但是Spike之后这些代码需要扔掉的，作为妥协，她愿意把这些代码全部注释起来（舍不得这些破烂）
• 用TDD的方式写代码，先写测试后写代码，没有测试失败就不要写代码，重构代码除外

真正的TDD开发

我 要求她使用TDD开发即测试驱动开发。先写一个测试，运行测试失败，然后再写业务代码。可是，她上来就反对：“费那事干吗，一次把所有的测试都写完了再写 实现代码，这样岂不是更快？”。我先是无语，然后便开始说服她，告诉她这叫小步前进，就是把复杂问题分解开，从最简单问题的开始，一步一步的前进，这样开 发才有节奏，每一小步都会有反馈（测试失败，实现业务代码，测试通过），整个开发过程可控可驾驭。我苦口婆心说了半天，她还是坚持自己的意见。于是我问 她：“你为什么要一次写完所有的测试？”。她的回答让我恍然过来：“因为我想到了很多测试场景，如果没有写下来，我担心自己后面会忘掉”
啊 哈！我终于搞明白了她的顾虑。这个好办，我们拿了一张卡片，然后把想到的测试场景全部写到卡片上。实现完一个小功能，就在上面做个标记。这样在做TDD开 发的时候，就可以专注写一个测试，有了一个失败测试之后，让测试通过是压倒一切的任务。这样的开发过程很专注，思维不容易发散，任何时候想到了其它相关的 问题，就及时的纪录在卡片上，等后面再实现。

在 我的严格要求之下，她开始了TDD方法，先写一个测试再写业务代码。我的目标是把她培养出来，所以我们采取了是教练式的结对方法：我提出想法，她操作键盘 和鼠标写代码（有时候我会为她写一些测试代码）。结对也是一个引导的过程，有了一个新的测试之后，第一步是要让测试通过，这时不用去追求代码的优雅，只要 测试通过就可以了，然后我会提出代码中的坏味道，和她一起讨论，问是否有更好的方法？如何让代码更能表达业务意图？如何在同一个层次上编程等等？引导她一 步一步的进行重构。

下面这张图是一步步用TDD方式产生的用户登录功能的测试用例：

就这样，用了三周左右的时间，我们一起完成了这个功能模块的开发。三个星期的结对下来，我也有了一些心得体会。

心得体会

• 在同一个经验丰富的开发人员进行结对辅导的时候，前面会有一个挑战的磨合期。因为他们一般都积累了自己的一套成功的编程方式和习惯，这样导致他们对新的TDD开发和简单设计有抵触的情绪。这样就需要顾问一步一步的引导说教，让他们切实体会到新开发方法的好处。
• 结对辅导需要两个人紧密的协作，刚开始肯定会有一些工作方法和习惯上的冲突。如果对方不认可敏捷的开发方法时，不要一味的说教，一定要先沟通和交流，询问为什么不愿意这样做，了解清楚对方的顾虑和担忧之后，对症下药，提供一些实践解决对方的顾虑。
• 有时候我们的建议遭到拒绝，往往并不因为是建议本身的问题，而是因为我们还没有建立好信任和领导力。

犯错误是最好的学习方式

──莎伦·德雷珀

背景

我们为客户提供咨询，刚开始做了很多敏捷的实践，包括：持续集成、测试驱动、用户故事需求分析、迭代开发等等之后，发现如果再想深入下去，就会面临 一些“硬骨头”：遗留系统和开发设计能力的问题。在一些客户那里，他们产品有10多年了，但是很少有人新加程序文件，写代码习惯于复制粘贴，都是在已有的 类和函数上修修补补。团队缺少追求好代码的品质和能力，到处是大函数，上帝类（超大类，任何功能变化都要修改此类），重复代码，混乱逻辑，开发和维护成本 太高。作为一个顾问，如何才能从根本解决这样的开发设计能力问题呢？

在ThoughtWorks，如果招聘了一个没有经验的开发人员，会把他们送到印度的TWU(ThoughtWorks University)培养2-6个月，OO训练营是开发人员的主要课程之一。它专门用来训练开发人员如何使用面向对象，如何进行测试驱动开发。通过这样 的训练之后，开发人员可以很快的掌握面向对象开发和简单设计能力，养成追求好代码的品质。所以，我们也为客户的团队引入了TWU的OO训练营活动。

活动方式

OO训练营的培训方式和我们传统的“填鸭式”教育完全相反。它采用的是苏格拉底式教学法，顾问不会给你任何标准答案，而是通过问题的引导，让学员自己一步一步找到最佳的解决方案。我的OO训练营的组织方式一般是：

一、顾问提出需求

顾问在训练营活动会扮演着客户的角色。活动一开始的时候，会以客户的身份提出一个需求，让大家去完成。例如：要求建模一个长方形。

二、简单设计

以分组讨论方式做一个简单设计，一般从如下三个方面进行设计。

1. 类名是什么？
2. 类的职责是什么？对于复杂需求，可能会要求画一个简洁的UML对象关系图。
3. 类的测试用例会有哪些，并且找到第一个测试用例

讨论结束之后，每组介绍一下各自的讨论结果。通过分组讨论和顾问的引导，对建模一个长方形需求一般会得到如下的设计结果：

1. 类名是: Rectangle
2. 类的职责是计算周长和面积
3. 计算周长的测试用例：
   • a. 正常场景。如果长是2，宽是3，那么周长是10
   • b. 异常场景，宽为0的情况。如果长是2，宽是0，那么应该抛出异常
   • c. 异常场景，宽为负数的情况。如果长是2，宽是-3，那么应该抛出异常

这些测试用例完全是由学员自己设计出来的，没有标准答案。作为顾问只是引导大家，让每组的测试用例更具体和全面。假设没有一组学员没有考虑到异常情况的测试用例，这时也也不用指出来，等后面代码展示的时候，再指出这个问题，因为犯错是最好的学习方式。

三、测试驱动（TDD）开发

学员根据设计和讨论的结果，用测试驱动的方式进行结对编码开发。要求先写单元测试，写完一个单元测试之后，运行测试失败，然后再去写业务代码。如果没有失败的测试，不允许写一行业务代码。这样严格的要求，让大家养成测试驱动开发的好习惯。

两个人一组使用结对方式进行开发，要求使用乒乓式的结对方法。假设是A和B进行结对开发，A先写一个测试用例，编译通过但是测试失败。然后把键盘和 鼠标交给B，B写业务代码，让测试通过，然后为A再写一个失败的测试。通过这种乒乓的方式，一个人写测试用例，一个人实现业务代码，并且不停的变换角色。 这样两个人可以很好的进行配合，互相给对方出“难题”，一个人在写实现的时候，另一个人会思考下一个测试用例会是什么。

有的时候，我们会对团队提出一些更高的要求。比如编程过程中不允许使用鼠标，一切都是快捷键操作，这样能提高开发的效率。编程过程中不允许使用复制 和粘贴功能，如果是相同的功能或者代码，第一应该考虑到的是如何进行功能重用，而不是复制一遍，这样可以杜绝这样错误的编程习惯。

四、代码展示和顾问点评

写完代码之后，每个人开始展示自己的代码。这时，顾问就开始从代码里面寻找代码怀味道(Bad smell)，告诉大家什么样的是好代码，什么样的是坏代码。坏代码会有哪些危害，让后让大家重构。

例如：在实现长方形周长的时候，有人实现了getLength了getWidth方法，把长方形的长和宽的数据暴露出来了。那么这就是一个代码坏味 道（Bad smell），顾问会指出这个问题，告诉大家面向对象最重要的一个特征是封装，不应该把数据直接暴露出来。因为数据暴露出来之后，一方面造成数据的依赖和 耦合，另一方面其它代码在调用长方形这个对象的时候，也许会拿到长和宽的数据自己进行运算，这样就破坏了封装，对象之间耦合增大，并且容易产生重复的代 码。然后提问大家，正确的做法应该是什么？

答案应该会是长方形不应该把长和宽的数据暴露出来，所有长方形相关的运算和逻辑都应该在长方形这个领域对象里面进行。这也正是面向对象设计的一个重 要原则：Tell don’t ask的体现。通过这样的引导的方式，带领大家一步一步找到正确的面向对象设计方法和原则，同时纠正那些错误的编码和设计习惯。

每次活动就是类似这样的流程。顾问提出需求，然后是讨论和设计，结对开发，最后展示代码和点评。一轮结束之后，顾问又给大家一些新的需求，进行第二轮，如此一直的循环下去。

经验和教训

我多次为客户的团队组织过类似的训练营活动。最长的一次坚持了3个月，每周2次，每次两个小时，完成了OO训练营的所有课程。坚持参加完这个活动之 后，开发人员和技术Leader的都能真正的全面掌握面向对象设计方法和原则，并且把这些用到自己的项目中。下面是我的一些经验和教训：

• 活动时间安排。如果每次活动2个小时，一般是安排在下班左右，一小时工作时间和一小时个人时间。因为大部分团队都有交付的任务和压力，完全占用工作时间不现实。
• 家庭作业。由于我培训的一些团队技术基础不是很好，大部分开发人员无法在2个小时内完成编码任务。所以我会把没有完成的任务留作家庭作 业，让大家在活动之后完成，这样在OO训练营的时候主要是进行设计讨论和代码的展示点评。这样也有一个好处，每个人都会有时间进行独立思考，对代码进行重 构产生一个更好的设计。
• 活动整个过程是以引导为主，让大家自己进行编码、重构和讨论，自己解决问题，寻找设计的最佳解决方案。顾问只是担任一个类似主持人的角色。

参考资料

如果你也想在自己的团队或者公司引入这样的活动，下面一些资料可供参考：

• OO训练营资源为了做好OO训练营这样的活动，需要事先设计好一些练习和案例。下面的书籍里面就有一些很不错的例子，可以直接拿来练习。比如：《测试驱动 开发》这本书里面的Money例子，《重构》这本书的影评出租店例子等等。也可以去网上找到一些训练营的资料，我这里为大家提供一个咖啡机的案例，它有现 成的用户故事，可以直接拿来做OO训练营。它的网址是：http://agile.csc.ncsu.edu/SEMaterials/tutorials/coffee_maker/index.html 。
• 参考书籍顾问点评是一个很重要的环节。要求顾问首先自己是一个优秀的程序员，有丰富的开发和设计经验，这时候才能去很好的指导别人。精通和掌握下面几本书，是对顾问最基本的要求：
  • 《重构:改善既有代码的设计》Martin Fowler
  • 《测试驱动开发（中文版）》Kent Beck
  • 《敏捷软件开发：原则、模式与实践》Robert C. Martin
  • 《代码整洁之道》Robert C. Martin

只要功夫深，铁杵磨成针

──宋·祝穆

在我们咨询过程中，遇到一些开发技术很薄弱的团队，大部分人只会通过复制和粘贴的方式写代码，然后花费大量的时间进行修改和调试。有些开发人员还只是刚刚从 学校毕业，几乎没有什么开发经验。面对这样的团队，如何教他们使用敏捷开发方法？如何教他们测试驱动开发？如何教他们简单设计呢？

如 果连一门语言还没有完全吃透，还如何谈测试驱动开发和简单设计呢？这是一个很大的挑战。我回想起自己学习新语言的方法。前些时间我自学了SCALA语言， 看完了《Scala程序设计：Java虚拟机多核编程实战》，但还是觉得很多概念没有吃透，然后我就把书合上，然后把书上所有的例子独立写了一遍，这时才 能感觉自己是学了一门语言。于是我用同样的方法来训练这个团队：

一、找一本合适的书。

如果要快速吃透一门语言，最快的方法就是找一本好书，系统的把一门语言学习一遍，扫除语言的盲点。我们如何选择一本合适的书呢，我总结了三个条件：

1. 选择国外大师的权威著作，这些大师应该有深厚的开发经验，这样可以从书上学到很多编程和设计的最佳实践。
2. 书不能太厚，最好在200-300页左右，足够介绍完一门语言的常用特性和最佳实践。那些面面俱到的的厚砖头一般适合做参考手册。
3. 书上的例子一定要经典，这样比较适合练习。

因为团队主要使用C语言，我就在Google上搜索了一下“C书籍推荐”，找到了很多网友推荐的Top C语言书籍。通过我几天的阅读和筛选比较之后，最后我为大家选择了《C程序设计语言》这本书，完全符合上面的三个条件。如果你是使用的其它编程语言，可以参考下面的读书列表：

• 如果你用的是C++,我推荐《Essential C++中文版》
• 如果你用的是Ruby，我推荐《Everyday Scripting with Ruby中文版》
• 如果你用的是Java，我推荐《Agile Java 中文版：测试驱动开发的编程技术》
• 如果你用的是SCALA，我推荐《Scala程序设计：Java虚拟机多核编程实战》

二、具体的读书计划

选 择书之后，就要有一个具体可行的读书计划，这样大家能有节奏的一步一步把书读完。因为大家都有一些Ｃ语言基础，所以我们把读书活动安排为每天的家庭作业， 每周读完２章。我们的验收标准是：在不看书的情况下用TDD实现每章全部的例题（这个后面会有详细的介绍）。下面是我给大家制定的读书计划：

三、光看不练假把式

有了书，有了读书计划，当然这个还不够。这个活动的重点就是要写代码。这是读书写代码活动的验收条件。要求每个人在不看书的情况下，把书上的例题改造成测试驱动的代码。一章所有例题都改造完了，才算是把这章读完。比如：Hello World 的例子

#include
main()
{
printf(“hello, world\n”);
}

要求把这个例子改造成测试驱动的代码。改造之后代码分别为：
测试代码：

TEST(test_case_name, test_greetings) {
EXPECT_EQ(“hello, world”, greetings());
}

业务代码：

char[] greetings()
{
return (“hello, world”);
}

通过这样的训练，每个人不但可以系统的学习一遍C语言的知识，并且可以锻炼如何用TDD进行开发。

四、闭环──代码展示

如 何保证每个人可以完成写代码活动并且达到预期的效果呢？我们搭建了一个Subversion，让每人把自己的代码提交上去。我们每天早上会有一个代码展示 活动。准备一个投影仪，每个人花3-5分钟展示和讲解自己的代码，然后集体鼓掌表示认可，然后其他的同事提出问题和改进建议。这样有三个好处：

• 让每人分享自己的代码和经验，这是对每人的认可和鼓励
• 一个互相学习的氛围; 通过展示可以学习一下其他同事是怎么写代码，怎么写测试
• 互相督促，如果没有完成代码，这时候就没有任何东西可以展示了

我们坚持了一个月之后，这个活动结束了。每个人都感觉很好，系统的把C语言掌握了一遍。一些有经验的一个开发人员也觉得，系统的学习之后消除了C语言的很多盲点。现在对C语言编程更有信心了，并且还学会了如何做TDD开发。

上周五一堆人在会议室讨论持续集成的解决方案，大家搞出来了这么个词：质量管理可视化。在敏捷开发方法中，有一项非常重要的实践叫：项目管理可视化。用类似看板的方式，把需求和开发任务贴到墙上进行可视化管理。那持续集成，无疑就是对项目的质量的可视化管理。

软件质量分为二部分:

一、外部质量

主要是指软件满足客户的需求，能够正常工作；软件功能正确并且健壮。在每次有代码提交之后，持续集成会自动编译、部署，运行单元测试、功能测试、验收测试。如果有测试失败，那说明有功能被提交的代码破坏，那么持续集成会失败报警。这个美吧，不过要想玩得转测试覆盖率至少要到达60%以上，这样自动化测试才能发挥威力。

二、内部质量

主要是指软件的可维护性、可测性、可扩展性等。可以通过代码的静态检查，包括代码检查、静态结构分析、代码质量度量等来监控项目代码的健康程度。我们可以持续集成上面运行这些静态坚持工具，生成代码健康状况报表，或者在代码不符合要求的时候报错告警。

这样就可以在团队里进行质量的可视化管理。听上去很邪恶呀！

我这几年给一些公司做了内训、咨询，指导了很多团队进行敏捷的转型。其中发现了推行敏捷遇到的一些阻碍，在这些阻碍严重的时候，可能会直接导致敏捷推行的失败。

下面就是导致敏捷推行失败的三大杀手：

一、命令式的管理方式

这是敏捷的第一大杀手。特别在一些大的软件部门或公司中，很多是命令式的管理方式。这样直接导致，一线的工作人员缺乏主动思考和主动工作的能力。软件开发强调的是自组织的管理，每一个领导或经理都是一个教练，是帮助团队成长，帮助团队解决编码、设计和需求方面的工作，而不只是单纯的发号施令者。最好的架构、需求和设计来自于自组织的团队。

同时，如果一个组织存在命令式的管理方式。这说明了这个组织不够了解软件开发的真正本质，缺乏创新，工作效率不高。

二、人员的能力和经验问题

这是对国内软件行业的一个一个挑战。在国外，已经经历了一个面向对象设计和极限编程的革命，所以现在在开始组织和流程的优化，开始软件精益的流行。而在中国，一些软件公司的开发设计能力是很差的，一般开发团队平均只有2-3年的经验。实施敏捷有一个前提：基础扎实，具有很好的开发、设计、需求分析和项目管理的能力。这些都是基本功，如果这些方面的能力有问题，那么推行敏捷可能会出现“虚不受补”的情况。

三、遗留系统

这是很多大公司的一个现状，很多的新功能都是基于遗留系统进行开发。如果遗留系统有很长时间，甚至10年之久。这样，很可能会直接导致迭代开发、用户故事划分、测试驱动开发无法正常的进行。如果遗留系统的基础架构有问题，那么唯一有效的解决方案就是重新开发。这就意味着大量的工作量、成本和风险。这时就需要一个专门的遗留系统重构项目，这不是敏捷方法可以直接解决的问题。

UML概述

• UML层次
  • 概念层（Conceptual）：表达自然语言
  • 规格说明层(Specification)：用来转换成源代码
  • 实现层(Implementation)：描述已经存在的源码
• 不幸的是，这些图本身并不能说明它们描绘在哪个层次上了
• 各种类型的图
  • 类图（Class Diagram）
    • 长方形表示类、箭头表示关系
    • 图中关系叫做关联
    • 关联名称对应变量名
    • 箭头边的数字表示持有的数量
    • 大多数符号式可选的
  • 对象图(Object Diagram)
    • 它说明了系统执行期间在某一特定时刻的 一组对象及其关系
  • 序列图(sequence diagram)
    • 描述消息的先后顺序
  • 协作图(collaboration diagram)
    • 描述了对象之间的关系
  • 状态图（State Diagrams）

有效使用UML

• 使用模型来验证事物是否可工作
• 传达设计
• 最后的文档
• 复杂的UML图比没有更糟糕
• 只保留有价值的UML图
  • 表现你的系统中一个通用设计解决方案的图
  • 记录了复杂的协议，难以通过代码了解的图
  • 提供了比较少涉及到的系统范围内的“路标图”的图
  • 记录了比代码更易表述的设计意图的图
• UML图只是了解代码的一条捷径

注：《UML:Java程序员指南》的读书笔记