-
读《建设全功能团队》后感
胡凯在InfoQ发表了两篇文章。读后，简单的感想是：追求卓越的团队，就得所有人会做所有事。
所有人都得会编程。所谓编程，是指在离散的数字世界中输入信息量以建模连续的真实世界之某一局部方面的智力活动。如果不会编程，如何知道用户的价值应该怎样以数字方式建模？如果不会编程，如何知道数字模型的哪些部分可能存在潜在错误？不会编程的人做不好软件需求，也做不好测试。
所有人都得会测试。所谓测试，是指提前发现和消除用户可能在真实使用中发现的软件缺陷的智力活动。如果不站在最终用户、最终生产环境的角度思考，“质量内建”从何谈起？不会做测试的人做不好软件需求，也做不好软件开发。
当然，常见的角色还有需求和管理。不过，“所有人都要了解需求”是敏捷软件开发中的老生常谈。而管理，私以为它就是一种浪费。如果团队每个人都会编程、会测试、会跟客户沟通需求，我们真的需要项目经理吗？
其中最难的部分是“所有人都得会编程”。因此每个追求卓越的软件企业招聘和人才培养以及每个追求卓越的软件从业者的个人成长都应该将编程能力作为一个重点。
以上。
-
问题解决型沟通活动纲要
沟通有很多目的，例如解决问题、帮助个人成长、交流感情、杀时间等等。本文针对问题解决型沟通。
获得信息
专业人士的工作是解决问题，而解决问题的第一步是知道问题是什么。在动手（甚至动脑）尝试解决问题之前，首先要获得足够的信息。
倾听
首先学会倾听。耐心，让带着问题来找你的人慢慢把话说完。其中最重要但经常被忽视的信息是：提出问题者的目标和价值。提出问题的人往往会直接告诉你应该怎么做。告诉他不要急于进入解决方案，先讲清楚自己想要达到的目标和价值，然后你会和他一起寻找解决方案。
不光是对方的解决方案，还要学会放下自己的解决方案。专业人士都有多拉A梦情结，总希望自己能从百宝袋里掏出法宝让康夫破涕为笑。这个时候别去想你有什么法宝，那会让你听不清对方的问题。
有时候（如果你对面的是一个同样训练有素的思考者）只是倾听就可以解决问题。有时候对方只是需要平静地把问题从脑子里过一遍就能找到办法。如果对方正在一点点整理思路，不要打断他，可能他自己就能搞定。而他同样会感谢你。
记录
大多数时候坐在你对面的不是和你一样训练有素的思考者。所以他需要你帮助他整理思路──通过把他告诉你的信息记录下来。不仅记录“现在是什么样”，还要记录“我希望将来是怎么样”。只对现状不满而没有期望的人不是在请你解决问题，他只是需要一点情感抚慰；只讲期望而不说现状的人，嗯，他还没睡醒。
重复一遍：记录是为了帮助对方整理思路，而不是给你自己备忘。所以，不要在你自己的笔记本上做记录。用白板，或者其他水平相当的可视的工具来记录。把记录的过程变成一个共同创作的过程。随时问对方反馈“你看这样画对不对？”。如果他这个时候说“画得不对”，你就为自己避免了几个小时甚至几天的返工。
因为是共同创作，请注意记录的美观。有很多图示方法可以用，或者最简单的逐条记录也不坏。关键在于两点：（1）字体写小一点，字体大了就显得草率和难看；（2）手握住白板笔的前半，手掌贴在白板上写。漂亮（或者至少整洁）的白板才会让人有与你共同创作的欲望。这有一部分能力问题，主要是态度问题。
顺便附赠一个对“敏捷难道不写文档吗”这个问题的标准答案：一个好的沟通者会在信息还热乎的时候就把它可视化出来，立即与相关者达成共识，而不是开会时闷头记笔记回到办公室抓耳挠腮炮制出一个尽管漂亮但充满含糊和误解的文档。共识达成，然后把这个漂亮（或者至少整洁）的白板拍下来，文档也有了。
回讲
分析
差距
根因
计划
促成行动
责任人
验收计划
PDCA
基本原则
-
问题解决型沟通（壹）：获得信息
沟通有很多目的，例如解决问题、帮助个人成长、交流感情、杀时间等等。本文针对问题解决型沟通。
获得信息
专业人士的工作是解决问题，而解决问题的第一步是知道问题是什么。在动手（甚至动脑）尝试解决问题之前，首先要获得足够的信息。
倾听
首先学会倾听。耐心，让带着问题来找你的人慢慢把话说完。其中最重要但经常被忽视的信息是：提出问题者的目标和价值。提出问题的人往往会直接告诉你应该怎么做。告诉他不要急于进入解决方案，先讲清楚自己想要达到的目标和价值，然后你会和他一起寻找解决方案。
不光是对方的解决方案，还要学会放下自己的解决方案。专业人士都有多拉A梦情结，总希望自己能从百宝袋里掏出法宝让康夫破涕为笑。这个时候别去想你有什么法宝，那会让你听不清对方的问题。
有时候（如果你对面的是一个同样训练有素的思考者）只是倾听就可以解决问题。有时候对方只是需要平静地把问题从脑子里过一遍就能找到办法。如果对方正在一点点整理思路，不要打断他，可能他自己就能搞定。而他同样会感谢你。
记录
大多数时候坐在你对面的不是和你一样训练有素的思考者。所以他需要你帮助他整理思路──通过把他告诉你的信息记录下来。不仅记录“现在是什么样”，还要记录“我希望将来是怎么样”。只对现状不满而没有期望的人不是在请你解决问题，他只是需要一点情感抚慰；只讲期望而不说现状的人，嗯，他还没睡醒。
重复一遍：记录是为了帮助对方整理思路，而不是给你自己备忘。所以，不要在你自己的笔记本上做记录。用白板，或者其他水平相当的可视的工具来记录。把记录的过程变成一个共同创作的过程。随时问对方反馈“你看这样画对不对？”。如果他这个时候说“画得不对”，你就为自己避免了几个小时甚至几天的返工。
因为是共同创作，请注意记录的美观。有很多图示方法可以用，或者最简单的逐条记录也不坏。关键在于两点：（1）字体写小一点，字体大了就显得草率和难看；（2）手握住白板笔的前半，手掌贴在白板上写。漂亮（或者至少整洁）的白板才会让人有与你共同创作的欲望。这有一部分能力问题，主要是态度问题。
顺便附赠一个对“敏捷难道不写文档吗”这个问题的标准答案：一个好的沟通者会在信息还热乎的时候就把它可视化出来，立即与相关者达成共识，而不是开会时闷头记笔记回到办公室抓耳挠腮炮制出一个尽管漂亮但充满含糊和误解的文档。共识达成，然后把这个漂亮（或者至少整洁）的白板拍下来，文档也有了。
回讲
画好了现状和目标的可视图形，现在转过身来，给在场的所有人讲一遍，问他们“我画得对不对”。作为倾听者，如果你主动把沟通过程中的所有困难都揽到自己身上（“我画得对不对”），对方会感谢你，会愿意给你讲清楚。
另一方面，如果你是那个要给别人讲事情的人，请丢掉一句口头禅：“你明白我的意思吗？（笨蛋！）”讲完以后问对方“我讲明白了吗”，然后请对方复述一遍，最好是以可视化的方式。
最后别忘了，拍照。
（未完待续）
-
阅读之2010秋冬季
（这次从西安出来以后读的一些书。）
《反潮流》。睿智而敏锐的以赛亚·伯林。我喜欢他关于马基雅维利的那一篇。只有当你不仅了解某人说过什么、而且了解某人何时何地说与谁听、而且了解当时的人对某人说的这些会如何反应，你才会更接近于了解某人是一个怎样的人、为何要说那些话。同样，关于犹太人的。
《编程的本质》。Stepanov是在向我们展现，科学家和工程师是以多么不同的方式编写程序。大量近世代数的概念。让我对自己进行严肃阅读的能力产生了怀疑。于是想要好好补习一下基础。
《语言本能》。语言是一种被继承的本能而非纯粹后天习得的技能。大量的实证。有新鲜感。
《玫瑰的秘密》。很可爱的小故事。
《iPhoneSDKDevelopment》。不错的入门书。我会写iPhone程序了～～虽然都是在模拟器上。
《玫瑰的名字注》。人物依据他们生活在其中世界的法则，不得不做某些事，而叙述者成了他的预设前提的俘虏。可是艾柯又不甘心做俘虏，所以他要再来注解一把。关于小说环境的设定，令人拍案叫绝。
《精益企业》。关于企业转型中领导者的角色部分论述精辟。但我产生了一个联想：每一句简单告诫的背后，都是一家（或许好多家）企业数十数百人的惨痛经历。不禁有点悲怆。另外，翻译太差。
《Agile Testing》。佳作。脉络清晰，内容详实。对于“如何做敏捷测试”的标准答案从此应该是“读这本书”。每一章的开头有本章内容脑图提供，省了我大把时间。
《All For One》和 《True Professionalism》。正在读，两本关于专业服务的书。后者提出了几个很好的问题：你想成为谁？你想为谁服务？你想和谁一起工作？
如果你不爱你的客户，你很难真的那么专业。
-
只要写程序，就会有收获
公司搞了个HTML5编程比赛。奖品是一台iPad。于是我也报名了。（不想被年过三十并且已经拥有iPad的大叔打败的年轻TWer们，赶快加油吧～～）
一，WebSQL数据库尽是些异步操作，搞得我很难测试…如果谁做一个JsDbUnit之类的东西我一定挺他一票。
二，Safari上也可以用Firebug，Chrome上也可以用，IE上也可以用～～
三，搞出了一个牛逼闪闪的“Techlead项目启动手册”，这就叫经验啊经验啊～～
继续写程序去～～
-
精益生产的六大要素
工作场所安全、有序、极为整洁。
产品按照客户需求即时生产。
六个西格玛质量标准融入产品和生产过程中。
被授权的车间小组有权做出重大决策。
可视化管理跟踪业绩，公司的一切均让员工了解。
坚持不懈地追求完美。
-
开发一个好的自动化测试工具（如果需要的话）
如何开发一个好的自动化测试
-
多能工化的算术表述
（本文系剽窃胡凯的点子。写出来一是因为有趣，二是为了刺激胡凯赶快写好他的文章。）
假设一个功能点的开发需要1人天、测试需要0.5人天。一支3个开发人员和1个测试人员构成的团队一周能交付多少个功能点？
答案是8个。因为第一天还没有功能点被开发出来，测试人员没的测。后来虽然开发了很多，但没有测，不能交付。
现在想象另一支团队：还是4个人，不过4个都是开发人员，并且开发人员都能够并且愿意做测试工作（通常不是一个很离谱的假设）。这支团队一周能交付多少个功能点？
具体的动态规划有点复杂，总之是接近 4×5/1.5 ，十多个。比有专职测试的团队交付得多。你真的相信“专业分工能提高效率”吗？
更有趣的是，如果这支团队只有3个开发人员，没有那位测试人员，但开发人员都能够并且愿意做测试工作。这支团队一周能交付多少个功能点？
答案大概是9或者10。多加一个专职测试，反而不如没有这个人交付得多。你真的相信“专业分工能提高效率”吗？
更详细的计算以及“为什么”和“如何能做到”的答案，敬请期待胡凯的文章。（我写完这个有趣的部分就没兴趣再写下去了。）
-
TuoHuang.Info
一开始，胡凯跟黄拓说，你需要一个体面的博客，一个有自己域名的博客。我说，我有服务器，你把域名申请到，我帮你搭。于是黄拓学习了怎么申请一个域名，怎么把域名映射到别人的服务器上，怎么使用WordPress。于是TuoHuang.Info就好了。我满喜欢这个域名的，听起来像是“拓荒”。
我还跟黄拓说，你的博客写得太不负责任了。你要坚持写，把自己学到的东西写下来，让别人也看明白，才算真正学会了。黄拓点点头，若有所思的样子。于是他就开始写得越来越多，越来越有样子。我看到他写JRebel的第一篇，问他些深入的问题，他又写了个精彩的第二篇。
黄拓生于1988，离开大学不到半年，目前ThoughtWorks中国最年轻的一名员工。
能跟这样好的年轻人（以及，把年轻人教导得这样好的胡凯）一起工作，真是很好。
-
到现场去
再说一次，一切的改善，首先是到现场去。
又是这样一位志存高远的改善推动者。她想知道一次敏捷变革如何进行的所有细节，她想找到一套敏捷实施的模板，她想把敏捷的经验快速复制到成千上万人的组织，她想得很多很大。
但她不肯到现场去。
当我说这些东西的细节对你一点用都没有的时候，我不是在开玩笑也不是在故意刁难你。你不知道现场在发生什么，你不知道人们为什么痛苦，你不知道他们在追求什么，你不知道什么在阻碍他们，你也不知道这些改善计划是如何被一步步推导出来的。看着最后的这个改善计划，看得越细你只会越糊涂，只会朝着错误的方向走得越远。因为你想不去现场、叉着两只干净的手就去推动改善，因为你重视流程与工具重于人与交互。
到现场去，你才会知道如何把那些抱怨转化成持续改善的动力。去了解和关心那些置身于改善中的人，你才会知道应该给他们提供怎样的支持、向他们提出怎样的要求。把你自己的政治野心扔掉，你才会知道如何赞赏一点一点改善的积累、鼓励他们坚持不懈。
不到现场就不要谈改善。不了解现场的改善推动者所能做的最好的事，也就是彻底远离现场，不要给人们添乱就行了。
