路宁(luning)的博客

我最近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

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

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

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

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

最近的一个Web项目大部分的逻辑都是客户端页面逻辑，主要是通过Javascript实现的，如何进行高覆盖率的单元测试是我们面临的一个问题。

分 析一下，有两种逻辑需要测试，一个是与服务器交互的页面操作，比如提交表单后跳转到另一个页面，这很适合写Selenium测试。这里关注的是另外一种， 即客户端页面逻辑，它与服务器没有交互，比如页面Dom元素的联动变化和数据校验逻辑等，这部分当然也可以写Selenium来测，而且由于不与服务器打 交道，组织得当的话速度也很快。但此时Selenium测试与代码实现的反馈距离太远，不方便组织细粒度的测试，更重要的是写这个测试对 Javascript代码的设计没什么帮助，因为再烂的Javascript实现可以方便地写出Selenium测试。

对于客户端页面逻辑，我们尝试使用Jsunit进行测试。对于没有Dom操作的纯Javascript函数，测试很容易。对于有一定复杂度并有Dom操作的逻辑，我们将他们封装成Javascript对象并用Jsunit测试它。

一个具体的例子

上图是页面的一部分......

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

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

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

Q:单元测试的主要作用有哪些?

A:单元测试的作用主要有：
   (1) 确保代码实现了预想的逻辑。这是所有测试都有的，也是最重要的功能。
   (2) 确保重构不破坏现有的功能。所有测试都或多或少地支持这一功能，有些“重构不友好”的测试在重构过程中可能会被删除或修改。
   (3) 驱动出设计，主要是帮助识别出类或接口函数。这是个一次性的好处，只有部分测试会起到这个作用。那些直接保证内部函数实现逻辑的测试起不到这个作用。
   (4) 当难以编写满意的测试时，提示开发人员现有设计的问题并鼓励他们重构现有的代码。这也是个一次性的好处，只有部分测试会起到这个作用。
   (5) 作为需求文......

    前些天在InfoQ中文站上发表了《软件开发中的准时化生产》一文，它是在我的一篇同名博文基础上修改而成的。李剑指出了原文中的很多问题，并给了我不少建议，新文章在内容、结构和语言上有了不少改进。

    文章简介：

• 在软件开发过程中进行频繁的交付，以此减少库存（部分完成的工作），暴露并消除浪费，加快价值的流动。
• 通过客户来拉动开发过程，确保每一时刻团队成员都在围绕客户认为最重要的软件功能展开工作。
• 在第一时间、第一现场发现问题，并从根本上解决问题，以此将质量内建在分析、设计和开发的过程中，而非依赖后期检测来保证质量。
• 将与项目相关的所有人组成高度授权的团队，通过可视化地向团队成员全面展示项目信息来支持自我决策。
• 当改进流程和实践时，要以快速交付和高质量为首要目标，而成本则要端到端地考量，低成本往往是实现快速交付与高质量的自然结果。

【本文发表于《程序员》杂志2008年第7期，是在《频繁的Switch Pair是一种浪 费吗？》一文的基础上修改而成的。】