-
三人成众
一个人是孤单的，就像“人”字，只能自己支撑自己。
两个人的团队，如果不是互相对立的话，就难免有一人比较强势。如同一个“从”字，主从关系往往确定下来就不易改变。
四个人或更多人的团队，就常会分裂成小帮派。
三个人的团队是个绝配。三人成“众”，既互相支撑，又互相平衡，均势来回变，难有某一人永远强势。一起出现，三人不显太多；分开行动，一人两人可以灵活配置。
而且争吵能得到有效控制。一旦两人出现争执，另一人便可客观评判，居中调停。而且这次的旁观者下次就可能成了争执的一方，这次的争执者下次又换了调停的角色。于是每个人在身涉争执时大可各执一端畅所欲言，因为信任旁观者已有准备平息战火。于是争执也常被带往健康的方向。
所以如果去陌生而紧张的环境工作，三个人的团队是很好的选择。
-
测试驱动咨询
当别人求助你解决一个问题时，第一件要做的是什么？
不是挽起袖子解决问题。不是诊断症结在哪儿。甚至都不是问5个why。
首先要问的问题是：
- 如果这是一个问题，用什么数据能体现它？
- 如果问题被修复了，从这个数据上是否能反映？
然后，把度量放下去。每个度量项要有几个要素：
- 哪些数据？
- 如何得到数据？
- 以什么频率采集数据？
- 如何发布结果？
按照这几个要素制定一个跟踪度量方案。用这个方案先采集现有数据。根据现有数据定一个改进目标。
这就是你的──正在失败的──测试。先把测试放下去，然后再提任何改进措施。
-
Sponsor的价值所在
今儿给麦罗打电话的片段摘录…
- 我：俺们SVN server装Windows上，用个32位Apache做前端，那玩意有2G内存限制…
- 麦：一，用Windows做SVN server。二，代码库很大。三，很多人同时访问。
- 我：对头～～
- 麦：你在XX公司？
知音啊～～我又内牛满面了～～介个就是Sponsor的价值亚～～
-
设计问题多于方法问题
比如说吧，产品和平台之间依赖好严重啊，产品还经常要修改平台的代码；特性组和支撑组之间耦合好紧密啊，支撑组的代码都得到特性组去验证和提交。敏捷怎么解决这些问题啊？还有啊，开发人员总是几个故事一起做，做出来的故事测试人员发现没法测。敏捷怎么解决这些问题啊？
还有啊，架构思想都没有传达到开发人员啊，都做乱掉了；持续集成工具的专家他不属于开发团队啊，出问题找他支持好麻烦啊；测试工具的专家…嗯，最近的一个离我们大概有一千公里吧。敏捷怎么解决这些问题啊？
这些不是方法问题，是设计问题。设计很简单。单一职责，DRY，OCP，依赖倒置，接口隔离，就这么些东西而已。但简单不等于容易。写代码的时候不会设计，划分模块的时候同样不会，划分产品的时候同样不会，管理组织机构的时候还是同样不会。一个软件组织不让员工学会写代码，其结果就是设计问题出现在所有地方。
还有个下半句：管理问题多于能力问题。
我们很想提高工程人员的技术能力啊，应该怎么让他们学习啊？我们这些实践影响的人太少啊，怎么快速复制到成千上万人啊？──想要事情做下去，不走样，就得去关注所有的细节。拍一个任务下去，你周五之前给我完成，我只看结果。完不成怎么样？时间过去了，能力还是没提升，问题还是没解决。这就是所谓粗放式管理。一层一层都说，行，我支持，大家去学习吧──你不去手把手的教着他，他除了变成蘑菇还能变成什么？
管理细节也很简单。代码的坏味道有没有重构？每个函数有没有测试？每次提交的注释是不是符合规范？但简单不等于容易。写代码的时候不会管理细节，做管理也同样不会。一个软件组织不让员工写好代码，其结果就是管理问题出现在所有地方。
-
持续不能集成
持续集成只是信息源。持续集成的检验是在代码提交之后而非之前进行的，因此持续集成的作用只是使项目健康情况可视化。并且这种可视化必须建立在构建经常成功的前提下。因为软件本身的复杂性决定了只有“是否达到质量要求”能够被简单度量，而“达到（或不达到）质量要求的程度”无法被简单度量。所以，如果构建经常失败，持续集成所能提供的信息就只剩“项目一直不健康”──这个信息的价值很小，如果不是完全没有价值的话。
让持续集成保持经常成功，必须规范三件事：
- 提交代码之前必须更新
- 提交代码之前必须进行本地验证
- 线上构建失败时不得进行任何提交（或更新）
如果做不到这三件事，持续集成就可能降格化为持续不能集成：你知道项目有问题，但不知道问题出在哪儿，也不知道该如何解决这些问题。
为了避免这种降格化，在持续集成到位之后，需要用更多的手段确保三点规范得以落实：
- 代码库和持续集成分级
- 责任逐级下压
- 建立提交前本地构建基础设施
要言之：持续不能集成会使持续集成的价值降低到约等于0（甚至低于0）。要避免持续不能集成的发生，第一要严格规范，第二要提供技术手段使规范能够被落实。
-
滥用缩写和意义的缺失
《ThoughtWorks文集》的第六章这样写道：
我们总会不自觉地在类名、方法名或者变量名中使用缩写。请抵制住这个诱惑。缩写会令人迷惑，也容易隐藏一些更严重的问题。
不光是在程序中。这个庞大的组织里充斥着形形色色的缩写。角色有缩写（SE、DE、PO、PL、TL、TPL…），测试种类有缩写（UT、ST、SDV、SIT、HLT、LLT…），文档类型也有缩写（PR、SD、SRS、TC…）。
缩写不仅会令人迷惑。“更严重的问题”是，当人们习惯了铺天盖地的缩写，大脑就会麻痹而停止思考缩写所代表的本体是什么。于是人们就只是凭着惯性把一个缩写和一个既定的东西联系起来，而不去思考两个问题：
- 这个东西存在的价值是什么？
- 如何改进现有的东西使之更好地达成其预期的价值？
当我们说出一个完整的、有意义的名称，大脑是在思考这个名称所指涉的意义。例如当我说自己是“techlead”，我就会下意识地想：我做的事，第一有没有“tech”的性质，第二有没有“lead”的性质。而当大脑习惯了“TL”这个缩写，扮演这个角色的人们也就不会在下意识中不断审视自己，从而使无数细节改进就此浪费──或者从来就没有出现过。
这个庞大的组织相信，目的重于过程，实质重于形式。但我们谈论的是沟通。麦克卢汉说，媒介即信息。沟通的形式就是实质，沟通的过程就是目的。不在意形式的沟通，其结果就是传递的信息直接降格化为无意义──例如这些缩写。
-
《ThoughtWorks文集》精选版可以下载了
在帮助客户实施敏捷的过程中，ThoughtWorkers常被问到一个问题：有没有一套标准的“敏捷模板”可供快速入门之用？
作为一种强调持续改进的方法学，自然不会有一套放诸四海而皆准的“标准流程”；但对于希望采用敏捷方法的组织和个人而言，若有一组普遍适用的最佳实践作为基础，便能少走许多弯路，以期事半功倍之效。
摆在你面前的，正是这样一本“敏捷入门手册”。
本迷你书从《ThoughtWorks文集》的13篇文章精选5篇编撰成集。这几篇文章有一个共同点：它们介绍的是一些最根本、最易施行、又最能立竿见影的敏捷实践。藉由这几篇各自独立而又相互关联的文章，我们希望帮助读者从持续集成和测试入手，建立行之有效的项目健康保障体系，并掌握必要的面向对象编程和重构技能，从而切实提升软件质量，并为更进一步的改进打下坚实基础。
如果你喜欢本书，可以购买原版《ThoughtWorks文集》。
或在InfoQ中文站免费下载这本书（PDF）
-
博尔赫斯风格的培训
今天培训的主题是，站立会议和回顾会议。
于是，我们先讲，站立会议是干什么用的，应该怎么开，常见的坏味道有哪些，小技巧有哪些。
讲完站立会议，就开始讲回顾会议。大家一起读一遍回顾会议宣言，然后讲回顾会议是干什么用的，应该怎么开。
然后，大家就一起来开一次回顾会议吧。回顾的主题是：我的站立会议。
于是大家开始回顾，各自团队的站立会议开得怎么样，哪些地方做得好，哪些地方可以改进，有什么点子，等等。
一边回顾，一边继续讲解，“这就是回顾会议的要点，大家记下来了吗？”
回顾做完，针对“站立会议讲太多细节”和“团队成员参与度不高”两个最受关注的主题，得到了一系列切实可行的改进措施。
同时，怎么做回顾会议，也就学到手了。
这培训做得，颇有点像博尔赫斯小说的风格。
（还有从胡凯那偷学来的小技巧，着实精妙得很啊。）
-
对象健身操：九诫
- 方法只使用一级缩进。
- 拒绝使用else关键字。
- 封装所有的原生类型和字符串。
- 一行代码只有一个“.”运算符。
- 不要使用缩写。
- 任何类的长度不能超过五十行。
- 任何类中的实例变量不能超过两个。
- 任何包含容器的类不能再包含其他的成员变量。
- 不使用任何Getter/Setter/Property。
阻碍我们写出好代码的，首先是根本不知道代码能写多好。
-
结构化沟通框架
每次沟通活动（会议）应该有以下元素：
- 动机：每个会议应该有且只有一个动机，声明沟通的涉众
- 目标：每个会议最好有且只有两个目标，一个针对现状的信息传导，一个针对将来的行动
- 实践
例如，standup meeting：
- 动机：全团队每天的内部沟通
- 目标：
- 每个人了解团队整体当前进度
- 触发针对问题的后续详细/小范围讨论
- 实践：
- 每个人讲三件事：昨天做了什么，今天要做什么，重要的事项和问题
- 所有人对所有人讲话
- 小范围的详细讨论被及时中止并放到会后
再例如retrospective：
- 动机：全团队周期性的回顾
- 目标：
- 增进信心
- 促成改进
- 实践：
- 就事论事，对事不对人
- 具体，每个条目只说一件事
- 讨论最受关注的条目，每个条目要有后续行动和负责人
