滥用缩写和意义的缺失
October 31st, 2009
《ThoughtWorks文集》 的第六章这样写道：
我们总会不自觉地在类名、方法名或者变量名中使用缩写。请抵制住这个诱惑。缩写会令人迷惑，也容易隐藏一些更严重的问题。
不光是在程序中。这个庞大的组织里充斥着形形色色的缩写。角色有缩写（SE、DE、PO、PL、TL、TPL…），测试种类有缩写（UT、ST、SDV、SIT、HLT、LLT…），文档类型也有缩写（PR、SD、SRS、TC…）。
缩写不仅会令人迷惑。“更严重的问题”是，当人们习惯了铺天盖地的缩写，大脑就会麻痹而停止思考缩写所代表的本体是什么。于是人们就只是凭着惯性把一个缩写和一个既定的东西联系起来，而不去思考两个问题：
- 这个东西存在的价值是什么？
- 如何改进现有的东西使之更好地达成其预期的价值？
当我们说出一个完整的、有意义的名称，大脑是在思考这个名称所指涉的意义。例如当我说自己是“tech lead”，我就会下意识地想：我做的事，第一有没有“tech”的性质，第二有没有“lead”的性质。而当大脑习惯了“TL”这个缩写，扮演这个角色的人们也就不会在下意识中不断审视自己，从而使无数细节改进就此浪费──或者从来就没有出现过。
这个庞大的组织相信，目的重于过程，实质重于形式。但我们谈论的是沟通。麦克卢汉说，媒介即信息。沟通的形式就是实质，沟通的过程就是目的。不在意形式的沟通，其结果就是传递的信息直接降格化为无意义──例如这些缩写。
《ThoughtWorks文集》精选版可以下载了
October 27th, 2009
在帮助客户实施敏捷的过程中，ThoughtWorkers常被问到一个问题：有没有一套标准的“敏捷模板”可供快速入门之用？
作为一种强调持续改进的方法学，自然不会有一套放诸四海而皆准的“标准流程”；但对于希望采用敏捷方法的组织和个人而言，若有一组普遍适用的最佳实践作为基础，便能少走许多弯路，以期事半功倍之效。
摆在你面前的，正是这样一本“敏捷入门手册”。
本迷你书从《ThoughtWorks文集》的13 篇文章精选5篇编撰成集。这几篇文章有一个共同点：它们介绍的是一些最根本、最易施行、又最能立竿见影的敏捷实践。藉由这几篇各自独立而又相互关联的文章，我们希望帮助读者从持续集成和测试入手，建立行之有效的项目健康保障体系，并掌握必要的面向对象编程和重构技能，从而切实提升软件质量，并为更进一步的改进打下坚实基础。
如果你喜欢本书，可以 购买原版《ThoughtWorks文集》 。
或在InfoQ中文站 免费下载这本书（PDF）
博尔赫斯风格的培训
October 16th, 2009
今天培训的主题是，站立会议和回顾会议。
于是，我们先讲，站立会议是干什么用的，应该怎么开，常见的坏味道有哪些，小技巧有哪些。
讲完站立会议，就开始讲回顾会议。大家一起读一遍回顾会议宣言，然后讲回顾会议是干什么用的，应该怎么开。
然后，大家就一起来开一次回顾会议吧。回顾的主题是：我的站立会议。
于是大家开始回顾，各自团队的站立会议开得怎么样，哪些地方做得好，哪些地方可以改进，有什么点子，等等。
一边回顾，一边继续讲解，“这就是回顾会议的要点，大家记下来了吗？”
回顾做完，针对“站立会议讲太多细节”和“团队成员参与度不高”两个最受关注的主题，得到了一系列切实可行的改进措施。
同时，怎么做回顾会议，也就学到手了。
这培训做得，颇有点像博尔赫斯小说的风格。
（还有从 胡凯 那偷学来的小技巧，着实精妙得很啊。）
对象健身操：九诫
October 12th, 2009
- 方法只使用一级缩进。
- 拒绝使用else关键字。
- 封装所有的原生类型和字符串。
- 一行代码只有一个“.”运算符。
- 不要使用缩写。
- 任何类的长度不能超过五十行。
- 任何类中的实例变量不能超过两个。
- 任何包含容器的类不能再包含其他的成员变量。
- 不使用任何Getter/Setter/Property。
阻碍我们写出好代码的，首先是根本不知道代码能写多好。
结构化沟通框架
October 4th, 2009
每次沟通活动（会议）应该有以下元素：
- 动机：每个会议应该有且只有一个动机，声明沟通的涉众
- 目标：每个会议最好有且只有两个目标，一个针对现状的信息传导，一个针对将来的行动
- 实践
例如，standup meeting：
- 动机：全团队每天的内部沟通
- 目标：
- 每个人了解团队整体当前进度
- 触发针对问题的后续详细/小范围讨论
- 实践：
- 每个人讲三件事：昨天做了什么，今天要做什么，重要的事项和问题
- 所有人对所有人讲话
- 小范围的详细讨论被及时中止并放到会后
再例如retrospective：
- 动机：全团队周期性的回顾
- 目标：
- 增进信心
- 促成改进
- 实践：
- 就事论事，对事不对人
- 具体，每个条目只说一件事
- 讨论最受关注的条目，每个条目要有后续行动和负责人
知易行难，魔鬼都在细节中
October 4th, 2009
一看这本 《卓有成效的程序员》 ，就一票人说，前半部分写得好呀，思想很深邃呀，很值得去思考呀。后面嘛，无非是些小技巧啦，只要思想掌握到了，小技巧无关紧要的啦。
还有 《重构》 也是，前几章思想很深邃呀，至于重构列表嘛，少少有点琐碎啦，只要思想掌握到了，具体的重构怎么做嘛无关紧要的啦。
还有我讲怎么做standup，怎么做retrospective，嗯嗯，思想很深邃呀。结构化交流，专注，目的驱动，很值得思考呀。至于具体这个会议的形式嘛，只要思想掌握到了，形式自己可以调整嘛，无关紧要的啦。
扯淡。
结果就是，思想好像掌握到了，实践怎么都实践不起来。咦？我不是秉承着xx思想来做的吗？怎么效果就没有呢？嗯…看来这个xx思想是有点问题啦…要么就是我们这里情况太特殊所以xx思想也不适用啦…所以xx思想实在太理想化啦…
敏捷，精益，整个讲的就是“怎么做事”。做事不照着正确的方式做，光抓着个“思想”在那边YY武林秘籍大还丹…练辟邪剑谱还要挥刀自宫的好吗？
所以涅…（1）真想学点什么，就好好的学，别人说怎么做就认真怎么做，不要抓着个自以为是的“思想”就开始自己YY；（2）真要自己YY也无妨啦，不过可以麻烦不要扯上别人的“思想”么？Neal Ford和Martin Fowler教咱怎么做事，可没教咱怎么YY。
