路宁(luning)的博客

有一个新入职的Dev，每次开发完一个功能后就叫上QA到自己的机器上来测试，并不像大多数Dev一样发起正式的提测流程。

他这么做一方面是因为担心自己开发的质量差，正式提测后的Bug被记录下来，影响他的KPI表现。另一方面是正式提测如果有问题还要打回来，来回走流程费劲。

QA起初积极配合，但后来发现这么做对自己很不利，无法在领导那里体现自己的工作。因为QA是根据Dev的提测计划制定自己的测试计划，QA经理主要根据测试计划及执行情况来了解手下人的工作。不仅如此，这样做还会影响自己的一项KPI：漏测率。漏测率是指上线后发现的Bug数除以总Bug数，如果记录的Bug基数少了，漏测率极易上升。

QA反应过来这个问题后就不再配合了。Dev嫌QA变默唧了，QA 反过来嫌Dev懒，让他正式提测。两边合作不愉快，就开始找“流程”帮忙，沟通少了，一切走邮件，走流程。

Dev 感觉QA 让他名下的Bug多了，搞得自己在Dev经理面前很没面子，和QA说话时自然没什么好语气。QA 心里也不顺，本来没多大的事，搞得默默唧唧的。

最终的解决办法是，走流程，你在系统里提测，我才测试，有问题记录Bug，依赖Bug跟踪系统......

哈哈，有意思吧。你能说这个Dev或QA不够好吗？不是。

不管出于什么动机，他们确实发现了一个更高效的合作方式，但却被“流行的组织结构”，“僵化的KPI”，和“万能的流程”无情地打击了......

我最近Lead一个QuickStart，第三周编写Story，这一周就像是整个项目的缩影，它让我看到了项目的未来：屈服于压力，不尊重实际的速度，迷信业务的承诺，轻信自己的判断，后期加班，项目延期。

我和一个BA想用一周时间（本周有7个工作日）把Story都做出来，并制定交付计划。之所以是一周，是因为第二周要做汇报。开始比较乐观，认为Story可以很快产出。

周一：
只做了30个Story，比预期的少了近一半，但一想只花了半天做Story，以后应可以补回来。

周二：
做了28个，远少于预期，因为今天又有别的事，不能全力做Story，也许明天会好些。

周三：
做了34个，今天多了些，但感觉Story的总量会比预期多不少。我们反思了一下，业务（客户）的支持不足是最大问题。心想，如果业务一直在身边，写起Story肯定神速。于是争取了一下，业务承诺每天10点至少支持我们2小时。

周四：
业务如约来支持我们，但主要是Review做好的Story，没写新的。下午业务开会，还是我们自己写Story，今天完成40个。

周五：
业务没有来，因为他每天都工作到凌晨3点，虽然承诺10点到公司，但11点还在自家床上呢。看来只能加班适应他的时间了。今天做了33个。

周六：
我们11点多才到公司，就是准备晚上陪业务加班。加上加班的2个多小时，共写了42个，并没有预期的50～60个那么多，原因是“软柿子”都被我们捏过了，剩下的都是复杂的需求了。

周日：
一早我和老大分析了一下，决定推迟汇报的日期。业务那哥们今天大部分时间都在支持我们，但由于剩下的都是复杂的逻辑，今天只做了40多个。

一周回顾：
一开始根据汇报的时间点做了乐观的估计。3天后有了实际的“速度”，但迫于压力没有据此调整预期，因为还梦想着业务会支持我们并大大提高生产率。后来发现业务近两天不可能提供全面支持，于是决定加班。之后又发现即使业务支持了，速度也未必明显提高。最后决定延期交付。

哈哈，整个过程俨然就是将来项目的缩影，该犯的错误是一定要犯地！

 

Burn down chart and story wall are often used in agile project for visualizing the status and progress of project. They should be designed to visualize smell easily as well.

Smell is sometime made less visible unintentionally. We probably did things as below:

• Enlarge the wall for more cards.
  The wall then became more 'smell tolerant'. Problems are hard to identify.
   
• Categorize bugs so that we can manage more.
  Feeling of bugs being well organized weakens the strength of the will to fix them soon. The count of half done stories may increase with the bugs.

 
So, in order to resist the tendency, we can try:

• End-to-end evaluating, keep goal in mind.
   
• Make it brittle for even small problems. Here 'it' fits for process, story wall and more.
   
• Keep it simple, less is more.
   

 

前些天，客户的一个经理问我，来到ThoughtWorks前后自己有什么变化，当时说的都是和工作相关的，今天突然想记录一下自己在日常生活中观点的变化，这些都直接或间接地受到敏捷和精益思想的影响。

• 以前习惯每周坐车去大超市买一大堆吃的回家，买的时候都挺新鲜，吃得时候要留意一下是否已经烂了。现在更多是在楼下的小超市买东西，哪怕会有点贵。
   
• 以前溜达到超市库房，看到工人们忙碌在堆积如山的商品前装卸，觉得挺有意思。现在心里却想，老子付的账还要给这库房买单，还要给“装箱”、“拆箱”这类无聊的动作买单，心里不甘。
   
• 以前心理想着“十年磨一剑”，等我牛了之后吓死你们。现在琢磨出点东西就想到处去显摆。
   
• 大学四年，尽管大部分知识在工作上都用不上，但觉得这些知识对我应该是有些潜移默化的影响的。现在看来，这种想法就是扯淡，是给目前的高等教育找借口，学习本来就是一辈子的事，需要啥就学啥，用不上的东西就是浪费。
   
• 以前喜欢用大钱包，有用没用的都往里装。现在用一个极小的钱包，除了钱，只有两张卡和一个省份证。
   
• 以前攒一周的脏衣服，周末一起洗，现在天天都想洗，只是后悔买了那个5.5升的洗衣机，太费水了，很多只能手洗了。如果能有一个小的洗衣机，然后和邻居共用一个大的就完美了。
   
• 以前搬家的时候这个不舍得扔那个不舍得丢。最近一次搬家，东西扔的真痛快。去年春节回老家，真想把家里的“垃圾”都扔了，可是没法说服父母。我爸连我小学时候用的课本都不肯扔，说是要留给我未来的儿子用，汗。
   
• 以前到银行，在超市，深信“排队”是一种美德，现在更多的时候是在想“为什么还要让我排队啊”。
   
• 以前总觉得北京这三环四环不够宽。现在感觉很多路根本没利用上，很多“大院”、“小区”对公共交通一点贡献都没有。
   
• 以前感觉有个××商业中心、××展览中心和××CBD挺好。现在听到“中心”、“集中”这样的字眼心里就烦，好好的交通就坏在这些中心上了。

 

我说上面这些变化都和敏捷和精益有关，你信么？

回顾会议中的Safety Check

在敏捷项目回顾会议正式开始之前，我们有时会做个匿名的“Safefy Check” ，以了解大家在分享自己的想法时是否有“安全感”。一般分5个等级，1代表“我会微笑，说事情进展的不错，并同意经理的所有看法”，5代表“愿意敞开谈任何问题”。

这样做是让大家认识到，每个人心里的安全感是不一样的，组织者会据此变换会议的形式，以确保在达到会议效果的同时不让任何人感觉不舒服。

项目组中的Safety Check

同样的，在项目组中，每个人也都有自己的“安全感”等级。让我们试着回答下面的问题（每个问题的前一个选择表示你在团队中有较高的“安全感”）：

• 你是否愿意及时表达自己的意见，而不必担心会被指为是幼稚的想法。
• 在有疑问时，你是否愿意在第一时间找到对此问题最熟悉的人寻求帮助，而不管他/她是谁，也无需担心被鄙视。
• 在你做一些自己没有把握的尝试时，得到的常常是鼓励与指导，还是阻力或质疑。
• 在你做一个选择或决策时，考虑的是对整个团队是否有价值，还是更在意给项目经理或某一个人留下的印象。

对上面问题的回答可以反映出成员在项目组中的“安全感” 级别。当安全感等级较高时，团队的能动性和创造力可以被充分激发出来，团队成员工作起来也开心，幸福。相反，较低的安全感让人感觉压抑，要处处小心。“安全感”是主观的，无法强加的，也是团队建设的重要方面。

你在项目组中有“安全感”吗？

修bug时我们都有这样的经历：简单查看了一下代码，发现没有那个类负责这个逻辑，进一步深入代码，查找一番，才在一个看似不相关的地方找到了错误的根源。原来这个逻辑被散落在几个地方，隐讳地错误实现了。我们在出错的地方多加一个if else，或是写点别的什么代码，这个bug就这样被fix了。

仅仅这样做虽然提高了软件的外部质量，但对内部质量的提高毫无益处，泄漏在外的逻辑不仅仍然无家可归，而且有变得越加复杂和晦涩的倾向。

每一个bug的出现都是对分析、设计和编码过程的一次质疑。这次......

Unit tests have many benefits, they are usually expressed as:
* ensure existing logics during developing
* drive out design
* documentation of requirements

Another big benefit is making smell code more smeller, brave developer...

    准时化生产（Just In Time）是精益生产（Lean Production）和丰田生产系统（Toyota Production System）中的概念，其目的是在合适的时间生产合适数量的满足客户需求的产品。它充分体现了从客户价值出发组织生产运营系统的观点，是一种先进的生产方式，为包括丰田、戴尔等众多世界500强企业的成功奠定了基础。
    软件开发组织从一开始就在向制造业借鉴和学习，并形成了各种不同的开发方...

    敏捷开发中有一种实践是结对编程（Pair Programing），指的是两个人坐在一起共同开发一项任务，这样做的目的常常被解释为便于传递知识，提高软件质量。

    结对的两个人是需要经常换的，不同的团队往往有不同的Switch策略。有的做完一个Story再换，一般要2、3天或更长；有的团队每1、2天换一次，不管有没有做完Story；有的团队确保每个Story有一个Owner，他始终不离开这个Story；还有的...

前天公司组织了一次非正式的讨论，关于如何创建一个鼓励创新的工作环境。

ThoughtWorks非常重视创新，并视其为保持其行业领导力和文化的重要因素。北京分公司也曾经有同事有很好的技术创新，并开发出了软件工具，但从增个公司的角度看还不够理想，现在的问题是公司如何创造出一个更好的鼓励创新的环境，让大家在工作中发现和培养具有创意的想法，让这些想法有机会进一步发展，创造更多的价值。

下面是我的一些想法：

* 不要给创新的点子投票（Don't...

从敏捷软件开发的角度分析丰田生产系统的各种实践。

The presentation I gived in the pre-sale activity.
http://luning12.blogbus.com/files/12068545210.ppt
...

[本文发表于《程序员》杂志2008年第3期] 

      戴尔电脑在应用了精益之后，2001年库存周转64次，比最大的竞争对手多50次，运营成本则比其降低了一半以上。那些成功应用了精益的软件开发项目，在初期就开始向客户交付可以运行的软件，并使其创造价值，之后每个月都能向客户交付一组可运行的完整功能，软件也更加符合用户的真实需求。

    精益思想是从顾客端开始，由此往回推，把任何不能为顾客创造价值的活动定义为浪费，并以消除浪费为主要手段使成本、...

消除浪费 浪费往往是通过价值流的流动和拉动过程使其浮出水面的，各行各业都有不同的办法来消除浪费，有趣的是，不同行业采用的方法出奇地相似。TPS中有“单件流生产方式”，敏捷有“迭代式开发”；TPS中有“看板”，敏捷中有“故事卡”；TPS中有“人性的自动化”，敏捷中有“持续集成”；TPS和敏捷都强调全能小团队……
...

从软件开发的角度介绍精益思想

    单元测试可以确保代码的局部行为是按照设计意图实现的，但单元测试只能覆盖一部分逻辑，还有些逻辑需要引入集成测试。尽管如此，很多bug还是 很难被各类测试覆盖，此时系统就特别依仗良好的设计了，良好的设计简化单元测试，让深层的逻辑变得简单，进而让更多的逻辑变得可测。糟糕的设计让单元测试 成为负担，而且往往导致重复的测试和难以理解的测试。
    这里说的良好设计当然就是指简单设计，但有时“简单”二字...

    沟通，反馈，简单，勇气，尊敬是敏捷开发的五个价值观， 它们深刻地反映了当前软件开发组织中相对缺少但又对团队建设和成功交付至关重要的东西。

    里我想聊聊反馈，但并不讨论关于反馈的全部，主要是集中在对“想”与“做”的节奏的探讨。

    馈是我认为最特别的一个价值观。实际上，做很多事情，我们总是重复着&ldqu...

    前些天在程序员杂志上看到同门大师兄WPC的文章"Javascript程序调试 - 不调之调”，有些感触，文章通过诙谐的语言讲述了作者在Thoughtworks工作时处理Javascrip调试问题的对策 - 通过应用Selenium页面测试工具来减弱甚至消除对调试的需要。

    其实，敏捷开发推荐的测试驱动开发对于跟踪调试的态度正是“不调之调”，跟踪调试在绝大多...