关于DevOps的快速阅读
January 30th, 2011
中文WikiPedia上的 DevOps 这个词条是我今天刚翻译过来的。
需要频繁交付的企业可能更需要对DevOps有一个大致的了解。Flickr发展了自己的DevOps能力，使之能够支撑业务部门“每天部署10次”的要求──如果一个组织要生产面向多种用户、具备多样功能的应用程序，其部署周期必然会很短。可以把DevOps看作开发（软件工程）、技术运营和质量保障（QA）三者的交集。
The whole point of DevOps is to enable your BUSINESS to react to market forces as quickly, efficiently, and reliably as possible.
特别值得一提的是，DevOps对于个人来说（再一次地）是个学习和 持续改进 的问题。
Automate, automate, automate.Don’t stop innovating and learning. Technology moves fast. So do customer requirements.
What's Wrong With Multi-tasking?
January 28th, 2011
努力培养审美能力中～
January 25th, 2011
站在新的旅程前
January 19th, 2011
翻译了两章 DSL 。又温习了一遍编译原理。
学了一点点算法基础。插入排序是Θ(n^2)的，合并排序是Θ(nlgn)的。堆排序是优雅的，快速排序是很快的。算法分析是费脑的，概率分析是没看懂的。
成功往iPad上传了自己写的应用程序。打算开始做Ohfy。准备看看 PhoneGap 。
跟客户领导打了电话。回北京参加一天的会。渐渐开始思考客户关系的事情。想把《 All For One 》读完。
帮着组织 QCon 的一个track。收到盛大寄来的新年礼包。听说石一楹要在杭州开研究院了。
找徐昊求了两根签。第一签是“test automation”，第二签是“smoke test”。看来这个项目的测试必然要成问题了。
看见办公室里很美的墙和白板，感到欣慰。就是这样在抱怨和改善中成长的。
明天，又要去墨尔本了。这次会在那边过年，在Bourke Street看舞龙。
2011年有着一个华丽丽的开局呢～～
A3报告的基本结构
January 10th, 2011
悦读2010
January 8th, 2011
开卷有益，今年要更上层楼～～
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
达摩流浪者
January 6th, 2011
2010年，世界杯以后，从广州回到北京以后，开着车，又去了很多地方。
在路上的感觉真好。
问题解决型沟通（肆）：基本原则
January 5th, 2011
一次通常的多人参加的沟通，有一些基本的原则，我把它叫做“SOFT原则”：
- Subject：每次沟通应该有且仅有一个主题。如果有多个主题，也许需要不同的人、不同的时间、不同的方式。
- One conversation：任何时间仅有一个人在说话，其他人应该听这个人说。必要时使用令牌。
- Facilitator：应该有一个主持人。主持人应该表现中立：他的任务不是发表观点，而是保证沟通过程顺畅高效。
- Timebox：应该预先设定时间。尽量把主题细分以便控制时间。总用时不要超过两小时。
具体到一次沟通开始时，应该有一个主持人在白板上写下要讨论的主题和计划的时间。如果缺少其中任何一样，你就需要注意：沟通是否以高效的方式在进行。
问题解决型沟通（叁）：促成行动
January 4th, 2011
把问题分析清楚并且找到了解决办法，这经常会使人一下子感到愉快并放松。你长舒一口大气，准备说“散会”──停。如果解决方案没有被实施，那么所有的倾听和分析都将被浪费。你需要确保某些事情发生。
促成行动
“行动”就是把刚才讨论出来的解决方案变成现实的过程。考虑到你已经有了一个清晰并且可操作的计划，这时候不应该有什么事是不可被做到的。但“可以做到”绝不等于“会被做到”（否则这世界早就应该和平了）。你需要确保有人去做。现在。
责任人
必须有一个人对这件事负责。负责的人不必是亲手去做的那个人，甚至不必是直接指挥别人去做的那个人。但他应该成为整个组织中最关心这件事的人──即便他原本不是。通过督促、指挥或者亲自动手，他将确保这件事发生。
确定责任人有两个原则：
- 不允许选不在场的人。必须由在场的某个人接受这个指派。他的责任可以是“把责任转交给不在场的某人”，但不能把责任人直接确定为不在场的人。
- 避免责任人过于集中。当然你可以说“所有事都由项目经理负责”，但这没有意义。让不同的人都来尝试负责某些事，是锻炼团队的机会。
验收计划
这位责任人应该给出一个验收计划：什么时候验收，如何验收。
验收最好以迭代的方式进行，这能更有效地控制风险。
PDCA及其他
问题通常不会一次就搞定，你需要反复 PDCA 。我不展开讲这个内容。
另外胡凯说，行动之后的反馈（赞扬，感谢，或者建设性的意见）也应该是整个循环的一部分。同样不展开讲。
（未完待续…快完了）
