沙滩阅读记录
March 9th, 2010
Buzz是个好东西。一边玩Buzz，一边抓紧时间看了几本书。
Organizational Patterns 操作性缺缺，看完仍然不知道该怎么实施──甚至不知道能不能实施
说话的魅力 废话超过文化
演说之禅 “胶片”这个词真的很不好，因为它杂糅了幻灯片和讲义
让你的声音更有魅力 系统性和可操作性都太差了，国人写书的通病
还在读 Fearless Change 。原来Linda Rising就是模式年鉴的作者，难怪我听着那么耳熟呢。
Evangelist => Test the Waters => Time for Reflection => Small Successes => Step by Step
Ask for Help, Connector, Guru on Your Side, Innovator, and Just Say Thanks
You’ve had a meeting using the pattern Piggyback or Brown Bag. Perhaps you were able to Do Food and you scheduled the meeting at The Right Time. You brought some interesting books or articles, hoping to Plant the Seeds and point to External Validation for your new idea. You talked about the Next Steps for your fledgling effort and maybe you used e-Forum to help Stay in Touch with people who are getting interested in your work. If you were really lucky, your collection of like-minded folks has started to form a Group Identity.
昨天收到 Strength Finder 2.0 。
You might be especially adept at legal work, crafting sound business deals, or ensuring compliance to regulations.
郭晓说：I am surprised by Harmony!
伤了。
Leadership Over Management
March 5th, 2010
灰色区域是普通员工，蓝色区域是被尊敬的员工，绿色区域是优秀的管理者，红色区域是危险的。
所以，得不到管理职位没什么好着急的，领导力更要紧。
Organizational Pattern: Producers In The Middle
February 26th, 2010
(From Organizational Patterns of Agile Software Development )
In a project, not all roles hear everything. But much of the information communicated has important implications for the product.
Within any software project, there are many activities, roles, and individuals competing for attention. Of course, there are the developers. But project managers have a need to be at the center of everything. They need to have their finger on the pulse of the project; to know everything that is going on. That’s their job. In a similar manner, perhaps to a lesser degree, other roles also need to be involved in the project.
But all roles are not equal. Certain roles (developer and a few others) contribute directly to the product; they create it. Most other roles contribute indirectly to the product; they (should) exist only to help the producers do their job. The producer roles need information in order to do their job.
Therefore,
The producer role(s) must be at the center or very near the center of the hive of communication. Make sure the producers are party to all, or nearly all communication about the project.
Organizational Pattern: Don't Interrupt An Interrupt
February 25th, 2010
(From Organizational Patterns of Agile Software Development )
It’s important to balance a desire that SOMEONE ALWAYS MAKES PROGRESS (4.1.20) with the thrashing that can accompany short-term priority calls. One worker will inevitably be blocked on you—you can’t do both things at once. Complete, omniscient foresight and scheduling are unreasonable to expect.
Therefore:
If a developer is already working in “interrupt mode” on a critical issue, don’t put that work aside until it is complete or until that issue itself becomes hopelessly tangled.
Organizational Pattern: Day Care
February 25th, 2010
(From Organizational Patterns of Agile Software Development )
Your experts are spending all their time mentoring novices.
You begin to hear things like “We are wasting our experts,” or “A few experts could do the whole project faster.” Indeed, the experts are not proceeding at the rate you or they would expect, because training the new people is draining their energy, time and concentration. But the new people must be trained, by experts, of course.
At the same time, you must make progress on the project itself.
Therefore:
Put one expert in charge of all the novices, let the others develop the system.
Separate an experts-only “progress” team from a training team under the tutelage of one or more mentors. Select the mentors for their ability to teach design and programming (object-oriented design and programming, for example) to novices. Let the progress team design 85-95% of the system, let the training team focus on quality training, delivering only 5-15% part of the system. Transfer people to the progress team as they become able to contribute meaningfully.
Make sure that the training team does not simply do training exercises, but actually contributes to the final system in an ever-increasing way.
If you have many people to train (more than, say, six), you will have to design a series of tasks for them to attempt. Otherwise you may give them a small, real part of the main system to design.
If the people in the training team are the ones who know the domain, you will have to make some further adjustment, or else the division may cause conflict.
[zz]Agile Metrics
February 8th, 2010
借鉴丰田方法对大型软件组织进行敏捷改造（提纲）
January 18th, 2010
本文以某大型电信设备提供商与ThoughtWorks合作的案例为基础，介绍如何采用丰田倡导的精益生产方法对大型软件组织进行敏捷改造。在这个咨询项目中，ThoughtWorks咨询师引入的精益理念包括：
- 5S
- 自働化
- 现场管理
- 湖水和岩石
- 造物先造人
以这些精益理念结合敏捷实践，贯彻PDCA/SDCA实施策略，在四个月的时间里，成功地对一支超过百人的交付团队完成了初步敏捷改造。
三十了，许愿吧
December 31st, 2009
转过年，就三十岁了。
（感叹的话全都不说了。三十岁的男人要沉稳内敛，嗯嗯。）
我想亲身经历一家重要企业的精益变迁，并且在其中扮演重要的角色。
我想把已有的技术磨练得更精熟，又学会新的技术做出新的东西。
我想变得更可靠更教人安心，同时更自信而不恐慌。
就是这样了。很简单的愿望。很大的愿望。
是的，我想要流程改进…
December 20th, 2009
…只要“被改进”的不是我。
到底有多少人怀着这样的念头呢？
给某知名互联网企业做了一个草草的价值流分析。这家企业和同集团的几家姊妹企业最近都在热火朝天地搞敏捷。培训，项目试点，经验分享，宣讲推广，还打算要制定流程规范。一级一级把成果和经验报上去，领导都很支持。业务线的领导说，交付线的同学们多搞搞敏捷，交付能力强了，咱们公司就能更好地应对顾客们的需求了…
等等。这话为什么让我胃里一抽呢？
十分钟画出的价值流图告诉我们，一个用户需求从被客户服务部门收集到，直到成为一个新特性上线供用户使用，lead time总计2个月又20天（约合58个工作日），process time约20个工作日。Muda在这个流程中占65%。
那么交付线到底浪费了多少呢？嗯，交付线的lead time共计17个工作日，process time共计10个工作日。
换句话说，就算这家公司得到了一根魔杖，只要魔杖一挥就能把用户需求变成可用的特性，他们也不可能在两个月内响应用户需求，如果业务线没有“被改进”的觉悟的话。
所有人都在讲流程改进。所有人都在讲敏捷讲精益。你真的准备好了吗？流程改进的结果，真的是你想要的吗？得到一个精益流程所需的决心和勇气，你已经有了吗？
用系统图分析一种常见现象
December 11th, 2009
这是一个“舍本逐末”的系统基模。
上面的环路代表快速见效的症状解，它迅速解决问题症状，但只是暂时的。下面的环路包含了时间延滞，它代表较根本的解决方案，但其效果要较长的时间才会显现出来。然而它可能是惟一持久见效的方式。有时候舍本逐末的结构中，会多出一个由症状解所带来的副作用所形成的增强环路。发生这样的情形时，副作用常使问题更难以解决。想要扭转舍本逐末的情势，需要增强治本的反应与减弱治标的反应。组织的特性常显示在如何处理舍本逐末情势的能力上。
增强治本的反应总是需要一个长期与共有的“愿景”。企业如果不能建立长期不断创新的愿景，那么暂时解决短期问题的策略将取得主控地位。
减弱治标的反应，需要诚实地说出那些“症状解”的真相。有时采用症状解有其必要性，但必须认清那只是为了纾缓痛苦症状的权宜之计，此时最容易忽略的是，一旦压力纾缓，就停止寻找根本的努力。
