2008年6月22日
题外话：我其实想说的是一个被人所忽视的问题。形式有没有价值？我承认，形式化是不好的。但是这个世界有个东西，叫做仪式。
举个例子，在国外，有种组织叫兄弟会，（电影里很常见）他们的有些会设置很多可笑的考察仪式来考察你够不够入会的资格。有些会有危险，有些只是纯粹搞出些恐怖气氛吓你看你会不会被吓退。这种东西有价值吗？心理学告诉我们，设置准入门槛可以提高组织成员的忠诚度。如果你觉得这玩艺太可笑了，给取消掉。你会莫名其妙的发现后来加入的人对组织的认可度忠诚度都不高。这就是仪式的价值。
今天说的是Retro，全名retrospective，中文名“回顾会议”，网上有很多相关文章，就不再这里赘述了。这里提到的Retro是最常见的一种模式，分Well, Less Well, Puzzle三个维度的模式。该模式的Retro的特点是会让我们更多的关注less well，关注我们做的不好的那些。这点有好有坏。本文只揭示它好的一面。做为补充，还有一种海星图的模式，感兴趣的人可以自己查询。
我个人认为retro是敏捷开发中很重要的一道防线。是团队健康度的晴雨表，是沟通的桥梁，是共识建立的契机，是改进的开始。
对于团队本身就存在大量问题，而这些问题可能都在敏捷方法的问题域里时。Retro是一个很好的发力点。他的效果可能没有持续集成那么立竿见影，往往是润物细无声。他可以帮我们把痛点暴露出来，但是不一定是根本问题。就像医生看病也得先问你哪不舒服。而Retro就能帮团队说出来哪不舒服并达成共识。某种意义上讲，它是个报警器。
如果已经采用了大量敏捷实践的团队呢？比如我们团队，在我们团队的开发中，我们一直推进着各种改进，期望让我们的工作更有效率，交付更多价值，同时也让我们的生活更美好一些，这是一件双赢的事情。 可是我们也要看到改进是需要成本的，而且也是有风险的，所以有的时候难以推动。对于客户（ 有时是PM等内部角色）来说，他讨厌一切成本和风险，而更感兴趣的是新功能，当碰到短视的负责人，或者交付压力占了上风的时候，难以推动这点感觉尤为明显。不过商业社会里竞争如此激烈，这也无可厚非。虽然我们也知道出来混，欠下的迟早是要还的。
不过这不是我们今天讨论的角度。今天我们站在推动改进的角度来看这个问题，开发时，在开发第一线的我们往往是第一个了发现开发中的问题，然后我们会发现改进最困难的是沟通，明明这是个问题，但是让各方都接受这个问题并改进它需要证据，需要沟通，需要资源，最重要的需要时间。我曾眼睁睁得看着客户只是加几台机器提升持续集成的构建效率这件事竟然推动了近一年才成功，那么在这个问题被发现但不能改进的时间里，团队会怎样呢？首先士气会被打击，接着如果问题长期不能解决并影响了工作效率，一种不愿追求卓越的气氛会渐渐感染团队成员，进而使得大家会在其他实践上表现渐渐变差。（ 相对于每个人自己，而不是团队其他成员）改进的意愿也会不同程度的变低。这符合
破窗效应。
这时候，很容易出现的一个倾向会是干脆我们不要retro了，反正也改进不了，完全是浪费时间。 这就成了自毁长城。不能干因为报警器老响就把报警器拆了的事。出来混欠下的始终要还，学鸵鸟是没用的。当retro不能给我们提供更多实际改进价值的时候，它还能提供最后一个价值：忏悔的仪式。
曾经一直不明白西方人为什么定期去教堂忏悔，周周去，周周都有值得忏悔的，甚至犯过的错还有很多类似的。看起来没什么用。但这就像房间，天天打扫天天都有的打扫的，心灵的房间也是一样。一位有信仰的朋友告诉我，定期经常向神忏悔会更愿意改进自己，如果一段时间不去对自己的要求就会放松。人的心理就是这么奇怪。这揭示了一个道理，人是会逐渐放松对自己的要求的，所以需要一种手段让我们保持对自己的高标准。
我个人认为retro就是一个很好的手段。尤其我前面说过了，这里讨论的这种Retro的模式的特点就是让我们更关注于Less Well。定期，经常，回顾，反思。当我们无法变得更好的时候可以帮助我们反观团队自身，不要变得更差。让破窗效应难以发生。
（本来只是想写一个敏捷团队碰到让人沮丧的情况时Retro提供的价值，结果越写越多，有点跑题了⋯⋯）
在我们的开发中，有些实践的价值是容易感受到的，比如重构，比如TDD，比如持续集成。
有些实践的价值则不容易感受到，比如Retro（回顾会议），比如IPM（迭代计划会议）。
以IPM为例，在我们的IPM上我们一般会做两件事Kick off cards和Estimation。也就是选择下个迭代要做的卡和评估每张卡的点数。这两件事情似乎第一件事没必要所有人都参与，第二件事感觉一定程度上是瞎蒙，尤其是一群人来蒙，显得尤为的不靠铺。而且似乎我们IPM就是为了选出下个迭代能做完的卡，就是为了知识传递，就是为了给客户可视的数据和计划，让他们心理好过。
假设说我们不必所有人都参与就能保证选出适合下个迭代做的卡，我们通过每日Code Review等实践使得每个人都不会缺少相关卡的知识，而客户也不特别在意我们的进度（或者说我们的进度他们总是满意），是不是我们就不需要IPM了？是不是我们就不需要集体Estimation不需要集体Kick off了？
实际上，我们的项目就符合前面的假设，在项目的最后，我们真的取消了IPM。这时，才感觉出来IPM的价值。
整个团队的效率慢慢开始下降。对于目标的理解开始不一致。虽然团队整体的表现并不差，虽然没有出现任何实质的问题，但容忍度低的人开始不舒服。跟团队自己以前的状态比，确实有点退化的感觉。怎么会这样呢？
每当说到这种状态出现在敏捷团队中的时候，我最常听到就是人的问题，态度问题等等说法。其实我一直觉得，如果追究态度，空谈人的问题有用的话，我朝应该是世界第一而不是那个人人自我的美帝。人一直是有问题的，不然要管理学干什么？敏捷里提倡自组织团队，自我管理。但决不是松散组织，不管理。自组织它也需要组织，自我管理它也是管理。像IPM这样的活动，就是管理的一部分。
IPM上做的两件事，看起来完全不靠铺，实际上却非常有价值。整个IPM活动就是一个承诺的仪式。像古代行军打仗前的誓师大会一样，可以调动起团队在下一个迭代中的士气。通过集体参与评估和制定计划，通过各个角色的共同作用，使得每个人都参与到整个计划制定中来。自然而然的对下一个迭代许下承诺。而承诺一旦许下，就会像一个耳语的恶魔，暗中催促着人们的行为与其保持一致。
生活在我朝的人们，似乎对承诺这个东西的效果是完全不相信的。这也难怪，不过出于众所周知的原因，咱不谈我们为啥不信任承诺。从心理学的角度，承诺是有实际意义的。《影响力》“第三章 承诺和一致”中就讲了这个极为简单却极为有用的心理学原理：人人都有一种言行一致（同时也显得言行一致）的愿望。
其中有很多很有趣的实验，揭示了承诺的力量。 感兴趣的人推荐读一读。里面有个小例子提到，两个星期前一个愿意在自家的草地上插一个小牌子为交通安全做点贡献的小承诺，使得该社区76％的人都在两个星期后接受了在自家草地上插一个挡风景的大牌子的请求。而对照社区只有17％。巨大的反差可以让我们看到承诺的力量。
当然我们对承诺的不信任也是有道理的，当承诺真的难以完成的时候，几乎所有人都会违背承诺。在传统的瀑布式开发过程中，使得计划这种承诺难度大大上升，而可信度也就大大下降。这也是为什么我们需要迭代的原因。
一个成功的企业需要积累。当你坐在电脑旁，看着一个运行达十年之久的软件的源码时，相信我，你一定会更深刻的感受到积累这个词，确确实实是个中性词。
软件多种多样的功能支撑着一个企业帝国的运转，它源源不断的在为这个帝国创造着财富，毫无疑问它随着时间积累了很多挣钱的能力。可是如
同历史上其
他的帝国一样，在繁华的背后，很多黑暗的东西同样随着时间积累了下来，临时性的策略被固化在核心流程中，为扩展留下的空白成了每次扩展必须绕行的弯路，精妙的手法随着时间的变迁显得复杂过时，分工协作使得同样事情得处理方式大不相同，预先的设计又使得本不相同的东西硬造成了相同的样子，管理的疏忽使得简单的功能用了复杂的模式实现。
坐在代码面前，仿佛在读一本被囚禁了灵魂的魔书，你能在注释中读出兴奋与痛苦，你能在代码中看到骄傲与彷徨。每当完成一次重构就像解救了一个被困的灵魂。那代码又仿佛一个人的脸，你可以看到各个技术历史阶段在它脸上留下的岁月痕迹。畅游在代码中，有些时候我们好像穿梭在时光的河流中，你能看到一个愚昧的风格是如何从一个有价值的需求中演变而来。如今再看，仿佛一群羊在不断的跳过一个早已不存在的栅栏一样诡异。而有些时候，我们只能看到一些遗迹，原野中矗立的大石柱根本无法自己告诉我们他们到底是为何矗立在那里的。以及移动他们会不会带来什么灾难。
能力很强，问题很多。是任何一个已经有历史的公司都会有的。软件不过是公司的一个表现方面。就像一个拥有完整公司基因的细胞。准确的说，任何时候，任何公司都不可能没有问题的。但是何时解决？这个问题就跟什么时候重构一样，答案也是一样，随时。解决问题的时机会影响解决问题的难度。越晚解决，就越难解决。说起来容易，做起来谈何容易。是的，解决问题总是需要鼓励的，但是谈何容易四个字却很容易瓦解我们前进的意志。低下头埋到土里，是可以让一切都清静了。但不管我们做不做，甚至于即便我们在做，问题也永远不会停止它产生并进化的脚步。面对问题，只有应战，没有第二条路可以走。经济危机教会了很多企业只顾赚钱而忽略企业的问题会有什么后果。我相信有很多人会选择遗忘并在遥远的未来继续重犯同样的错误，但是我也相信，也会有很多人会选择记住并把教训提炼成一种知识或制度，让后世人学会警惕。
进来听闻最大的CMM堡垒DNV要搞敏捷。大票的猎头纷纷出动，四处搜罗敏捷咨询师。使敏捷这个本来只有小众在实践的一类开发方法陡然变得要大众化了。本来以为是件好事。却在昨天看到z叔大喊，敏捷要倒。当时只是觉得有点道理。晚些时候却切身体会到了。
收到某非知名公司举办的scrum培训的邮件。顿时心里一紧。在这个时间，用这个操作手法有点可怕，各培训公司都找到了敏捷里面最好切入的一个点---Scrum。
Scrum是个筐，什么都能往里装啊。为什么这么说呢，他并不能算是一个完整的开发方法。只是一个框架。不领会敏捷的精神，没有其他具体的开发方法，他只能是一个大面的东西，如果用上这种东西就号称敏捷了。那真是可怕。而且，scrum证书也在这波浪潮中量产。一个人，花几千块钱，上两天的课，拿着一张纸就号称敏捷了。没办法，谁让咱们崇拜证书这种看得见摸得着的东西呢。但这样大量量产出来的敏捷项目经理。一实践肯定不对劲，就会用自己的理解去曲解敏捷。然后大家认为敏捷就是早晨开个会，月末开个会。最后的结果就是你在骂敏捷，我在夸敏捷，可是你嘴里的敏捷和我嘴里的敏捷根本就不是一个东西。
记得曾经见过一个CMMI的咨询师，张口闭口卡耐基梅隆，一付兄弟当年在英国的时候的样子。生搬硬套的CMMI流程。最后搞的那套流程根本不可操作，大家都为流程凑数据。当下如果大家都从CMMI倒向Scrum，这种人咋生存呢？会挂掉？错，摇身一变，举起敏捷大旗开始摇旗呐喊。没这两下子怎么能在忽悠界纵横这么多年呢。像这样的人都来搞敏捷了。敏捷不臭，那除非老天开眼了。那原来搞敏捷的人呢？本来就是小众，在这大浪里面，估计很快就看不见了。。。。从今开始，我还是少说两句敏捷了。。。
我习惯于在午饭后午睡一下。上班时午睡，只能是趴着睡。最近才注意到，写字楼的空调大多是从上往下吹得，所以这个时候整个后背是暴露给空调的。从中医上讲，背上主要是两条经络。督脉和膀胱经。其中膀胱经主人体一身之阳气。号称人体最大的排毒通道。膀胱经不通的人可能会怕风怕冷，容易得湿疹等病，常年排毒不畅，可能会导致更多疾病。
体的经络不管哪一条，都怕六邪，风湿热火燥寒。对于处处空调的现代人，火燥热远不如风湿寒需要担心。比如像这样天天把后背暴露给空调，而且是在睡觉这种放松状态下。就等于天天让空调的风寒入侵膀胱经。加上很多办公室都有加湿器。那湿也是跑不了。当然，人体自身有防御的能力，肯定不会马上出问题的。但是天天这么搞，难免不出问题。上个礼拜加了几天班觉得左肋靠近腋窝的地方疼。周末好一点了，今天下班前又痛了。引起我一点警惕。所谓猝死，大概就是这么一点点演变来的。干咱们这行撑不死可也别累死。
温热可以驱寒，我想把背紧靠一会靠背取暖。这时发觉我的椅子后背只到肩胛骨中部。好像很多公司的椅子都是这样的，不能很好的护住背部（除了老板椅。老板椅上面似乎还要往前多出一块来，连后脖颈子都能护住。倒是很养生。）
所以，办公室可以放一件外衣，睡觉的时候披上来防风防寒。另外，可以偶尔的去做一些保健。比如拔罐，刮痧等。基本上背部拔罐就是在疏通膀胱经。背部刮痧也是。不过要注意的是：
一，拔罐的话，频率不宜过高，拔罐是排毒比较猛的一种方式，体内毒多的时候倒是在排毒，毒少了以后，排的就不只是毒了。有一种说法，拔得太频繁反而会有损阳气。我比较认可这种说法。一个月一次或者隔一个月一次为宜。拔罐后六个小时不能洗澡。
二，刮痧倒是可以频繁点，但最好找干净的地方或让自己家人做。肉少的地方尽量少刮。最近发现一种叫魔蝎刷的东西，个人感觉比刮痧板好用，可以替代刮痧板刷背。刮痧后半小时不能洗澡。从时间上也能看出哪个比较猛。
最后，多多运动是最好的保健方法。自我锻炼总是要胜过别人伺候。愿程序员们都能度过一个健康的夏天。
没“贡
献”的田鼠
在田野里，住着三只田鼠。
秋天到了，三只
田鼠开始准备过冬的东西。
第一只田鼠每天都到田野上运粮食，准备冬天食用。
第二只田鼠每天都到田野上运野草，准备冬天取
暖。
而第三只田鼠每天都跑出去游玩，对粮食和野草一点儿也不关心，好像冬天永远也不会到来一样。
前两只田鼠劝它为即将到
来的冬天多准备一些必要的东西，但它只是笑笑，仍然每天都出去游玩，经常玩到天黑才回来。
寒冷的冬天很快到来了，三只田鼠住在洞里，饿了
就吃第一只田鼠运回来的粮食，冷了就用第二只田鼠运回来的野草取暖，而毫无贡献的第三只田鼠自然也得到了前两只田鼠的嘲笑。
然而日子一
天天地过去，每天都无所事事地待在洞里，做着同样的游戏，吃着同样的粮食，三只田鼠渐渐厌烦起来，感觉到了无聊的空虚。
这时，第三只田鼠
开始为前两只田鼠讲故事，讲它在秋天出去游玩的时候见到的许多新鲜有趣的故事，前两只田鼠听得津津有味，生活开始重新变得充实而有意义。
作
为感谢和报答，前两只田鼠经常把自己的粮食和野草挑出一些送给第三只田鼠。
原来，有些贡献并不是从一开始就能看得出来的，然而我们却经常
因为暂时看不到它的“用处”就舍弃了它。
这篇文章是受启发于要求我写一些设计和spec的文档的面试要求。趁这个机会整理整理自己的思路。
什么是软件开发呢，最常见的一种说法是，软件开发是一门艺术。我觉得更现实的讲，软件开发应该是一种生产。跟其他所有的生产一样。要考虑成本和收益。收益这块，跟其他很多外部因素相关，对开发者或者说开发者的管理者来说无法控制，开发者从职业的角度出发更多需要考虑的是成本。这也是我们职业的目标。
软件这种产品的生产，材料本身的损耗也就是电脑，电费，基本属于沉没成本。不会因为咱们任何努力而改变。（也不是完全不能改变，只能是变多。。。。）那么，最大的成本损耗在时间上。一方面，程序员都属于高薪人士（相对，相对）。每一天的损耗都意味着大量的钱打水漂了。另一方面，随着时间的推移，商业价值在降低，风险却在增加。
对软件开发来说，需求实现速度，应该说是很重要的，但是实现速度本身并不是考量的标准单位。作为最大成本考量标准的时间，从对她的消耗来看：除去简单的功能点实现需要，需求的变化浪费的时间则更客观。而无数实例证明，我们在需求分析阶段投入时间诚然可以减少需求的变化，但是并不能达到我们满意的高度，所以对需求变化的反应也是我们的重要标准。
敏捷这个词，我觉得非常好。做为一门方法学，从名字上就说明了软件开发需要关注的两个重要的点：需求实现速度和对于需求的反应速度。当然，说到这里有点虚了。我想，回归到不太实际的本质，能更好的指导我们的实践。Rails框架为什么这么火热，恰恰因为它做到了这两点。我们想想，为什么要设计？我读过让人舒爽的代码，也读过看着让人想吐的代码。抛掉个人的感情因素，这两种代码有什么区别呢？大部分让我想吐的代码里出现的是一些重复的代码，看起来稍有不同，却不肯费点心思除掉这些“坏味道”。重复代码的问题在哪里呢？最大的问题就是随着代码量的增多，工作量的与日剧增。维护量也会增大。而且，复杂度绝对不是O(n)。其实我常常觉得，我们最早学程序的时候要学算法与数据结构。其实这个课程很早就告诉了我们编程最重要的两块：算法，结构。好的设计就是好的结构。可扩展，可维护，最起码，可以分工。
好的设计可以大量的减少代码。减少代码就意味着成本的降低。也就是文初说的，我们职业的目标达到了。但是现实往往不是那么美好，虽然我们有很多OO的设计模式，我们有很多最佳实践。但是在现实中，我们往往需要妥协。一般是三个原因：性能、稳定性、各种接口，在左右着我们。其实，很多时候，这也是最考验一个程序员的功力的地方。如何在这三个沼泽上跳舞，才是软件开发真正可以被称之为艺术的地方。而怎么做，则只能靠一行一行的代码锻炼，一篇一篇文章和文档整理经验，没法一句半句说得清楚的了。
晨会是Scrum里的一个实践。
最近才意识到，这种东西一点都不时髦。很多理发店，饭店，他们早晨都有这个。今天在大鸭梨看到他们的晨会，颇有感觉。看着他们都站在那里，觉得跟站立式晨会差不多。不同的是他们的员工，年龄层比较低，处于还比较毛糙的年龄。也就是说，不仅需要教育怎么做事，还得教他们怎么做人。所以在这个晨会上，经理教育他们说，不要混日子，十年后，你们如果没做出什么来，一生就这么过去了。跟他们说，要当面说坏话，背后说好话。也就是进行人性和行事风格上的教育，也可以说是一种文化上的教育。经理教育完，几个像老员工的来说加单要写名字，不要怕写了名字会怎么着等等。虽然是端茶倒水送饭，但是需要注意的还真是不少。前台，服务员，后厨，这之间也是需要沟通规范，任何一个沟通不符合规范，就会出乱子。
比较起来，敏捷的实践只是要求个人说自己做过什么，要做什么，有什么问题。不过我发觉，有些话，其实是应该在晨会的时候应该强化与灌输，不见得是每天，但是隔三差五的就该讲讲。关于工作态度，配合。这是员工培训的最好时机。在这里用力，虽然不会有奇迹般的效果，但每隔一段时间肯定会有一点切实的进步。企业与企业都是不同的，有自己的氛围，那所谓的文化，就是企业的性格。员工与员工更是不同。但是企业喜欢的员工其实都很相似。不喜欢的员工却各有各的不同。所以企业经常培训员工。但我是不相信给员工搞一两次课可以改变一个人的。有天在快餐店，听到一个老销售教育一个新销售说，鸭子听鹰讲怎么飞。上完课，鹰飞回家了，鸭子还是走回家的。不能飞的鸭子又不缺什么，野鸭就能飞。所以，仅仅几天的员工培训能改变什么呢？不能指望着几天就能给公司制造出好用的员工来。公司对教育的重视不够说小了是不把自己的钱当回事，说大了其实是社会责任的缺失。
你们10年后还一事无成，这是给员工灌输的一种危机意识。要当面说坏话，背后说好话，这是对员工进行人性的教育。这像是领导说的话，有人说，领导两个字是领袖+导师。身为导师不引导人光明磊落，就不能怪人言可畏。有喜欢以流言御人的领导才有大量到处嚼舌头的下属。现代企业不是古代的官僚衙门。该专心搞的是经营而不是政治。
散会后，员工继续去工作了。你说这个晨会有什么作用吗？不知道，就像一颗石头扔进了平静的水里。一阵激荡过后我们什么都看不到了。但是，我想，日积月累，石头扔得多了。在你不注意的时候，水面会悄悄上升的。
敏捷作为方法学，其实还是比较虚的。哪怕是其中比较实的最佳实践，也是非常难以掌握运用的。原因其实很简单。人要想通过敏捷偷懒是绝对不可能的。敏捷的实施，在最初肯定是非常累的。因为改变总是痛苦的。回顾丰田的历史，他们在创造TPS的时候，工人们也是想把大野耐一的那些破烂东西都给砸咯。
不过很多时候，痛苦是幸福的开始。一个人完成很多人合作完成的工作，咋看起来是非常劳累的。但是习惯了，也就那样了。TPS里面基础就是让一个工人具备两项以上的技能。程序员也是一样。不能为自己的懒惰找理由。大家都是人，都想懒，但是今天懒了，总会有一天被逼着勤快。就好像没有时间锻炼，就有时间生病一样。只有每个团队成员都变得敏捷了，敏捷的方法才有意义。
时间。。。曾经是我最害怕的东西。。。如今却变成了最喜欢的东西。。。
这个世界纷纷扰扰有那么多的真实与虚假
只有时间能把它们分离开来。
时间，跟所有自然的伟力一样，从来都是缓缓的，慢慢的显示着自己的力量。
人可能等不及看到它的效果，可它却一直履行着自己的职责
一切浮于表面的虚幻，终会在时间的侵蚀下消逝，只留下最真实的东西。
google上搜这个词，搜到的很多是征文，和一些扯淡的文章。
跟这篇文章一比就差的比较远咯：
http://www.dapenti.com/blog/more.asp?name=xilei&id=15410
节选精华“中国梦”解释如下：
如果有人问什么是中国梦？我说，只要你看看这个国内的精英怎么选择的，你就知道了：
【1】读书，考上清华北大，然后，到外企工作，出国，拿绿卡；
【2】唱歌跳舞，不惜一切代价成名，出国，变更国籍；
【3】当官，贪污腐败，找机会逃跑到国外，躲起来过一掷千金的日子；
【4】做生意，赚到足够的钱，然后，出国定居，想生几个孩子就生几个孩子，让小孩都在国外上大学。
BlogJava，应该是一个技术博客。倒回来看自己写的东西，却感觉离题越来越严重。
对技术的热情在衰退。所写的技术相关的东西越来越少。
从Java到Flex到Grails。技术照理增长了不少，人却越来越迷茫。
对文科的兴趣在增长，已然超越了对程序设计的兴趣。
可是做的工作又不得不继续从事程序设计的学习，不然一旦失业了，我又能做什么呢？
所以每当看一些文科的书，就会有一种罪恶感。人活成这样，不得不说是一件悲哀的事情。
其实心里明白，所谓悲哀在旁人看来不过是一种吃饱了撑着的心态。
买了域名和空间，准备换一个独立博客了。到时想写些什么就写些什么了，也不用担心站方有问题。
最近一直在看跟丰田生产体系有关的书，得到一些很有意思的知识点
- 刚明白原来这些个名词他们是JIT->TPS->Lean->Agile这么一个关系。
-
丰田老总一拍脑袋提出3年之内超越福特。这种感觉就像好像有一家中国软件公司一拍脑袋说，三年之内超越微软一样。我要是执行人，只会觉得上边又发神经了，这不是疯了吗？结果大野耐一到底是大野耐一，竟然真的找到了方法。
- 生产过剩的浪费
- 制造不良品的浪费
- 停工等活的浪费
- 动作上的浪费
- 搬运的浪费
- 加工本身的浪费
- 库存的浪费
-
丰田的思路其实简单到了不能再简单，利润=销售价格-成本。那么在经济增长无望的时代，减少成本就等于创造利润。过去的时代是一个经济高速发展的时代。就像日本泡沫经济时代一样。但是泡沫破裂的时候，丰田反而崛起。类似的如学习TPS的佳能，在5年内销售没有增加的情况下，利润增长十倍。
- 面对一个即将来临的经济增长放缓的时代，成本开始成为管理者嘴上流行的新词应该是下一步的趋势。
-
软件开发中的浪费有哪些呢？我现在想不到太多。但是跟朋友聊天我突然意识到，犹豫也是一个巨大的浪费。作为一项脑力劳动，开发时的犹豫就如同停工等活的浪费和动作上的浪费。这种事情其实可以避免，我开始明白TPS这样一个强调变化与改进的过程，为什么还如此强调标准化。应该就是通过整理最佳实践并确定为标准流程来减少重复犯错与犹豫造成的浪费。那么结对对效率造成的改进，别的不提，减少了犹豫的时间应该是很重要的一点。而这也是在水面以下最不容易被发现的浪费。因为犹豫和谨慎，从表面上看，似乎是一样的。
通往天堂的轮船和通往地狱的轮船烧得都是同一种燃料，那就是人类的欲望。
记得小时候看《读者》这本杂志，里面有一个故事，上帝带一个人去参观地狱，地狱里支着一口大锅，锅周围坐着一群人，每个人拿着一个很长的勺子，因为勺子太长了，想要吃东西，经常会碰到别人，所以互相之间总会打起来，结果所有人都吃不饱，人人脸上充满着愤怒和痛苦。然后上帝带他又去参观天堂，结果天堂里跟地狱的摆设一模一样。但是人人脸上洋溢着幸福，原来，这里的人会用长勺子喂对面的人，所以，每个人都能吃饱。
同样的配置，同样的人，同样都有吃饱的欲望。一处是天堂，一处是地狱。现实中也是如此，一个好的游戏规则，游戏中便是天堂，一个不好的游戏规则，游戏中便是地狱。
相传，有两个嫌疑犯,合谋杀死了一个人，之后被警察抓住，警察将他们分开审讯。并告诉他们说，如果你们两个人都不说的话，以我们现在的证据，我们可以让你们坐一年的牢。如果你招供了，而你的同伙没有招供，那么我们将当庭释放你，你的同伙关20年。如果你和你的同伙都招供了，那么我们也就没有必要照顾你们任何一个，你们一人关10年。
这就是著名的囚徒困境。处于困境中的囚徒，该如何选择呢？
如果我是那个囚徒，我不说，你说了，我被关20年。你说了，我也说了，我关10年，只有你不说我不说的情况下，我还要关1年。这里还有一个极大的诱惑，那就是我说，你不说，我可以当庭释放。人性如此不可靠，综合判断的话，还是说最保险，保不齐还能当庭释放呢？不如赌一把。
这就是我全部的如意算盘，可惜，另一个囚徒他又不傻，他也会这么想。于是，利益最大化的可能性变成了永远不可能达到的彼端。而10年这个选项变成了我唯一的下场，也是我们双方唯一的下场。这个次坏的结局被称之为双输。我们追求的利益最大化的那一点被称之为单赢。而每人都得到次好的那个看起来更不可能的选项被称之为双赢。
这个故事中其实并不虚幻，现实中的我们都是这样的囚徒。想想日常中遇到的一些类似的情况，真的是非常的熟悉。
现实中的情况复杂一些，可是道理相同。我们每个人都追求自己的利益最大化，可是长远来看，最大化的利益或不曾降临，或稍纵即逝。我们最终得到的只有那个次坏的选项。不过还好我们还可以合理化，安慰自己说，总算没有到最坏的结果。但实际上我们明明可以到达双赢的结局。
从刚知道这个故事的时候，我就发觉工作中的情况与此非常类似，于是我想，应该找办法摆脱这个困境，远离双输，通往双赢。我觉得，凭借敏捷方法我可以不用陷入这个困境。可是我错了，以前的困境拼图并不完整，敏捷方法恰恰是补完了这个困境通向双赢的那最后一块拼图，至此一个完整的囚徒困境才算是建立完成了。有诱惑，有陷阱，有希望，于是也就有了困惑。于是，困境始成。
在这个困境里，企业那点道道，就不说了，大家都很熟悉，可是作为我们程序员，就多么高尚吗？
敏捷要求全能小团队，可对于程序员来说，只干自己擅长的那一摊事，然后拿工资是利益最大化的选择。抽空还能自己学点东西提升一下自己。或者聊聊天、泡个论坛、玩个网游什么的。我们自己做出了并不比企业高多少的选择。通过双方的不懈努力，终于，企业和我们达到了双输的结局。简直就是悲剧。悲剧一再上演着，却没多少人太在意，至少大家都可以安慰自己说，总算没有到最坏的结果，一定是哪里做的不够好，再改进一些会好的。可惜，自然规律是很无情的。你做了这个选择，就只有这个结局，于是悲剧一再上演。
没有解决的办法吗？有，当囚徒困境不是模型里的单次博弈而是多次博弈时就有解。可以采用一报还一报的方式，当一方选择个人利益最大化的选择时，那另一方也选，直到对方放弃。也就是不停的双输，并且沟通，直到大家一起回到双赢境地下。这就是囚徒困境的唯一破解之法。只可惜这个方法也有问题。第一个选择个人利益最大化的人会在这个方法中获利。如果利益比较大的话，反复几次，他就可以有机会破坏这个平衡，将双赢博弈再次变为零和博弈。所以，惩罚机制也是很需要的。
方法有了，可是模型毕竟是模型，现实比这复杂得多。在囚徒困境之外，你会发现，还有团队这个群体存在。当一个人做选择很容易，当一群人做选择的时候，就很难了。按照大众心理学的说法，群体几乎是没有意识的。所以这个时候，我是只能感慨个人的渺小了。
价值,所有的方法学都会指向这个词。
可是所谓的价值，有的时候说得清楚，而有的时候很难说得清楚的。客户说出来的清楚，但有可能根本不是他最需要的。如果天下的人都清楚的知道自己要什么，也许也就不会有什么方法学了。
就考虑我们自己吧，我们想要什么？钱，没错，谁都需要钱。但要钱干吗呢？在钱的背后是我们追求的价值。大家都想让自己的价值得到体现。可是这简单的一句话在每个人身上却有不同的含义。
客户提出需求的时候总是欲求不满的，仿佛跟上帝许愿一般。可是我们毕竟不是上帝，只是勤劳的工匠。工匠是一种介于艺术家与科学家之间的职业，是兼顾感性与理性的一群人。在我们的身上有像艺术家一样追求超越自我的性格也有像科学家一样锲而不舍追求真理的性格，制造出对人们有用的工具是我们最大的价值体现吧。可复杂的现实，让我们这么利他的追求也难以实现。
红警、星际、暗黑。还有人记得当年的这三个伟大的作品同台竞技的那个时代是怎样的情景吗？
不记得也没关系，因为这个时代又要来临了！
这次是红警3、星际2和暗黑3.哇咔咔，未来的几年不会太无聊了。不要太沉迷于游戏中才好，呵呵。
昨天，盖茨离开了微软。对我来说那一天只是一个普通工作周的结束，对微软来说，却是一个时代的结束。
用盖茨大叔的操作系统的历史跟我接触电脑的历史一般长。从最早的dos到win32到win95、98、me、xp、2000、2003、vista。我几乎用过微软的每一代操作系统。经常会骂微软垃圾，可我也从来没掏钱买过正版操作系统，这种骂多少有点龌龊。
时隔若干年之后，总算我也用上了正版的windows（笔记本送的Vista）。回想起来，一些往事不由得浮上心头
最早的时候接触的dos已经记不得是哪个版了，286时代的，而那个286电脑大概长成这样：
但是开始正式学的dos应该是6.22的：
那个时候装机只需要一张5存盘：
后来才有的3.5寸盘：
那个时候盘经常坏，所以3.5寸盘的塑料盒和5存盘的纸袋是很重要的东西。
后来，接触到的第一个图形化的操作系统是windows 3.2，那个时候我并不知道apple是什么：
操作起来大概是这么个感觉：
没有任务栏、没有开始菜单，非常诡异。再后来的，就是windows95了吧：
win95的界面比较经典，可以看出来现在的windows界面相比win95其实没有太大的变化：
当时的游戏大多都是在dos下的，机器内存又小，为了玩游戏需要切到dos下，关掉95。即便在这么困难的环境下，依然有伟大的作品诞生：
。。。。
那个时候，很多游戏的安装需要靠一个叫arj的解压工具：
中间还有一个改进版的95，被称之为win97，至今我也不知道到底有没有那么一个正式的97出现过，反正很快，98就诞生了：
回想起来，那年开始，我接触的游戏开始变多，我永远忘不了我看到星际的时候的感受：
在那个时代，还有一个称得上传奇的病毒---CIH，以其可以对电脑造成物理伤害而闻名：
98是一个及其不稳定的操作系统，解决98里一些较大问题的唯一法宝往往就是重装，也许正是因为他如火凤凰一般的再生能力，一直到2000和xp诞生之后都有人选择他做自己的操作系统。
而win me。。。很多人根本就不知道他的存在：
不知道现在有几个人知道win me安装完第一次启动时必须忍受那个开机动画的事。再后来就是2000了，其实在win32时代就有windowsNT，微软用它在服务器市场里战斗，不过我个人并没有用过，windows 2000是我接触的第一款微软的服务器级别的操作系统：
到了windows 2000之后我对微软的怨言已经少很多了，呵呵。之后微软家族的产品越出越好，只不过漏洞和病毒依旧多不胜数。XP和2003就不回顾了，反正他们还不算历史。看看前面的这些东西，想想盖茨大叔的退休，该说些什么呢？私底下骂了微软若干年了，反过来看，微软也给我带来了很多乐趣。也许，应该对他说一声，谢谢。
前些天跟朋友聊天，聊得很激烈，我也收获很多。
中间聊到过程，朋友认为，管理的最高境界应该是没有过程，但仔细一问发现，还是有过程的，只不过是一些更人性化的过程而已。结合我另一些朋友的观点，看来“过程”这个词有点招人恨了。（当然如果是瀑布式的过程的话，我会第一个跳出来恨的,:P）
我一直认为过程这种东西，做不好就是枷锁，做好了就是铠甲，让你在工作中左冲右时保障你的安全。这次敏捷大会跟o6z聊天时，他说，虽然他老说敏捷，但他
其实是一个很偏好重型过程的人。其实还是我的那个比喻，只不过重型的铠甲也是铠甲，更适用于直线冲锋陷阵的重装骑兵，但是你要是随便找个步兵团队来配上重装骑兵的铠甲，估计还没打就被压死了。
关于过程这个东西，很有趣。既然想到这了，就像抽取一些自己的零散思维放上来。
我琢磨XP有很长一段时间了，Scrum也看了一段时间，就个人来说，不是很喜欢Scrum。总觉得这个东西天生带有一点滋生官僚这种细菌的潜质。常听说
XP没有管理的内容，Scrum在这方面做的更好。可我还是觉得Scrum没提供什么东西，完全可以把Scrum的一些东西吸收到XP中，结合自己的团队
实践搞一些混合敏捷（Hybrid
Agile）。因为Scrum在管理方面做的东西并没有多少，实在算不上盔甲，顶多是个盾牌。比较起来，XP的话，倒是有丰富的价值观和配套的实践，在吸
取了它的一些本质的东西之后集合公司实际做一些定制化的管理框架更好。
下一步准备研究一下FDD，再考虑跟前面俩方法混搭一下。我感觉这搞过程越来越像J2EE开发了：Struts + Spring + Hibernate一样的玩法。