BlogJava-鼠标的咖啡屋-随笔分类-Agile

初读《Scrum敏捷项目管理》

咖啡屋的鼠标 — Fri, 23 May 2008 02:42:00 GMT

这本书前面部分写了太多关于案例的内容。没有足够形象的讲解Scrum。也没有充分描述Scrum的假设、适应情况和不适应情况。讲Scrum的风格跟微软的讲师讲座倒是真挺像。
书中的Service1st公司的案例跟我们部门的情况极其相似。最后他也没解决，只是说Scrum在现有的形势下带来了什么好处，有些失望。不过仔细想想，这个团队的问题不是软件开发方法的问题，而是企业文化的问题。所以Scrum解决不了是意料之中的。
但是这本书，说实话，不是特别经典的一本书，大概看看吧。

咖啡屋的鼠标 2008-05-23 10:42 发表评论

关于浪费的杂想

咖啡屋的鼠标 — Tue, 20 May 2008 09:57:00 GMT

敏捷是以消除浪费、提高质量为目标的。但是有些时候总能见到一些原教旨主义者指出，重构也是浪费、结对也是浪费、讨论也是浪费。然后呢，又有人提出，XX是必要的浪费这种说法。

想了一下，XX是必要的浪费这个说法其实不确切，只能说，这些东西是必要的成本支出。所谓浪费，必须从经济学角度讲才行。不然世间一切都可以带上这个难看的帽子。从牛博网最近新来的骗银老师那里学来一个概念：“经济学上有个奇怪的概念叫‘冤死的损失’（deadweight loss），英文的直译是‘未被释放出来的能量损失’，那是说，有一部分损失，...”谁也没拿走，“...但因为效率原因，它就那么凭空损失掉了。”
因为听起来很玄，为了让大家更好理解，骗银老师在后面讲的一个非常耳熟能详的例子：
“我雇了一帮人，天天就负责刨坑，刨了然后填上，然后再刨开，再填上（这例子不荒谬，中国随处可见），我发给他们工资，这一来一往国民生产总值（GDP）就上去了。看起来谁也没损失什么，对不对？只是简单的财富转移。其实不然，这里面有巨大的浪费，因为这些钱、这些劳力本来可以用在其他更为有效的生产上，可都用来刨坑了，那就是浪费。”（其实个人这个例子还不够形象，如果挖坑和填坑的不是一批人，他们自己根本就不知道自己做的是浪费的事情，就知道干了活，拿钱，而且还为挖坑和填坑做了很多过程改进，提高工作效率。那就更形象了。）

所以说，您不能因为某些工作做了您能看到效果了，就不称之为浪费，而有些工作做了您看不到效果就称之为浪费了，应当反思一下是不是自己眼界不到。

离职将近，我在交接工作之际，因为我最熟，所以要我把依赖我负责模块的其他模块的适配器类改至新版。自己搬着Mingle写了一些故事卡，又用CC写了一些持续集成的脚本。接下来，我还会去写测试用例。整个过程中，没有一行有效代码的产出。在以代码计绩效的角度看，我的工作就算是浪费。可是，大家应该知道，没有这些东西，先不说我会不会在开发的时候保证质量。就说我离开以后，当产品质量出问题了，谁来保证？我可以根据异常一眼看出问题可能出在哪里，新接手的人能吗？如果他改了程序，能保证不会按下葫芦起来瓢吗？他需要时间去犯错去学习，这个时间，没有产生新的价值，这才是真正的浪费。而且这也就成了挖坑-填坑的模式了。

问题反过来了，我做好这个CI的环境走了，来了一个新人接手，会怎样？一天，系统报异常了。他有我的测试环境，而且，还是可以运行的。他可以很快的写一个测试用例，并开始调试，即便他无法理解整个设计，那不妨碍他快速的修复Bug。而且，因为以前的测试用例可以自动运行，他还可以保证自己的修改不会导致之前的功能出现问题。一个为产品而组织的团队，离开了某个特定的人，产品仍然可以自我完善，能完成这样的目标的手法才是最有价值的。

很多人担心前期花费的时间太多，后期就更没时间，问题又来了。前期花费的时间多，是浪费掉了，还是合理的用掉了？如果是浪费掉了，自然不应该，如果是合理的用掉了，那是必须的。我们学软件工程的时候都学过，一个问题发现的越晚，改正他的成本就越高。后期所谓的没时间，就是因为前期太多问题没有修正。

说道这个前后期的问题就不得不提最近一次结对的经历。在我的坚持下，总算完成了一次与同等水平开发人员的结对编程。持续时间有三天。与同等水平的人结对，感觉是不一样。也发现了很多以前没有发现的问题。这都是个人问题，脱离我本人就没有意义了，所以也就不说了。主要说一下心得。这三天的时间里做了一件什么事呢？推翻以前分成两个模块的应用，合成一个。两个人做一件事，大家可以随时根据今天剩余的时间做工作的调节，精确到小时。因为了解的信息不同，可以快速传递，合作互补，当他提出一方案的时候我可以快速告诉他，我这边没有问题，减少了尝试造成的时间浪费。因为两个人一起做，脑子根本停不下，一个人停了，另一个人还在转，带着你不得不进行。一天的有效工作时间在6小时以上。而分开的话，基本上能有3个小时就不错了。

（中间发生的一点插曲。因为结对开发从不了解的人看来，是一件很浪费时间的事情。所以出现干预结对的现象出现，理由是担心做不完。我觉得，如果不是坚持的话，就真的做不完了。从现实中看来，强调浪费，很容易被偷欢概念。而偷换概念的人很多人都没有做过仔细的考虑。纯粹的想当然。）

咖啡屋的鼠标 2008-05-20 17:57 发表评论

CMMI的最高目标和Agile的世界观

咖啡屋的鼠标 — Fri, 11 Apr 2008 05:55:00 GMT

今天公司过了CMMI 4级，5级没过，听老外讲述什么是5级也就是说什么是持续改进以后，感觉到CMMI的持续改进和Agile的消除浪费其实是一枚硬币的两面，持续改进就是消除浪费，为什么这么说呢？CMMI的持续改进本来就是高级别的过程域，那个时候指望重大变革基本就不靠谱，所以这个时候，看不管哪个行业，都会走向消除浪费的方向，软件开发也不例外。CMMI的持续改进要求一直做一直做，那跟敏捷要求的追求精益的观点是一致的。

CMMI认为通过4级的度量形成了稳定的过程之后，5级就应该是对4级过程的不断改进，什么时候看，都是不满足的，值得修改的。那种精神不正是敏捷的世界观吗？CMMI给出了一堆过程域和目标，并没有告诉我们怎么实现，Agile就更粗狂，不过大家提到Agile其实想到的是XP。所以觉得Agile就是一堆实践而已，没关系，不去争辩这个问题。我就看XP，XP的那12个最佳实践，跟CMMI的思想一点都不矛盾。（细节不可考，因为很多时候我很难清到底是CMMI里面就定好了这细节还是我们的EPG定的）。以前的时候只是粗略的感觉这两者可以不矛盾，现在培训过后，更证实了这点。

============
缩写解释：
Agile 敏捷
CMMI 能力成熟度模型集成
XP 极限编程
EPG 企业过程小组

咖啡屋的鼠标 2008-04-11 13:55 发表评论

web2.0时代也谈在家办公

咖啡屋的鼠标 — Thu, 31 Jan 2008 15:59:00 GMT

今天在首页看了一篇很有意思的博文：谈一谈在家办公的利弊
其实在家办公对我来说是一个很遥远的梦想。但是人总不能放弃梦想啊。也来一个假想吧。
说是假想，其实这些手法也是来源于一些分布式开发的讨论。而在家办公在一定程度上构成了分布的情景。
最早听说分布式开发是一篇讲分布式敏捷的文章，之后一直对这种神奇的开发模式十分向往，也看过一些讨论贴，借着这个话题也来写一些东西，主要考虑一下Web2.0产品对分布式开发可能会有的一些帮助。在那篇文章曾说到分布式开发的基本原则：

异地分布式敏捷软件开发 (Distributed Agile Software Development)

基本原则：极尽交流之能事

异地分布软件开发面临的最大问题是交流问题。随着人员距离的增加，交流效率将大大降低（参见Alistair Cockburn的文章），同时交流成本将极大提高。很多时候on-site一端团队不能把正确的需求传递到off-site一端，这直接造成产品质量的下降。

为了使避免这种情况，应尽量采用一切手段来提高交流的效果。例如，项目经理和团队成员都需要了解其他人的工作状态，一个技巧是可以将你的MSN或Y!名称后缀写上你在做哪一块的需求。并可以随时和同事通过IM进行交流。

（注：可以接触到实际客户的一端一般称为on-site，另一端可相应的称为off-site）
原则说得很到位，总之，无条件的提高交流的效果。在手段上我觉得在web2.0时代，我们有很多更好的工具可以帮助我们进行交流。

首先，对那个MSN和Y！的做法我就不是很同意，相比较的话Twitter不是更好吗？项目组成员一人注册一个Twitter帐号，所有人互相Follow。制定一个制度（先不考虑制度的建立过程）每隔一个小时写一个正在干什么。Twitter不就是干这个的吗？就像Twitter输入框上面写的：“What are you doing？”Twitter还能对话，而且所有的对话都是公开的，方便每个人加入进来，天生是个开放的环境。Twitter还能发到手机上，外出有事也能接到小组成员的工作动态。并且随时插入讨论。当然Twitter毕竟是国外的，可能会有很多问题，比如哪天被盾掉，那么叽歪，饭否也是可以选择的。相传矶歪的功能比Twitter更强大。

接下来我说的更多像是给Google做广告了，但是不管你承不承认，Google这些工具确实很有帮助。
第一个，Google日历，Google日历可以拿来做计划和工作日志，每个人一个日历，项目组再做一个计划日历。每个人的日历写自己的计划和日志，项目组的日历写项目计划和日志。可以帮助项目组跟踪计划和统计工作量。甚至项目经理或组长可以拿日历分配任务。拿任务日历和日志日历跟踪进度情况。

第二个，Google Group，google的这个论坛可以拿来做项目组讨论的地方，每一个发起的讨论都可以记录下来，还避免了平常口头讨论时不容易回溯的问题。但是单纯的GoogleGroup还是比较麻烦的，只有在结合了Google的另一个拳头产品之后，这个手段才是可用的。那就是Gmail。

第三个，没错，Gmail，Gmail中可以直接对Group发帖或对讨论贴进行回复，并且每一个讨论贴都可以折叠和展开起来。同时各个Gmail用户可以直接聊天，聊天记录也可以被保存在Gmail中。一切都是便捷且可回顾的。

第四个，Google Doc，不管我们怎么讨厌文档，大多时候文档是逃不掉的。大家分布的情况下，文档的管理和共享是个问题，但实际上，即便是不分布的时候，我们的文档的管理共享也是问题（我总是在飞鸽上收到大量的文档，导致我的文件夹中文件膨胀速度太快，产生大量垃圾，每次到找的时候总也找不到需要的文档。）。为啥不使用Google Doc呢？文档可以轻松共享，且大家可以协作完成一份文档。且支持版本控制。

第五个，Google NotePad,这是一个很有趣的记事本工具，他有很多种用途，在我看来，他可以做能够共享的TODO List，而且一些点子可以随手记在上面，当哪天差不多了可以导出到Google Doc，我们可以用它来制定自己的计划，并共享给组长或组员。

Google的广告做完了，再来吹吹Adobe的，Adobe推出了一款在线会议室：BRIO，目前还是测试版。
我申请了一个个人会议室试用了一下，还是挺不错的。可以共享桌面、聊天、语音对话、视频，上传文件。这些对于帮助在家办公的人开会是很有帮助的。不过因为外国服务器的关系，速度有点慢。

即便这个东西因为网速等人力不可战胜之原因跑不了，我们还有qq嘛，虽然因为众所周知的原因，用QQ一般是降低工作效率的，不过我们可以申请一个工作用QQ嘛，这样聊天、语音、视频、共享桌面也都全了。而且在twitter的帮助下，配上TDD和持续集成的手法，偷懒应该是很容易被发现的。

以上就是我想到的可以辅助我们在家办公或者说分布式开发的web2.0产品。
===========================
写完之后我到回来想，其实有些用在办公室里也未尝不可。

咖啡屋的鼠标 2008-01-31 23:59 发表评论

Lean与SARA模式-消灭惯性思维

咖啡屋的鼠标 — Mon, 21 Jan 2008 16:29:00 GMT

早在AgileChina上听过关于Lean的只言片语，OpenParty上冲着这个名字于是跑去听路宁的《Lean Thinking with Examples》。
这个Session很有意思，讨论也很激烈，以至于严重超时。虽然听了之后还是对单件流一知半解。即便Google了一些也没完全搞明白这个东西在生产中的价值，以及操作的手法。不过对于Lean--识别和消除浪费的技术（路宁的ppt中还有对浪费的解释：不产生附加值的活动。我个人认为这个解释反而让我糊涂，于是给去掉了。），总算有了一定的初步认识。

路宁在讲演中，一直在强调要考虑端到端、对最终用户价值的重视。这是一个很棒的新思维。我们的思维惯性里，对短板效应比较重视，总是对最短的那个木板进行优化，但是丰田直接把木桶扔掉了。因为在他们的模式里，木桶接水，是一种浪费。这种让人耳目一新的思路，不由得使我想起了郎咸平的那个案例：时装行业的SARA。
他们为了解决3家大工厂和400家小工厂之间的物流问题，建了200公里的地下隧道，用高压空气运输；他们用空运而不是海运；他们款多量少；他们根据销售情况快速反应制作下一个款式；他们从设计到出现在店里的时间（又称前导时间）为12天。而我们国内一般最快的是60天，最慢的能到180天。因为我们会怎么做？3家大工厂与400家小工厂太分散，集中。海运便宜，选海运。一个款式还在热销我傻了我不大量生产？比较来看，我们的手法从常识上来讲似乎是减少了浪费：集中了，更有效率，减少了运输浪费。海运便宜，减少了运输成本，把每一个款式的销售额发挥到了极限。结果，我们的前导时间是他们的几倍甚至十几倍更不要提他们因反应敏捷带来的快速设计新的款式的加成效果了。他们引发了时装界的革命，我们只能恶性竞争，一块死掉。
这就是说，浪费有很多是反常识的。让我们考虑，时装行业，对最终用户来说最大的价值是什么？新潮、时髦的衣服。最好能不要跟人撞衫。
从这个角度上再来看，考虑端到端，最大的浪费是什么？前导时间、同一款式过多的量。现在你再倒回去看Sara模式，他不成功谁成功？咱不失败谁失败？
李剑在session中提到一个故事，一个人外出，准备了各式各样的预防措施，最后走到桥上，桥折断了。这个故事说明，我们经常为了害怕的风险做一些无谓的预测行为，反而变成了浪费。我们要找到我们真正的问题，我们软件开发中，也常常做预测（预先设计），以防项目中会发生的变化措手不及。这本无错，可是我们经常把本质问题扔到一边，热衷于预先设计了。做那么多预先设计不一定能预防项目中发生的变化造成的措手不及，这是一种极大的浪费。（有时候我看到人们对预先设计的热衷，不由得感觉，那有点像对祈雨之舞的迷信，同学们，我们的目的是让他下雨，不是跳舞，当然你一直跳一直跳他总会下雨的，不过你不觉得那是蒙的吗？）我们真正的问题是为了变化不会杀死我们的项目（起码最坏的打算是这样的），别的都是手段而已。再回到sara的例子上，3家大工厂与400家小工厂的分散，从表面上看，不集中会带来浪费。但实际上，真正的问题是不集中会导致物流的不畅通，这个问题解决了，管你集中不集中呢，对吧。集中往往还会因为臃肿而导致效率低下呢。
我们要透过现象看本质，消灭惯性思维。通过这个session，我又一次认识到了这个思维的重要性。。。。。。
=========
附：
路宁Session的报道：
http://www.infoq.com/cn/news/2008/01/lean-2008-beijing

咖啡屋的鼠标 2008-01-22 00:29 发表评论