买了一些小线椒，洗净切碎，呈到瓷碗里，放稍微多一些的盐和山西老醋泡起来，扣上碟子，放入冰箱腌制，今天早上一闻，那个味道~~~~~真是爽！以后可以买馒头，就着咸鸭蛋一块吃，绝对的美味。

囧，今天去给新员工做入职培训，被一个美女新员工的介绍雷到了，她说高考的时候就立志要来中兴了，7年后的今年终于进来了！好佩服~~~~~~~~说不定会是今后的老总级人物！太忠诚了~~~~~~

昨天一上班就吹响了敏捷开发的集结号，在公司的论坛上召集大家晚上来“集合”。论坛上的帖子竟然引起了南京上海的敏捷团队的关注，还专门发来了邮件。

晚上的时候来的人很少，算上我才四个人，虽然事先已经想到了种种可能，但是还是有些失落的。谁知道，就我们这四个人居然谈的很开心，快2个小时都舍不得散去！

其实敏捷开发只是手段，目的是希望能够提高设计能力。公司的新员工增长的速度非常快，他们就如同一张张白纸，在这个时候如果能够给他们传授好的经验和技能，就会在他们心中放下一颗种子，总有一天会发芽成长。

虽然只有四个人，可是却是一个完整的团队，测试、研发、质量、管理都全了，而且就如同爬山一样，3、5个人最适宜，行动方便，以后甚至可以一边喝酒一边探讨。当然大家在谈论的过程中都看到了敏捷开发在目前现状下的困境，对这个过程是一个长期、艰苦的都有着共识。不过我个人其实一直都觉得，最后是不是真的能够推行下去并不是真正的目的，我看重的是这其中的过程：认识了新的朋友、掌握了新的知识和技能。

我们打算先自己摸索做一些实践，路很漫长，不过千里之行、始于足下，先走起来！

这半年的工作上有太多的不如意，怎么办？看到同学因为换了工作而积极的加班，一边开着玩笑一边在给自己说：我要需要找寻新的动力了！

按照经验，应该去主动的找寻开心，找寻能够让自己开心起来的事情，做自己喜欢的事情会开心！当人开心的时候在回过头看工作上的不如意很可能就不那么悲观了^_^

于是，想起了一个主意：在公司创办敏捷开发团队。

公司的新人很多，其中的毕业生更多，他们还是一张白纸，在这个时候如果能够让他们接触到正确、高效的开发方法，那么不光对于他们本身是一种好处，对于思想的传播更是有好处的。然而，对于这种技术型的团队不是光靠热情的，再加上我们都没有真正敏捷开发的经验，公司本身的项目也并不提倡敏捷开发，所以难度是可想而知的。一个简单的“如何在项目实践中使用测试用例方法”的问题就会让我们无从下手。怎么办呢？想法很多，一步步来吧，总之，好在是做自己感兴趣的事情，不利的因素已经想的很充分了，现在需要的就是：行动！

下周就召开第一次筹备大会，先把大家聚在一起：）

隐喻：普通语言和术语的集合，用来预见项目中的功能。

《敏捷软件开发：原则、模式与实践》一书中对隐喻的解读如下：

隐喻（metaphore）是所有XP实践中最难理解的一个。极限编程者在本质上都是务实主义者，隐喻这个缺乏具体定义的概念使我们觉得很不舒服。的确，一些XP的支持者经常讨论把隐喻从XP的实践中去除。然而，在某种意义上，隐喻却是XP所有实践中最重要的实践之一。

想像一下智力拼图玩具。你怎样知道如何把各个小块拼在一起？显然，每一块都与其他块相邻，并且它的形状必须与相邻的块完美地吻合。如果你无法看到但是具有很好的触觉，那么通过锲而不舍地筛选每个小块，不断地尝试它们的位置，也能够拼出整个图形。

但是，相对于各个小块的形状而言，还有一种更为强大的力量把这些复杂的小块拼装在一起。这就是整张拼图的图案。图案是真正的向导。它的力量是如此之大，以致于如果图案中相邻的两块不具有互相吻合的形状，你就能断定拼图玩具的制作者把玩具做错了。

    这就是隐喻，它是将整个系统联系在一起的全局视图；它是系统的未来景像，是它使得所有单独模块的位置和外观（shape）变得明显直观。如果模块的外观与整个系统的隐喻不符，那么你就知道该模块是错误的。

隐喻通常可以归结为一个名字系统。这些名字提供了一个系统组成元素的词汇表，并且有助于定义它们之间关系。

例如，我曾经开发过一个以每秒60个字符的速度将文本输出到屏幕的系统。以这样的速度，字符充满整个屏幕需要一段时间。所以我们让产生文本的程序把产生的文本放到一个缓冲区中。当缓冲区满了的时候，我们把该程序交换到磁盘上。当缓冲区快要变空时，我们把该程序交换回来并让它继续运行。

    我们用装卸卡车拖运垃圾来比喻整个系统。缓冲区是小卡车，屏幕是垃圾场，程序是垃圾制造者。所有的名字相互吻合，这有助于我们从整体上去考虑系统。

    另举一例，我曾经开发过一个分析网络流量的系统。每30分钟，系统会轮询许多的网络适配器，并从中获取监控数据。每个网络适配器为我们提供一小块由几个单独变量组成的数据，我们称这些数据块为“面包切片”。这些面包切片是待分析的原始数据。分析程序“烤制”这些切片，因而被称为“烤面包机”。我们把数据块中的单个变量称为“面包屑”。总之，它是一个有用并且有趣的隐喻。

       理解隐喻的确是个困难的事情，主要是这个说法太文了，其实我们在平时的开发中是一定会有做到的，只是我们没有将其重视起来。比如，在做一个Java项目时，我们可以在研发规范中要求对于每个对象要有一个属性类，对于这个对象的业务有一个业务类，对于这个对象的处理接口会有一个接口类，加入这个对象的数据库表名为TEST的话，那么它的属性类就是test，业务类是test_business，接口类就是test_instance。于是整个系统有多少数据表，基本上就会有多少套类，从目录结构上很容易看出来实现的进度和类之间的关系。这样的规范在大家接受之后，所有人都会按照这样的思路去做，假如在对代码进行重构的时候发现需要重新生成一个接口类，那么也会按照类似test_instance_xxxx这样的方式给类起名，这样别人看到这个类的时候就不会糊涂了。当然，我们这么做的时候仅仅考虑的是为了方便，从来没有想到这叫什么隐喻。大师之所以称之为大师，就在于他们能够将实践变成理论体系。

爷爷住院了，90多岁的老人需要有人陪护，小便、换药。父亲的兄弟几个人轮流看护，父亲住的最远，每次下班到医院就要1个多小时的时间。作为儿子和孙子总是要尽孝的，于是自己也加入到晚上陪护的队列中，父辈们体谅我，总是担心会影响我第二天的工作。但是晚上陪护却是最辛苦的，所以自己还是坚持一周有一次晚上陪护，这样至少可以让他们多休息一晚。其实本意是自己晚上去陪护了，等于顶替了父亲，他就不用大老远的折腾了，没想到他还是选择了另外一天晚上陪护。

老人晚上真是婴儿睡眠：睡一个小时就醒，要起来小便。以前还听说形容睡得香是婴儿般的睡眠，其实这种睡眠可真是折磨旁人啊。与其这么操心，不如干脆不睡了，带上笔记本电脑，看上一通宵的连续剧。就是第二天白天上班的时候到了下午的时候很痛苦，人处于昏迷的边缘，还不敢睡觉，生怕被领导生擒！

思维混乱的写博，脑子里面总是在想一个问题，爷爷他们生病了好歹还有几个儿子可以轮流照顾。到了父亲一辈老了，我们都是独生子了，怎么办啊~~~~~

啊弥陀佛啊弥陀佛

每周只工作40小时：充分利用你的时间，一个星期工作40小时已经足够了。

       终于说到很多人最热衷的话题上了，加班的话题是永恒的，其实我觉得是否加班并不是主要问题，重要的是这个加班是不是自愿的。

       曾经，为了能够保证项目投标的成功，连续三天两夜的安装、调试系统、完善、装订投标书，反复的对投标时的演讲进行模拟练习，整个团队的人虽然整夜的不眠，靠着咖啡、香烟和快餐来争分夺秒，那个时候身体虽然疲惫，甚至因为长时间在机房受到噪音辐射而呕吐，可是心里却是激动地，为了期望中的成功。也曾经，为了不影响客户白天正常的使用系统，彻夜加班修改白天收集的问题，团队中的成员互相讲笑话来驱逐睡意……。所有的这些辛苦，每每回忆起来总是感到很沸腾。那时候，加班是为了一个明确的目标。

       然而，当加班成为一种常态、一种惯例、甚至一种文化时，所有的一切都变了，有事没事都加班，不加班就意味着工作量不饱满，加班时间甚至成为考核的参考指标。同样一件事情，追求高效的人提前完成了反倒被看作是工作量不饱满，再给加上新的工作，于是，人们的心态发生了变化，使得大家不再追求效率，只是想办法让自己看上去忙忙碌碌。最终的结果就是加班不但没有保证工作的按时完成，反正成了降低效率的诱因。

       或许，正是看到了这个原因，敏捷开发中提出了每周只工作40小时的原则，这一原则的提出自然引起了大家的关注，吸引大家进一步的去了解敏捷开发的理论体系。可以肯定地说，敏捷开发的创始人并不是说每周工作40小时之后就呼呼大睡了，关键的话在这里：“充分利用你的时间”。

       回头来看看配对编程大家就会感受到，其实敏捷开发体系中对时间的要求更加严格，在那种机制下，每个人的8个小时是没有时间干私事的，每周40个小时是真正忙碌和充实的。反观一下我们目前的工作，扪心自问，谁能做到这一点？      

      随着对十二大原则的解读，越是感觉到敏捷开发、极限编程理念中对时间管理的要求，对人员素质的要求，甚至其他各个方面并不是像很多刚刚接触到的人说的那样“宽松”，相反，是要严格的多！所有的原则仿佛都是在为了一个目的：高效。

代码共享：在通过测试的前提下，任何一个人都能够对系统做出修改。

代码共享不单单是对代码阅读修改权限的一个共享，而是一种知识的共享。要想做到在通过测试的前提下，任何一个人都能够对系统作出修改，是需要很多前提的：

l         代码的编写规范是一致的

l         代码的可阅读性

l         熟悉代码对内、对外接口的定义

l         人员的开发技能

在敏捷开发、极限编程的其他几个原则中都已经为实现代码共享作了各种准备工作，例如，简单设计、重构增强了代码的可阅读性，配对编程通过工作方式上的压力实现了深层次的知识共享，编码标准使得代码的编写规范是一致的。

对于研发人员来说，谁都愿意能够学的更多一些，掌握更多的开发技能，这样对自己的职业生涯也是有很大帮助的。然而，在实际的情况中，因为进度的压力，不可能给每个人充足的时间去锻炼成为全才；因为人性，大家都希望自己成为“不可替代”的人而不愿将自己的知识共享；因为技术发展的速度越来越快，我们的精力仅仅够我们成为专业人才而不是全才……。于是，代码共享也就成为了大家都愿意去想（其实作为公司，是最乐意的，这样可以减少人员流失带来的问题），但是却仿佛“永远”难于做好的一件事情。可以这样说，如果没有配对编程，就很难实现代码共享原则。配对编程本来就已经是难于实现了，那么代码共享自然就是难上加难了！