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

从另一个角度看敏捷实践（二）－－Retro：忏悔与改进

咖啡屋的鼠标 — Sun, 13 Nov 2011 08:14:00 GMT

题外话：我其实想说的是一个被人所忽视的问题。形式有没有价值？我承认，形式化是不好的。但是这个世界有个东西，叫做仪式。
举个例子，在国外，有种组织叫兄弟会，（电影里很常见）他们的有些会设置很多可笑的考察仪式来考察你够不够入会的资格。有些会有危险，有些只是纯粹搞出些恐怖气氛吓你看你会不会被吓退。这种东西有价值吗？心理学告诉我们，设置准入门槛可以提高组织成员的忠诚度。如果你觉得这玩艺太可笑了，给取消掉。你会莫名其妙的发现后来加入的人对组织的认可度忠诚度都不高。这就是仪式的价值。

今天说的是Retro，全名retrospective，中文名“回顾会议”，网上有很多相关文章，就不再这里赘述了。这里提到的Retro是最常见的一种模式，分Well, Less Well, Puzzle三个维度的模式。该模式的Retro的特点是会让我们更多的关注less well，关注我们做的不好的那些。这点有好有坏。本文只揭示它好的一面。做为补充，还有一种海星图的模式，感兴趣的人可以自己查询。

我个人认为retro是敏捷开发中很重要的一道防线。是团队健康度的晴雨表，是沟通的桥梁，是共识建立的契机，是改进的开始。

对于团队本身就存在大量问题，而这些问题可能都在敏捷方法的问题域里时。Retro是一个很好的发力点。他的效果可能没有持续集成那么立竿见影，往往是润物细无声。他可以帮我们把痛点暴露出来，但是不一定是根本问题。就像医生看病也得先问你哪不舒服。而Retro就能帮团队说出来哪不舒服并达成共识。某种意义上讲，它是个报警器。

如果已经采用了大量敏捷实践的团队呢？比如我们团队，在我们团队的开发中，我们一直推进着各种改进，期望让我们的工作更有效率，交付更多价值，同时也让我们的生活更美好一些，这是一件双赢的事情。可是我们也要看到改进是需要成本的，而且也是有风险的，所以有的时候难以推动。对于客户（有时是PM等内部角色）来说，他讨厌一切成本和风险，而更感兴趣的是新功能，当碰到短视的负责人，或者交付压力占了上风的时候，难以推动这点感觉尤为明显。不过商业社会里竞争如此激烈，这也无可厚非。虽然我们也知道出来混，欠下的迟早是要还的。

不过这不是我们今天讨论的角度。今天我们站在推动改进的角度来看这个问题，开发时，在开发第一线的我们往往是第一个了发现开发中的问题，然后我们会发现改进最困难的是沟通，明明这是个问题，但是让各方都接受这个问题并改进它需要证据，需要沟通，需要资源，最重要的需要时间。我曾眼睁睁得看着客户只是加几台机器提升持续集成的构建效率这件事竟然推动了近一年才成功，那么在这个问题被发现但不能改进的时间里，团队会怎样呢？首先士气会被打击，接着如果问题长期不能解决并影响了工作效率，一种不愿追求卓越的气氛会渐渐感染团队成员，进而使得大家会在其他实践上表现渐渐变差。（相对于每个人自己，而不是团队其他成员）改进的意愿也会不同程度的变低。这符合破窗效应。

这时候，很容易出现的一个倾向会是干脆我们不要retro了，反正也改进不了，完全是浪费时间。这就成了自毁长城。不能干因为报警器老响就把报警器拆了的事。出来混欠下的始终要还，学鸵鸟是没用的。当retro不能给我们提供更多实际改进价值的时候，它还能提供最后一个价值：忏悔的仪式。

曾经一直不明白西方人为什么定期去教堂忏悔，周周去，周周都有值得忏悔的，甚至犯过的错还有很多类似的。看起来没什么用。但这就像房间，天天打扫天天都有的打扫的，心灵的房间也是一样。一位有信仰的朋友告诉我，定期经常向神忏悔会更愿意改进自己，如果一段时间不去对自己的要求就会放松。人的心理就是这么奇怪。这揭示了一个道理，人是会逐渐放松对自己的要求的，所以需要一种手段让我们保持对自己的高标准。

我个人认为retro就是一个很好的手段。尤其我前面说过了，这里讨论的这种Retro的模式的特点就是让我们更关注于Less Well。定期，经常，回顾，反思。当我们无法变得更好的时候可以帮助我们反观团队自身，不要变得更差。让破窗效应难以发生。

（本来只是想写一个敏捷团队碰到让人沮丧的情况时Retro提供的价值，结果越写越多，有点跑题了⋯⋯）

咖啡屋的鼠标 2011-11-13 16:14 发表评论

从另一个角度看敏捷实践（一）－－IPM：承诺的仪式

咖啡屋的鼠标 — Thu, 15 Sep 2011 15:25:00 GMT

在我们的开发中，有些实践的价值是容易感受到的，比如重构，比如TDD，比如持续集成。
有些实践的价值则不容易感受到，比如Retro（回顾会议），比如IPM（迭代计划会议）。
以IPM为例，在我们的IPM上我们一般会做两件事Kick off cards和Estimation。也就是选择下个迭代要做的卡和评估每张卡的点数。这两件事情似乎第一件事没必要所有人都参与，第二件事感觉一定程度上是瞎蒙，尤其是一群人来蒙，显得尤为的不靠铺。而且似乎我们IPM就是为了选出下个迭代能做完的卡，就是为了知识传递，就是为了给客户可视的数据和计划，让他们心理好过。
假设说我们不必所有人都参与就能保证选出适合下个迭代做的卡，我们通过每日Code Review等实践使得每个人都不会缺少相关卡的知识，而客户也不特别在意我们的进度（或者说我们的进度他们总是满意），是不是我们就不需要IPM了？是不是我们就不需要集体Estimation不需要集体Kick off了？
实际上，我们的项目就符合前面的假设，在项目的最后，我们真的取消了IPM。这时，才感觉出来IPM的价值。
整个团队的效率慢慢开始下降。对于目标的理解开始不一致。虽然团队整体的表现并不差，虽然没有出现任何实质的问题，但容忍度低的人开始不舒服。跟团队自己以前的状态比，确实有点退化的感觉。怎么会这样呢？
每当说到这种状态出现在敏捷团队中的时候，我最常听到就是人的问题，态度问题等等说法。其实我一直觉得，如果追究态度，空谈人的问题有用的话，我朝应该是世界第一而不是那个人人自我的美帝。人一直是有问题的，不然要管理学干什么？敏捷里提倡自组织团队，自我管理。但决不是松散组织，不管理。自组织它也需要组织，自我管理它也是管理。像IPM这样的活动，就是管理的一部分。
IPM上做的两件事，看起来完全不靠铺，实际上却非常有价值。整个IPM活动就是一个承诺的仪式。像古代行军打仗前的誓师大会一样，可以调动起团队在下一个迭代中的士气。通过集体参与评估和制定计划，通过各个角色的共同作用，使得每个人都参与到整个计划制定中来。自然而然的对下一个迭代许下承诺。而承诺一旦许下，就会像一个耳语的恶魔，暗中催促着人们的行为与其保持一致。
生活在我朝的人们，似乎对承诺这个东西的效果是完全不相信的。这也难怪，不过出于众所周知的原因，咱不谈我们为啥不信任承诺。从心理学的角度，承诺是有实际意义的。《影响力》“第三章承诺和一致”中就讲了这个极为简单却极为有用的心理学原理：人人都有一种言行一致（同时也显得言行一致）的愿望。其中有很多很有趣的实验，揭示了承诺的力量。感兴趣的人推荐读一读。里面有个小例子提到，两个星期前一个愿意在自家的草地上插一个小牌子为交通安全做点贡献的小承诺，使得该社区76％的人都在两个星期后接受了在自家草地上插一个挡风景的大牌子的请求。而对照社区只有17％。巨大的反差可以让我们看到承诺的力量。
当然我们对承诺的不信任也是有道理的，当承诺真的难以完成的时候，几乎所有人都会违背承诺。在传统的瀑布式开发过程中，使得计划这种承诺难度大大上升，而可信度也就大大下降。这也是为什么我们需要迭代的原因。

咖啡屋的鼠标 2011-09-15 23:25 发表评论

积累

咖啡屋的鼠标 — Sun, 17 Oct 2010 07:52:00 GMT

一个成功的企业需要积累。当你坐在电脑旁，看着一个运行达十年之久的软件的源码时，相信我，你一定会更深刻的感受到积累这个词，确确实实是个中性词。

软件多种多样的功能支撑着一个企业帝国的运转，它源源不断的在为这个帝国创造着财富，毫无疑问它随着时间积累了很多挣钱的能力。可是如同历史上其他的帝国一样，在繁华的背后，很多黑暗的东西同样随着时间积累了下来，临时性的策略被固化在核心流程中，为扩展留下的空白成了每次扩展必须绕行的弯路，精妙的手法随着时间的变迁显得复杂过时，分工协作使得同样事情得处理方式大不相同，预先的设计又使得本不相同的东西硬造成了相同的样子，管理的疏忽使得简单的功能用了复杂的模式实现。

坐在代码面前，仿佛在读一本被囚禁了灵魂的魔书，你能在注释中读出兴奋与痛苦，你能在代码中看到骄傲与彷徨。每当完成一次重构就像解救了一个被困的灵魂。那代码又仿佛一个人的脸，你可以看到各个技术历史阶段在它脸上留下的岁月痕迹。畅游在代码中，有些时候我们好像穿梭在时光的河流中，你能看到一个愚昧的风格是如何从一个有价值的需求中演变而来。如今再看，仿佛一群羊在不断的跳过一个早已不存在的栅栏一样诡异。而有些时候，我们只能看到一些遗迹，原野中矗立的大石柱根本无法自己告诉我们他们到底是为何矗立在那里的。以及移动他们会不会带来什么灾难。

能力很强，问题很多。是任何一个已经有历史的公司都会有的。软件不过是公司的一个表现方面。就像一个拥有完整公司基因的细胞。准确的说，任何时候，任何公司都不可能没有问题的。但是何时解决？这个问题就跟什么时候重构一样，答案也是一样，随时。解决问题的时机会影响解决问题的难度。越晚解决，就越难解决。说起来容易，做起来谈何容易。是的，解决问题总是需要鼓励的，但是谈何容易四个字却很容易瓦解我们前进的意志。低下头埋到土里，是可以让一切都清静了。但不管我们做不做，甚至于即便我们在做，问题也永远不会停止它产生并进化的脚步。面对问题，只有应战，没有第二条路可以走。经济危机教会了很多企业只顾赚钱而忽略企业的问题会有什么后果。我相信有很多人会选择遗忘并在遥远的未来继续重犯同样的错误，但是我也相信，也会有很多人会选择记住并把教训提炼成一种知识或制度，让后世人学会警惕。

咖啡屋的鼠标 2010-10-17 15:52 发表评论

敏捷将亡

咖啡屋的鼠标 — Fri, 11 Jun 2010 09:44:00 GMT

        进来听闻最大的CMM堡垒DNV要搞敏捷。大票的猎头纷纷出动，四处搜罗敏捷咨询师。使敏捷这个本来只有小众在实践的一类开发方法陡然变得要大众化了。本来以为是件好事。却在昨天看到z叔大喊，敏捷要倒。当时只是觉得有点道理。晚些时候却切身体会到了。
        收到某非知名公司举办的scrum培训的邮件。顿时心里一紧。在这个时间，用这个操作手法有点可怕，各培训公司都找到了敏捷里面最好切入的一个点---Scrum。
        Scrum是个筐，什么都能往里装啊。为什么这么说呢，他并不能算是一个完整的开发方法。只是一个框架。不领会敏捷的精神，没有其他具体的开发方法，他只能是一个大面的东西，如果用上这种东西就号称敏捷了。那真是可怕。而且，scrum证书也在这波浪潮中量产。一个人，花几千块钱，上两天的课，拿着一张纸就号称敏捷了。没办法，谁让咱们崇拜证书这种看得见摸得着的东西呢。但这样大量量产出来的敏捷项目经理。一实践肯定不对劲，就会用自己的理解去曲解敏捷。然后大家认为敏捷就是早晨开个会，月末开个会。最后的结果就是你在骂敏捷，我在夸敏捷，可是你嘴里的敏捷和我嘴里的敏捷根本就不是一个东西。
        记得曾经见过一个CMMI的咨询师，张口闭口卡耐基梅隆，一付兄弟当年在英国的时候的样子。生搬硬套的CMMI流程。最后搞的那套流程根本不可操作，大家都为流程凑数据。当下如果大家都从CMMI倒向Scrum，这种人咋生存呢？会挂掉？错，摇身一变，举起敏捷大旗开始摇旗呐喊。没这两下子怎么能在忽悠界纵横这么多年呢。像这样的人都来搞敏捷了。敏捷不臭，那除非老天开眼了。那原来搞敏捷的人呢？本来就是小众，在这大浪里面，估计很快就看不见了。。。。从今开始，我还是少说两句敏捷了。。。

咖啡屋的鼠标 2010-06-11 17:44 发表评论

我眼中的软件开发

咖啡屋的鼠标 — Thu, 15 Apr 2010 08:38:00 GMT

这篇文章是受启发于要求我写一些设计和spec的文档的面试要求。趁这个机会整理整理自己的思路。

什么是软件开发呢，最常见的一种说法是，软件开发是一门艺术。我觉得更现实的讲，软件开发应该是一种生产。跟其他所有的生产一样。要考虑成本和收益。收益这块，跟其他很多外部因素相关，对开发者或者说开发者的管理者来说无法控制，开发者从职业的角度出发更多需要考虑的是成本。这也是我们职业的目标。

软件这种产品的生产，材料本身的损耗也就是电脑，电费，基本属于沉没成本。不会因为咱们任何努力而改变。（也不是完全不能改变，只能是变多。。。。）那么，最大的成本损耗在时间上。一方面，程序员都属于高薪人士（相对，相对）。每一天的损耗都意味着大量的钱打水漂了。另一方面，随着时间的推移，商业价值在降低，风险却在增加。

对软件开发来说，需求实现速度，应该说是很重要的，但是实现速度本身并不是考量的标准单位。作为最大成本考量标准的时间，从对她的消耗来看：除去简单的功能点实现需要，需求的变化浪费的时间则更客观。而无数实例证明，我们在需求分析阶段投入时间诚然可以减少需求的变化，但是并不能达到我们满意的高度，所以对需求变化的反应也是我们的重要标准。

敏捷这个词，我觉得非常好。做为一门方法学，从名字上就说明了软件开发需要关注的两个重要的点：需求实现速度和对于需求的反应速度。当然，说到这里有点虚了。我想，回归到不太实际的本质，能更好的指导我们的实践。Rails框架为什么这么火热，恰恰因为它做到了这两点。我们想想，为什么要设计？我读过让人舒爽的代码，也读过看着让人想吐的代码。抛掉个人的感情因素，这两种代码有什么区别呢？大部分让我想吐的代码里出现的是一些重复的代码，看起来稍有不同，却不肯费点心思除掉这些“坏味道”。重复代码的问题在哪里呢？最大的问题就是随着代码量的增多，工作量的与日剧增。维护量也会增大。而且，复杂度绝对不是O(n)。其实我常常觉得，我们最早学程序的时候要学算法与数据结构。其实这个课程很早就告诉了我们编程最重要的两块：算法，结构。好的设计就是好的结构。可扩展，可维护，最起码，可以分工。

好的设计可以大量的减少代码。减少代码就意味着成本的降低。也就是文初说的，我们职业的目标达到了。但是现实往往不是那么美好，虽然我们有很多OO的设计模式，我们有很多最佳实践。但是在现实中，我们往往需要妥协。一般是三个原因：性能、稳定性、各种接口，在左右着我们。其实，很多时候，这也是最考验一个程序员的功力的地方。如何在这三个沼泽上跳舞，才是软件开发真正可以被称之为艺术的地方。而怎么做，则只能靠一行一行的代码锻炼，一篇一篇文章和文档整理经验，没法一句半句说得清楚的了。

咖啡屋的鼠标 2010-04-15 16:38 发表评论

看另一种晨会的杂感

咖啡屋的鼠标 — Sat, 06 Feb 2010 06:02:00 GMT

晨会是Scrum里的一个实践。

最近才意识到，这种东西一点都不时髦。很多理发店，饭店，他们早晨都有这个。今天在大鸭梨看到他们的晨会，颇有感觉。看着他们都站在那里，觉得跟站立式晨会差不多。不同的是他们的员工，年龄层比较低，处于还比较毛糙的年龄。也就是说，不仅需要教育怎么做事，还得教他们怎么做人。所以在这个晨会上，经理教育他们说，不要混日子，十年后，你们如果没做出什么来，一生就这么过去了。跟他们说，要当面说坏话，背后说好话。也就是进行人性和行事风格上的教育，也可以说是一种文化上的教育。经理教育完，几个像老员工的来说加单要写名字，不要怕写了名字会怎么着等等。虽然是端茶倒水送饭，但是需要注意的还真是不少。前台，服务员，后厨，这之间也是需要沟通规范，任何一个沟通不符合规范，就会出乱子。

比较起来，敏捷的实践只是要求个人说自己做过什么，要做什么，有什么问题。不过我发觉，有些话，其实是应该在晨会的时候应该强化与灌输，不见得是每天，但是隔三差五的就该讲讲。关于工作态度，配合。这是员工培训的最好时机。在这里用力，虽然不会有奇迹般的效果，但每隔一段时间肯定会有一点切实的进步。企业与企业都是不同的，有自己的氛围，那所谓的文化，就是企业的性格。员工与员工更是不同。但是企业喜欢的员工其实都很相似。不喜欢的员工却各有各的不同。所以企业经常培训员工。但我是不相信给员工搞一两次课可以改变一个人的。有天在快餐店，听到一个老销售教育一个新销售说，鸭子听鹰讲怎么飞。上完课，鹰飞回家了，鸭子还是走回家的。不能飞的鸭子又不缺什么，野鸭就能飞。所以，仅仅几天的员工培训能改变什么呢？不能指望着几天就能给公司制造出好用的员工来。公司对教育的重视不够说小了是不把自己的钱当回事，说大了其实是社会责任的缺失。

你们10年后还一事无成，这是给员工灌输的一种危机意识。要当面说坏话，背后说好话，这是对员工进行人性的教育。这像是领导说的话，有人说，领导两个字是领袖+导师。身为导师不引导人光明磊落，就不能怪人言可畏。有喜欢以流言御人的领导才有大量到处嚼舌头的下属。现代企业不是古代的官僚衙门。该专心搞的是经营而不是政治。

散会后，员工继续去工作了。你说这个晨会有什么作用吗？不知道，就像一颗石头扔进了平静的水里。一阵激荡过后我们什么都看不到了。但是，我想，日积月累，石头扔得多了。在你不注意的时候，水面会悄悄上升的。

咖啡屋的鼠标 2010-02-06 14:02 发表评论

敏捷还得是人敏捷

咖啡屋的鼠标 — Tue, 02 Feb 2010 15:59:00 GMT

敏捷作为方法学，其实还是比较虚的。哪怕是其中比较实的最佳实践，也是非常难以掌握运用的。原因其实很简单。人要想通过敏捷偷懒是绝对不可能的。敏捷的实施，在最初肯定是非常累的。因为改变总是痛苦的。回顾丰田的历史，他们在创造TPS的时候，工人们也是想把大野耐一的那些破烂东西都给砸咯。
不过很多时候，痛苦是幸福的开始。一个人完成很多人合作完成的工作，咋看起来是非常劳累的。但是习惯了，也就那样了。TPS里面基础就是让一个工人具备两项以上的技能。程序员也是一样。不能为自己的懒惰找理由。大家都是人，都想懒，但是今天懒了，总会有一天被逼着勤快。就好像没有时间锻炼，就有时间生病一样。只有每个团队成员都变得敏捷了，敏捷的方法才有意义。

咖啡屋的鼠标 2010-02-02 23:59 发表评论

TPS相关书籍阅读笔记

咖啡屋的鼠标 — Thu, 02 Oct 2008 16:34:00 GMT

最近一直在看跟丰田生产体系有关的书，得到一些很有意思的知识点

刚明白原来这些个名词他们是JIT->TPS->Lean->Agile这么一个关系。

丰田老总一拍脑袋提出3年之内超越福特。这种感觉就像好像有一家中国软件公司一拍脑袋说，三年之内超越微软一样。我要是执行人，只会觉得上边又发神经了，这不是疯了吗？结果大野耐一到底是大野耐一，竟然真的找到了方法。

TPS认为浪费有七种：

生产过剩的浪费
制造不良品的浪费
停工等活的浪费
动作上的浪费
搬运的浪费
加工本身的浪费
库存的浪费

丰田的思路其实简单到了不能再简单，利润=销售价格-成本。那么在经济增长无望的时代，减少成本就等于创造利润。过去的时代是一个经济高速发展的时代。就像日本泡沫经济时代一样。但是泡沫破裂的时候，丰田反而崛起。类似的如学习TPS的佳能，在5年内销售没有增加的情况下，利润增长十倍。
面对一个即将来临的经济增长放缓的时代，成本开始成为管理者嘴上流行的新词应该是下一步的趋势。

软件开发中的浪费有哪些呢？我现在想不到太多。但是跟朋友聊天我突然意识到，犹豫也是一个巨大的浪费。作为一项脑力劳动，开发时的犹豫就如同停工等活的浪费和动作上的浪费。这种事情其实可以避免，我开始明白TPS这样一个强调变化与改进的过程，为什么还如此强调标准化。应该就是通过整理最佳实践并确定为标准流程来减少重复犯错与犹豫造成的浪费。那么结对对效率造成的改进，别的不提，减少了犹豫的时间应该是很重要的一点。而这也是在水面以下最不容易被发现的浪费。因为犹豫和谨慎，从表面上看，似乎是一样的。

咖啡屋的鼠标 2008-10-03 00:34 发表评论

过程

咖啡屋的鼠标 — Sat, 21 Jun 2008 17:30:00 GMT

    前些天跟朋友聊天，聊得很激烈，我也收获很多。
    中间聊到过程，朋友认为，管理的最高境界应该是没有过程，但仔细一问发现，还是有过程的，只不过是一些更人性化的过程而已。结合我另一些朋友的观点，看来“过程”这个词有点招人恨了。（当然如果是瀑布式的过程的话，我会第一个跳出来恨的,:P）
    我一直认为过程这种东西，做不好就是枷锁，做好了就是铠甲，让你在工作中左冲右时保障你的安全。这次敏捷大会跟o6z聊天时，他说，虽然他老说敏捷，但他其实是一个很偏好重型过程的人。其实还是我的那个比喻，只不过重型的铠甲也是铠甲，更适用于直线冲锋陷阵的重装骑兵，但是你要是随便找个步兵团队来配上重装骑兵的铠甲，估计还没打就被压死了。
    关于过程这个东西，很有趣。既然想到这了，就像抽取一些自己的零散思维放上来。
    我琢磨XP有很长一段时间了，Scrum也看了一段时间，就个人来说，不是很喜欢Scrum。总觉得这个东西天生带有一点滋生官僚这种细菌的潜质。常听说 XP没有管理的内容，Scrum在这方面做的更好。可我还是觉得Scrum没提供什么东西，完全可以把Scrum的一些东西吸收到XP中，结合自己的团队实践搞一些混合敏捷（Hybrid Agile）。因为Scrum在管理方面做的东西并没有多少，实在算不上盔甲，顶多是个盾牌。比较起来，XP的话，倒是有丰富的价值观和配套的实践，在吸取了它的一些本质的东西之后集合公司实际做一些定制化的管理框架更好。
    下一步准备研究一下FDD，再考虑跟前面俩方法混搭一下。我感觉这搞过程越来越像J2EE开发了：Struts + Spring + Hibernate一样的玩法。

咖啡屋的鼠标 2008-06-22 01:30 发表评论

没事闲的，考虑一下企业文化

咖啡屋的鼠标 — Thu, 05 Jun 2008 16:54:00 GMT

前一阵跟一做企业文化咨询的哥们混了一阵，从他那瞅见一书，挺有意思。叫《公司基因》，看着不错就买了。
这OpenParty是不兴推荐书了，下次再有机会就推荐这个。
这书里认为企业文化不管怎么变，他的DNA都是由四个元素组成的，即：组织架构（原词是structure）、决定权、信息、激励机制。
它根据这四个元素把企业分成了七种类型

消极进取型
时进时停型
过度膨胀型
过度管理型
随机应变型
军队型
韧力调节型

其中前四者看名字就知道不是什么好东西，书中也定义为不健康的企业。后三者，虽然都算是健康的，但最好的其实是最后一个。

敏捷常常被说是一种文化，我也这么觉得。所以，我最近一直让自己从这四个角度看敏捷的方法学。分析来分析去，反而搞不清敏捷应该塑造一种文化，还是某种文化是维持敏捷的土壤。有点鸡生蛋蛋生鸡的意思。不过不管哪个生哪个，如果目的是养鸡，那谁先谁后就不是我关心的了。

咖啡屋的鼠标 2008-06-06 00:54 发表评论

初读《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 发表评论