Author Archives: terryyin

上周末去上海参加了一次Scrum聚会。可能是由于组织者的关系吧，其间有很多人是来自诺西、爱立信、华为、阿朗等主流通信企业的，除了中兴，几乎到全了。聚会为期一天，下午是采用open space模式的自由讨论。由参与的人自己发起感兴趣的话题，然后自由分组讨论。因为一直以来都好奇敏捷或者Scrum在其他同类公司中开展的状况，于是我大胆地提出了“通信设备企业Scrum现状”这样一个超级敏感的话题。之所以说它敏感，是因为明眼人一看就知道，这分明就是创造个机会，让平时竞争激烈的对手之间互相刺探公司流程之类的消息。相信与会很多人此行的目的多多少少也在于此:-) 开始大家还是蛮羞涩的，害得我不得不拿起麦克风向会场上80多人做了好几遍广告。你推我拉，半推半就，终于大家坐定了。诺西、华为、阿朗、爱立信，甚至还有前UT的，一个公司一到三名代表，其他人围观。咦！中间怎么还有人录音？赶快关掉！笔记收起来，只准听，不准记！鼓励大家多报料嘛:-) 于是我们开始一个公司一个公司的报料。。。。。 诺西。算是比较早的，在2006年就有小规模的试运行。2007年就有差不多半条产品线全面采用Scrum模式，由传统的瀑布开发模式向敏捷转变。其间经历了很痛苦的过程，在员工之中也引发了大量的抱怨。好在经历了这么多年以后，在讨论的现场就有Product Owner站出来说的确在很多方面有了很大的改进。但即然是半条产品线，那么也很难称为真正的敏捷。就整个公司而言，自09年以来，就有从公司高层传来的明确信息——向敏捷转变。当然，实施还要很长的过程。 华为。较早前就已经有一些团队自发的在采用Scrum开发模式。近两年，变成了自上而下在全公司推行的局面。公司在外面请来大量的Coach帮助产品线和团队进行改进。以华为执行力之高，相信至少在形式上已很成气候。而且员工认同度也比较高，只是觉得压力更大了，开发更紧凑了。当大家问及压力有多大时，一位管理人员讲“不过我们周末已经基本不加班了！”。据说外部压力也是他们采用敏捷的主要动力之一。做为外人我可以想象，因为华为的客户响应效率是其它公司没法比的。还有一个有趣的事情是当大家讨论多site开发的情况时，却发现华为几乎没有这样的问题！大部分团队都在中国，就算不在一个城市，大家大不了暂时搬到一起来。天啊，我们这些外企头痛得不行的问题，对华为来讲却这么简单！ 爱立信。“同一个单子，华为有三十个人扑在上面做，而我们就只能有三个人”，来自己爱立信的兄弟讲，“所以我们只能尽可能的提高我们的效率”。爱立信做为行业的老大，起点就是高。说是人在高处不胜寒，爱立信在向兄弟们学习。其他公司的Scrum或敏捷多多少少都是从中国开始起步的，而爱立信则是由北欧老家萌芽的。爱立信更重视从端到端的敏捷，即从售前到售后整个过程的敏捷。果然立意高远。不过让人怀疑的是，作为行业的老大，爱立信真的有动力去改变么？ 阿朗。阿朗在历史上是多家大公司的组合，同时又收购了很多小公司，于是在不同的产品线的实践也是大不相同的。在其中的一些部门Scrum已经运行得很流畅了。 当我们讨论到“如果发布的日子到了，但是有些不太重要的问题实在改不完了，你们会按原计划发布么？”的时候，大家都笑了。原来大家都差不多。。。。。。 其间有一位“前通信业人士”，现在已成为资深的Scrum coach的Bas Vodde。他对这些公司大都有些接触，我们希望他也能发表一些看法。他认为华为有其它公司无法比拟的一些优势，例如前面提到的多site开发问题。更主要的，他认为那些历史悠久的大公司的一个重要问题就是不愿放弃，也不能放弃的“历史投资”，例如那些老得不能再老的代码，实际上是在拖慢公司的步伐，很难敏捷。而华为这样的公司却没有这样的问题。但他也提到，以目前通信市场上的恶性竞争来看，企业“不得不”为了赶超竞争对手，加快步伐，从而生产更多的“垃圾” code base。而这些“垃圾”转而进一步拖慢企业。在这样的恶性循环当中，即使是华为这样的企业掉入其中，迟早也会面临其他公司同样的问题。 因为这并不是一个通信行业专门的聚会，我的这个话题可能会让非通信行业的朋友们鄙视啦，但没办法，机会难得嘛。另外，能来参与这个活动的基本上都是对Scrum有兴趣或者说是支持者。在这个群体中很难听得到异见，这也是很正常的事情。

这次不知道是不是火星了。 前几天在查资料的时候偶然间发现了一部很另类的网络小说《电子生涯》。之所以说它另类，是因为它的作者显然是一个程序员，而似乎其读者除了程序员也不大可能会有其它人了。小说描写2004年的一个程序员被雷劈到了1966年的美国，然后开始在计算机行业创业的穿越故事。里面充满了计算机软件、硬件，软件工程等术语，以及计算机及其相关数学的发展史。篇幅很长，真不知道作者写这种东西的动力在哪里。其故事有一定的趣味性，但太专业了，除非你对“计算机革命史”真的有兴趣，否则一定找不到太多阅读的乐趣。呵呵，说到计算机革命史，想当年在学校的宿舍里熄灯以后我也是个布道者啊:-) 我是在google“瀑布开发模型”，“Winston Royce”时偶然发现这部小说的，为了写那篇“倒霉的温斯顿•罗伊斯”。后来我读了小说的那个部分。主人公范含想要根据记忆（他的记忆非常准确，因为他的电脑被雷劈到脑子里去了）组织人力在1967年开发现在很流行的数学计算软件matlab，于是他要找到一种开发模式。小说里依然固执的称罗伊斯为瀑布开发模型的创始人，这也是没办法的事，众口铄金啊。里面还比较客观的分析了各种开发方式的利弊，指出瀑布模型是一种不合理的开发方式。我发现作者的确是行业中的明白人，因为他理所当然的帮小说主人公选择了瀑布模型做为他这个项目的开发方式。这样做是非常合理的，因为： 1.所有的风险都是已知的，范含作为一个现代过去的人，对于matlab用都用过了，对于可能的风险一清二楚； 2.所有的需求都已经非常明确，不会有新的，或者变化的需求了； 3.没有市场压力。虽然是个很有市场的软件，但在那个年代，没人指望马上用上这个东西，也没人在做同样的东西； 不知道在现实世界里有没有能满足上面任何一项要求的项目。如果有，那么不用瀑布模型来开发就是傻子。嘿嘿，如果下次有人强调瀑布模型的好处，我就可以说：“大师，你穿越了”。

很多天没写博客啦，因为这几天一直忙着在写一个在线编辑HTML的小工具，用javascript。好多年没用啦，写起来很吃力。现在总算有了个差不多的版本了。嵌入了这段javascript代码的本地HTML文件可以直接在IE里进行编辑并保存。主要是一些表格操作，因此我给它起名叫“tabel”。项目的地址为： http://tabel.googlecode.com 这个工具对你可能没什么用，除非你使用Robot Framework 。Robot Framework是由诺基亚西门子网络（NSN）发起的开源软件，是一个不错的测试自动化工具。正确的使用robot framework可以写出可读性很强的测试脚本，这些测试脚本甚至可以取代需求文档。可以很方便的使用Python或java语言对其进行扩展，适用于从大型嵌入式、分布式系统的功能测试，到有图形界面的桌面系统的用户测试等很多测试领域。NSN很明智的把robot framework开源。因为软件开发中所使用的工具的成败就在于这个工具的成熟度和比软件工程还要长的生命周期，而想要做到这一点，把工具开源是一个好办法。如果它真的是个好工具那么自然会有很多人用它，并不断的改进。甚至在我自己没事时随便写写程序也会使用这个framework进行一下功能测试。 问题是robot framework的test case文件是用HTML写的，里面都是一些表格。要编辑这些test case其实只用到很少的一些HTML编辑功能，如果用word或者open office有点大材小用，而其它的编辑工具似乎也都不太合手。在开发IDE如Eclipse里目前还没有能用的开源所见即所得的HTML编辑插件。于是我就写了这个东西。在打开html文件以后，直接就可以进行编辑和保存，也不用写什么eclipse插件了。 目前，这个小工具还只支持IE（一部分因为IE安全性差）。接下来我还想实现如copy/paste等功能。 希望这个小东西能对和我有一样需求的人有用。

温斯顿•罗伊斯（Winston Royce， 1929–1995）地下有知，一定会感到非常懊恼。因为他被人们公认为是瀑布开发模型的创使人。 几乎所有的讲软件工程的书或文章中提到瀑布模型时都会加上引用“… waterfall model [Royce70] …”。这篇Royce写于1970年的文章被称为“瀑布模型的摇篮”： MANAGING THE DEVELOPMENT OF LARGE SOFTWARE SYSTEMS 如果读一读这篇文章，你会发现，这些引用的人并没有真的花点时间去读一读它。因为Royce的这篇文章只是想说明瀑布模型并不能工作。在文章的最后Royce甚至指出应该采用迭代的方式进行软件开发。 瀑布模型的一个简单的例子就是： 需求分析->可行性分析->高层设计->详细设计->编码->底层测试->系统测试->发布->维护 这样的一个顺序开发模式。 瀑布模型的流行不仅因为他看上去很合理，另一个主要的原因是它受到了美国国防部（Department of Defense）的追捧。后者要求它的合同商采用瀑布模型进行开发。美国国防部的指导精神随之影响到了北大西洋公约组织（NATO），瀑布模型想不流行都不行了。其结果，对美国国防部而言是导致了其超过50%项目的失败。然而与Royce同期甚至更早的软件科学家们更多的提倡迭代开发，如冯·诺依曼。 与瀑布模型同出一辙的“V模型”，其实质都是一样的，是一种理想化了的软件开发模型。对于可预测性强的生产制造业，如生产汽车，的确很适合这种生产模式。然而对于具有很强的不可预测性的新产品开发，如生物学研究、新药的研发等，就不合适了。同软件开发一样，这些研发工作都更适合用迭代的模式来“生长”出来。 在中文维基中“瀑布模型”条目中对Royce对这个模型的供献描述并不准确，去修改了一下： http://zh.wikipedia.org/wiki/瀑布模型 百度百科里仍是把Royce作为瀑布模型的提出者而不加解释，由它去吧。 另，美国国防部已于1994年放弃了瀑布模型。