那些傻问题

之前经历过一些项目的Quickstart，也就是前期的需求沟通加上总体设计的阶段。Quickstart的第一天，一般应该会从项目的Goal（目标）开始，与客户一起探讨然后分解为若干Objective（目标）。虽然从中文角度上都为目标，但是前面的那个是我们的排它性目标，而后面那个感觉上是一些分解后的目标。举例子来说前面是：

世界和平

分解后的目标就是：

• 消除战争
• 消除饥饿
• 爱护自然
• ⋯⋯

我一开始就对为什么要有前面的那个目标而感到困惑，为什么不直接由Objective直接进行后面的讨论呢？如果说分解后的目标是需要时刻保证与大目标的一致性的话。那大目标是如何被验证有效的呢？机缘巧合，我碰巧经历了一个工具网站项目。这个项目是由一位心理学博士启动的。核心的理论是：

思考方向：现实的问题->个人的信念 ->个人的意图->个人的承诺 ->个人的行动

针对 具体的问题 保证 信念、意图、承诺与行动相互一致。

结合Quickstart中大目标的问题，大目标其实就是日常问题中所推演出的“行动”。也就是因为战争、饥饿、自然环境恶化等等我们才会拥有这样的大目标。如果说分解后的目标需要和大目标保持一致的话，那么大目标就应该与项目组的承诺保持一致，项目组的承诺需要和项目组的意图保持一致，项目组的意图需要和项目组的信念保持一致。项目组的信念又会变成公司的“行动”，需要与公司的承诺、意图、信念相一致。

我们看到一个好玩的现象：一些行动渐渐就变成了我们的信念。但我关注在行动之前的内容，那些承诺、意图、信念。是不是你已经不记得为什么要有那些信念了吧。或许是某次某人的一句羞辱的话语，让你奋发图强，让你异常积极。这种奋发图强和异常积极变成你达到目标的信念，当日常的挫折与问题出现时临时的行动也会逐渐变成我们的信念。最后我们可能成就斐然，但可能遗忘我们最初的信念。你可能会说Who cases或者So what。

我再举一些例子吧，前一段时间出事情的牛奶企业，使用地沟油的餐馆，天津的“彭宇案”等等。我们为了一个一个的目的而放弃了我们最初的信念，我们把挣钱当成了我们的信念、把完全扯淡的行为当成我们的信念。我们根本看不到我们的底线，为了A所以B，B就是我们的信念。为了B我们得C，C就成了我们的信念。一步一步我们已经习惯把最后的事物当成我们的信念了。

如何能把这一步一步向下的底线向上抬一些呢？

答案是多问自己问题，哪怕是愚蠢的问题。

为什么我会选择C呢？难道我一定要选择B？除了B之外我是否没有选择了？A是我真正的目标吗？我是不是在用这个虚假的目标来掩盖其他的目标呢？难道我非得跟其他人一样？别人是不是错了？我是不是应该休息一下呢？

越来越多的傻问题会提高生命的张度，也会提高你犯傻的机率。犯傻之后你可能会被别人误解，或者讥讽。但我相信，更多的质疑与思考会让你越来越清楚自己的定位和自己的使命。产生新的信念，最后付诸于积极的行动。

抓住你心中的感动瞬间

说到经历，在我脑海里只有一片片感动的瞬间。这些感动的瞬间与你的心灵进行共鸣，如果你抓住了这一个个的瞬间加以放大，你就一步一步的越来越接近你的自己。

就像我10年前写的内容一样：我感觉确实我和计算机有缘，但这缘分让我很充实，让我很单纯……。当时我只是一个计算机操作员，但我抓住了让我感动的瞬间。

工作14年来，我干过操作员、维护员、程序员、项目负责人、部门副经理、咨询师，当然还当过学生、学校的义务老师、天津软件沙龙的组织者，除此之外还有父亲、儿子、丈夫的角色。在角色之中是感动的瞬间，感动瞬间之后是对自己认识，认识之后是一个又一个的抉择。这一个又一个的抉择使我走得更远，起码是心灵层面上是这样的。

当维护员的某个下班之后的夜晚，我站在单位的院子里面，看着面前我成天跑来跑去维护计算机的大楼。我非常清晰的看到了在墙之后每层楼上的每台计算机，在每台计算机的旁边连接的网线通向哪里，网线汇聚到哪台交换机，交换机的哪些灯亮着。我感觉太熟悉了，这种熟悉让我感觉到害怕。我决定辞职去北京学习英语。

当部门副经理的日子，我有个相当给力的下属。我给他布置了一些任务，问他什么时候能给我结果，他说下周3给我。下周3我问他进度如何，他眼巴巴的看着我，说没有进度。我有点生气，再问什么时候能给结果，答曰下周3。等到时候我再问他的时候，他还是无辜的看着我，进度为0。我语气有点重的说：你这些事情让谁帮你做？毛主席吗？他说：他说毛主席要吗？我当时恨不得把他踢出办公室。无奈我无法开除这个人，我深刻感觉与他为同事是我的耻辱。所以决定离开公司。

在公司组织的旅游活动中，一路上听@假装思考的马波 讲故事，从科幻小说到恐怖故事，从物理学知识到之前的项目经历。我深深被震撼了，并不是因为他知识的渊博，而是我知识的匮乏。回来之后，我划分了4个方面：历史，文学、技术、哲学。每一个方面都开始进行系统的学习。这几年看过的书总结一下是之前十年总和的若干倍。获得更多的知识不是为了使我更强，而是我就想获得那些知识。现在我看的书籍集中在管理、哲学和少量的技术方面。

项目中期某场技术讨论之后，我们所做的决定似乎不能让每一个人满意。每一个人都有点颓废的走出会议室，@艺术滴扯淡  突然来了一句：是我们把这东西做废了啊。作为团队负责人的我当时就沉默了。是啊，一个全新的项目被我们做成这个样子，这个项目不就是被我们一个又一个的决定推到了现在这个样子吗。项目成功交付很久以后，虽然很多人跟我说那个项目是他们经历过的最好的项目，但是对我来说每一个未来的决定都会被这一句话所影响。

某个项目启动阶段，我与 @vvvvy1984 说明一些项目事项。这家伙一个问题接着一个问题，感觉像挑战我似的。最后我有点不耐烦了，他可能也看出我的表情，说到：我就是一个问题青年。当时我一下子就冷却了下来，确实问题就是问题，暴露比掩盖好的多、积极比消极好的多。从那个时候起，我也变成了一位“问题青年”。虽然有的时候大家会感觉有点讨厌，有驳于老祖宗的中庸之道。但是对事情我认为就应该这样。

一路走来，现在的我属于待业状态。但读书、编程不会停止。因为心已经跟随而去，我也只好随心而动。

三个为2012准备的心得

关注2012相关话题已经有一段时间了，看过的资料很多长时间了。有几个心得跟大家分享：

1、从众心理要不得

大多数人的选择取向一般是机会较少的选择。如果你想获得比别人更多的机会，那就不要跟随大多数人的选择。人性的野兽一面会随着资源的缺少而充分暴露。比如，在所有人被一些事情吓傻，落荒而逃的时候，千万别兴高采烈的背着准备好的行囊一起逃亡。 你的装备别人会羡慕，嫉妒，恨的。而且灾难不会突然降临（如果突然的话，躲也没用），灾难会一步一步降临，并且以多米诺骨牌形式造成对咱们各个层面的冲击。如果是这样的话，第一个崩溃的是人们的心理。所以灾难之中从众会更为危险。

可实施技巧：大家干什么我不干什么。比如大家相信，我就应该质疑。大家疯狂出逃，我就应该去超市储备资源，尽可能的休息。大家疯狂储备资源，我就应该考虑如何撤退。

注意事项：这里所说的众，是你目光所及的人们，包括你的家人朋友。

2、做好应有的准备

有的人说了半天的灾难，在网络上找了半天的资料。发现说法不一，有的说内蒙安全，有的说江西安全，有的说西藏安全。他们关注着这些信息，思考着要是出事的话，我逃到哪里。但家中最基本的应急物品还是没有准备，咱就别说世界毁灭，咱就说家人突然被火烫着了，你家里有马上能用的药品吗？行动才是真正能够改变事物，所以先把基本设备准备一些，因为这些东西怎么都能用的到。

可实施技巧：
美國聯邦緊急救難管理局 建议的计划

http://www.ready.gov/america/translations/chinese/seniors.html

和所建议的救生包内容

http://www.ready.gov/america/translations/chinese/getakitindex.html

注意事项：水和食物重要，别的都是浮云

3、开放并且感恩的心

昨天火车相撞，今天高速公路死几十个人，明天泰国都被淹。一方面，这些新闻咱们天天看，别想着时日不多。你应该认为每天都是你的最后一天，如果是最后一天的话你会干什么？另一方面，你应该想到这就是世界，一切都很自然。

我看过一些关于进化的书，进化有一个特性叫做“并行”。也就是说人要想进化，必须要很多人。比如猴子到人的进化，就是有一批猴子决定从树上走到地上（它们可能是被逼的）。刚才是把一个整体看成进化单元，但如果是一个人为一个进化单元的话如何能够实现进化呢？那就是善于否定自己，使自己更为客观一些。就像小孩子能够听进去别人的话一样，你得先认为自己的想法是错误的，这样别人的观点才能进入你的思考之中。

有人有不同的看法很好，这是进化的一部分。说不定人家说的对呢，另外人家不分享你如何能够知道这些想法的呢？

可实施技巧：别人的帮忙说声“谢谢”，哪怕是你的家人或是最亲密的朋友。

注意事项：先感谢国家

机会中的我们与我们的机会（Opportunism vs Justice）

I always wondering why most Chinese people doing everything in rush ,why quarrel due to trifle and why we always copy others idea but leak of innovation.

我总是奇怪为什么大部分的中国人总是很着急的做着事情，为什么因为一些小事而争吵起来，为什么没有精彩的创意而总是在模仿别人。

I admit that the problems related with education. But I do not believe that education can solve all my concerns.

我承认这可能教育问题有关，但我不觉得教育可以解释我大部分的困扰。

Recently I feel that the thick opportunism complex around us. Maybe that can explain some of mine questions.

最近发现在我们的周围围绕着浓厚的机会主义情结，而这种情结可能能够解释我的一些问题。

Right now we tend to be more believe in opportunism instead of justice. I think every one of us have this kind of opportunism complex. And I feel like this kind of complex related with environment.

我们在过分崇尚机会而忽略了应有的正义。在每一个中国人的脑子里面或多或少都存在这种机会主义情结，因为环境使然。

Let’s from examples:

我们还是从例子开始：

Example 1:

例子1：

Last Saturday I went to buffet dinner. The queue was very long. I found there is another cashier front the queue so I heading to the second cashier and people behind me still following me.  But after I told can not pay at that cashier I be come last people in the original queue since people behind me more close to original line. I was little surprise I am not complain to this and let it happen.

我前几天去吃自助餐，排队结帐。我发现前面还有第二个收银台，我走过去，身后的人也跟着我走了过去。但是我被告知这个银台不能够结帐的时候，我身后的人比我更快的回到了之前的队伍，我只能在他之后排着。因为他拥有我没有拥有的机会“离之前的队近”，我很惊讶我没有对此提出异议，并默许了这件事情的发生。

Example 2:

例子2：

If you want to buy house in Beijing and you are not Beijing local people you will need to have 5 years Beijing tax certification. Local people or foreigner no need the certificate.  another case is buying new car in Beijing we need do lucky draw. Every people envy this kind of chance.

如果你是一个外地人，想在北京买房子，你需要出具在北京5年的缴税记录。本地人或者外国人不用出具这种记录。说到买车就更邪乎了“摇号”不一定谁能买到汽车。对于本地人买房或者摇到号的买车人他们很幸运，大家开始羡慕这种机会。

Opportunism will guide us to a waiting game. This have two parts meanings. One is wait for the real value and benefit. Second is wait for chance on potential value.

机会主义会导致大家“伺机而动”。这里有两种含义，第一种含义是为了利益或价值而寻找机会采取行动。第二种含义是为了有可能获得潜在的利益或是价值的机会而采取行动。

This article mainly talking about second meaning of opportunism.

这里的机会主义我是指的第二种含义。

这也就能够解释为什么人与人之间发生小摩擦之后为什么总是选择争吵来决绝问题，换句话说就是展现谁更强。强势的人会获得更多的机会，这种机会显而易见不用过多的思考。胜过礼貌的承认错误，胜过了平静思考自己的过失。我们生怕错失了“机会”。

这也就能够解释为什么大部分的家长给孩子上培训班是为了考试能够加分的原因，因为家长想给孩子更多的机会而已。

这也就能够解释为什么我们买来ipad一定要等着破解的原因，因为我们不想放弃安装很多很多收费软件的机会。

So what

你可能会说这和我们有什么关系，我们认同你的观点又怎么样。

我希望大家能放下过多的机会，过多的机会会使我们无所适从，会使我们迷茫。这种迷茫和无所适从感会侵蚀我们的希望，换句话说就是我们对自己的不透明性会影响我们发现自己的过程。一个人如果连自己都不了解，如何了解他人。

就象精益有使流程更快和更慢两种方向的力一样，我们需要放弃一些东西使我们更关注于某一点，而不是一味的增加速度。

Scrum认证是否可以作为学习敏捷开发的开始?

前几天跟别人聊天，谈到敏捷总是谈到Scrum，并且问我是否获得认证。我表示了对敏捷认证的抵触，他认为Scrum认证是学习敏捷的一个开始。当时这个话题没有继续，但我相信有这种想法的人不在少数。但这是否正确呢？虽然我不是Scrum的专家，但我想尝试探讨一下这个问题，让我们从头开始吧。

首先，什么是敏捷呢？

敏捷 Agile最初来源于拉丁词根ag, agi, agit, act也就是to lead, to drive, to do的意思。这让我想起了对立面的一些词汇：跟随，静止。翻阅词典之后发现，agile本身有三种解释：1，快速且协调运动。2，积极的，有活力的。3，思维快速。但是这种行动来自何方？是什么使你有做的动力呢？ 是勇气。想象一下失去勇气的你在什么情况下才能做出行动。在勇气之前呢？那就是一颗勇于面对变化，且积极的心。

那什么是Scrum呢？

来自Wikipedia的解释是

“Scrum is a process skeleton which contains sets of practices and predefined roles.”

Scrum就是一个包含一些内容的过程。这个过程框架给出一些实践与预定义角色可供使用者进行剪裁并形成适合使用者的过程。它定义了过程中的角色、会议与工件(Product backlog, Sprint backlog, Burn down)。

我们再回过头来说说敏捷开发，最能够诠释敏捷开发的是敏捷宣言了。接下来我们将回顾一下经典并且尝试比较一下Scrum，这里需要注意的是 over 后面的内容敏捷不是认为它没有价值，而是前面的价值更多。

• 个体与交互 over 过程与工具
  • Scrum是一个过程的框架，虽然在过程的角度上尽可能的保证交互，但过程缺乏对个体的关注。这让我想起了CMMI，同样的关心过程、同样的宣称可以剪裁、同样的实施认证。如此一来过程的还是过程，套路不同而已，且多了噱头；关心交付的还是关心交付，对大家的考核框架根本没有涉及。总结起来就是，Scrum对过程和工具有所涉及，对个体与交互只是在过程中进行体现。
• 可以工作的软件 over 面面俱到的文档
  • Scrum定义了一些工件( Artifacts)，在中文版本的wiki中更是直接翻译成了“文档”，如果一个过程能够保证可工作的软件的话，那CMM早就可以了。“可工作的软件”这句话在我看来是敏捷开发宣言中最重要的一句话，也就是说敏捷更关心交付，但Scrum只是在精神层面上给我们暗示了方向。拿到认证的人们是否感受到这种暗示呢？对于代码来说隐性的东西是会受到批判的，因为如果你认为什么东西是好的，就应该显性的表示出来，不能让后来看代码的人有错误的想法。使用过程来实现敏捷价值观简直就是隔靴搔痒。
• 客户协作 over 合同谈判
  • 对于这项Scrum规定了客户建议扮演的角色和在过程中应该承担的责任。最有意思的是那个火腿鸡蛋的比喻，Stakeholders (customers, vendors)作为鸡的角色进入项目，试想一下如果用户不能积极参与项目的话，何谈交付。
• 响应变化 over 遵循计划
  • 说到遵循计划与响应变化，我就想起了一个朋友跟我说起的一个段子。他说：你听说过Scrum吗？你肯定没有见过这么烂的软件开发方法论。举个例子来说，比如一个足球游戏，突然在足球场上发现了两个足球，整个项目组还需要等一个月才能着手修正这个问题。当时我很无语，我也不知道这是Scrum的问题还是使用者本身的问题（当然肯定不是方法论的问题;-）。但若干年前我们使用CMM不就是这个样子吗？

说到最后，我还是对敏捷认证保留意见。首先你拿Scrum认证的目的是什么？如果为了更好的软件过程，这个证书又能代表什么？代表你了解了一些过程？还是你嘴中多了一个和别人忽悠的噱头？代表你愿意学习敏捷的意愿？还是职业生涯的又一个资本？

我们为了制造出更好的软件已经学习了太多太多的东西了，而在学习的过程我们在不停充实自己的过程中是否还记得我们最初的初衷？我们是不是应该尝试丢弃一些过程？丢弃一些实践？丢弃一些角色？丢弃一些会议？看看我们是不是还能做出好的软件。认证就类似一门考试，我们在追求考试的过程是不是这本身就不够敏捷？我们是不是想要的太多了？一方面要做好软件，一方面自己要紧跟时代的步伐，一方面要为自己的职业生涯添砖加瓦……

任何一种事物都在于我们对它的理解，从而产生巨大的不同。就如同小时候看到糖果的我，我会对它产生心理上的冲动，不光因为它的味道，父母的严令禁止也是原因之一，直接导致的结果就是牙齿的问题。对于Scrum来说，技术层面上讲我没有任何意见。但它的推广过程中所采取的方式，有可能会对结果造成影响。尽管它可能很火，尽管市场份额可能很大，尽管它可能成为潮流。

引用我一个朋友列出的敏捷学习过程，需要重点指出的是，他把Scrum的学习放在了第一步：

• 过程的敏捷（学习并尝试敏捷的套路）
• 痛苦的敏捷（学习并尝试与代码相关的敏捷实践）
• 真正的敏捷（学习并尝试实现敏捷深层次的价值）

最后，我相信 法无四乘。人心自有等差。不在乎套路也不在乎门派，关键在于内心。

我们的程序员素质难道真的不如以前？

当和一些朋友聊天的时候，经常会谈起现在的程序员的素质。朋友感叹道现在的程序员做完程序测试都不测试，发现一堆错误；做一个功能不动脑子想想到底有没有更佳的解决方案；对新技术跟进的主动性太差，诸如此类。又说道想当年的程序员是多么的细致、善于思考而且专业。感叹啊……感叹啊……。当然我的这些朋友大都已经不在开发工作岗位上，而是在管理工作岗位上。每次说到这些内容的时候我一般比较沉默。我在想难道程序员的素质真不如以前的前辈吗？

我不否认程序员个人能力的不同会影响最终的工作效果。但对于这个问题我们需要再认真的分析一下：

我们先回到对程序员评价的标准上，对程序员的要求到底是什么？我认为上面提到的种种程序员的问题是传递商业价值的过程中暴露出来的。也就是说用户在使用或配合建造软件的过程中发现问题才会间接反应程序员的问题。这里把测试部门的测试也当成用户的使用，因为在测试过程中发现的问题一样要拿到程序员的手中返工或改正，这也是浪费金钱的一种方式。总之我们考核程序员是传递商业价值效果的考核。我们列表对比现在和过去的细节情况：

这里需要说明一下的是，在过去IT部门的人员很少所以人员的考核是在整个IT部门的范围内考核程序员的绩效情况。现在的情况是由于职责划分，原来的开发部门分解为若干业务单元。比如专门负责需求的需求业务单元、负责测试的测试业务单元、负责后期维护的运行维护业务单元等等。试想一下，如果传递商业价值已经不作为考核的一部分，取而代之的是你写了多少行代码或者是否听话的干活。反正换了我，我也会对本业务单元负责的，毕竟工资是这么来的。

我们再比较一下过去和现在在团队上的区别：

对于团队上的区别和企业的IT信息化需求是紧密相联系的。在过去企业还处在努力实现人手一台计算机的阶段，精力大部分放在硬件或系统部分。但是现在随着软件系统需求的爆炸式增长，人员不可避免的增多。但在软件项目疯狂吸取人员资源的过程中，领导往往忙于应对人员的调配和各自业务单元利益当中。大家可能都没有发现：高质量的骨干人员出现断档，而且缺口越来越大……

技术也是非常关键的因素之一，我们来看看过去和现在的对比：

显而易见，我们现在面对的技术和过去面对的技术从信息来源、厂商数量、平台数量、需求层次都已经不能同日而语了。如果说原来客户吃稀饭加咸菜就算一顿好的早点的话，现在的客户你不给他做出，西式、广式、粤式、川式的早点就算你失职。

总结上面的内容，我认为考核方式是致命的。如果选择一种适当的考核方式会促进IT人员的努力。反之会抹杀IT人员的创造力。有一句话是：如果你期望得到一堆搬砖头的程序员，那么你就会得到一堆会搬砖头的程序员。

当一座山挡住唐僧师徒取经之路的时候

突然：

A精灵(为了弱化褒贬，这里使用“精灵”一词)跳出来，推销高性能推土机……

B精灵声称能带领师徒四人翻过此山……

C精灵好心的告诉师徒四人真经不在西方，而在东方……

作为唐僧，你该如何应对这些“好心”的帮助？你又如何真正的取得真经呢？

    你敢听从几个精灵的建议吗？你怎么能保证精灵们是真心想协助你取得真经的呢？
任何听从精灵话的人都会为之付出代价（记得有前辈跟我说过吃馒头也会有副作用，只不过大小多少的区别罢了。这里“代价”约等于“副作用”，因为我们无法确
定这些精灵的目的），有的代价可能是多跑些路就能够挽回，但有的代价则是惨重的。

    翻过山的目的也是为了获取真经，获取真经的话你需要一个团队，并且听从团队的建议。这只团队首先应该是经得起考验的团队，团队中的队员会帮
助你获得真经，翻过这座大山只不过是表象而已。尽管可能每个人的具体目的不同，但是理想团队中的每一个人都应该是希望团队获取真经的；团队在获取真经的过
程中、在取得最终结果时，团队中的个人也会因此获得“真经”。能意识到这一点的队员，就非常好管理，因为他的目标和团队的目标一致。但如果队员们只看到每
天分到的干粮，那管理起来就异常艰苦。 如果取经四人之中最清楚团队目的的只有一个唐僧，那么我个人认为，这个师傅是不称职的。

    那如何分辨哪些是精灵而那些是队员呢？
是不是在团队里面待的时间长就是队员呢？非也，说不定精灵已经伴随你很长时间了。最关键的是目标是否与团队相同，从这个角度来看的话，团队中只看重每天分
到手中干粮的那些队员也可以划到精灵一组中，只有目标与团队一致且明确的人才是真正的队员。

    所以，你今天问问你的“队员”吧，看看他是否能说出团队真正的目标。

谁在挖陷阱？最后谁被陷进去？

有一个公司要盖一栋办公大楼，成立了一个建设小组。小组决定引用W公司的基础建设方案，这种方案虽然安全性高但维护成本更为惊人，这样的话只要公司
还住在这个大楼的话，关于大楼建设以及扩展的问题就只能依靠这个建设小组来解决，因为社会上的其他建筑公司对W公司的产品非常陌生。

引入初期的效果是不错的，施工过程是成功的。地基打得非常深（当然钱花得也非常不错），大楼的框架在不长的时间就搭建起来了。建设小组发现一个新的
问题：对于W公司的基础架构的装修方案只能依赖W公司来进行。其他的装修公司对于W公司的基础架构相对陌生，这样的话建设小组为了保证大厦的顺利入住所以
又选用W公司的装修方案。装修工作非常不顺利，因为在装修工作过程中一方面W公司推荐建设小组购买很多巨型工具，并声称如果不用这些工具效果会大打折扣，
比如：桌椅自动摆放器、电话自动摆放设备、垃圾自动倾倒设备和自动化地毯铺装机等设备。另一方面对于各个办公室的设备布局设计，如桌椅的摆放、电话的摆放
等需要建设小组和业务部分的签字确认。一经确认，如要变动位置只能再签订合同。W公司工程师一天的工资可是8000人民币啊，更为郁闷的是原先建设小组想
对于摆放问题可以使用自己的人力解决。但是非常不幸的是在W公司的全套框架下，建设小组根本无法实现桌椅灵活摆放。

虽然非常别扭，但是最后公司还是勉强搬入了新大楼。

各个业务部门的办公用品换位置的需求已经快让建设小组崩溃了。经过若干年的学习，建设小组还是无法灵活的使用W公司的各种工具进行办公室内各种办公用品的摆放。公司高层已经感觉到建设小组的问题了，决定要彻底修正错误。建设小组的人已经慢慢的被调走了……

About learning

在邮件组里面遇到新同学的问题，我简单的说了说自己的想法。放到这里等待大家的高见…

提问：
这几天正在努力的学习基础知识，发现自己不懂的地方还很多，有些东西心里明白
但就是不知道该怎么说，看来自己还停留在比较肤浅的层次，找工作倒不急，努力学习才是正道
学习贵在融会贯通，JAVA技术太过庞杂，层出不穷，要想融会贯通，灵活运用不是一件容易的事

这么多新技术，该怎么去学，我以前的思路是用到什么学什么，不用的话就不去管他，但这样好象有点偏激，而且容易造成自己的知识结构不完整。
我们该去追求深度还是广度，或者说我们应该偏向那一方，时间和精力是有限，困难的是怎么去把握这个度呢？
请教各位前辈
当一种新技术出现的时候 该怎么去面对？
当我们学习一种新技术的时候
该怎么去学习呢？有没有比较好的步骤和方法？

回答：
首先我不是精力旺盛的人，如果您精力旺盛请直接跳过这些文字，谢谢

我一般是
多看、少用、勤动手
多看就是什么都看看，非常简单的看，了解功能就成
少用就是尽量少的使用，不得已才选用，选择前途光明的东西
勤动手就是多看使用工具的源代码，进一步了解你所用的东西

用剪子同样能剃头，你新学会用推子也不能代表你剃头剃得好
推子我以前用不着，所以不想学了。但最近经常来平头的活，没有办法。
突然发现有电动推子了

但说回来了，找工作的话似乎会用的工具越多越好，如果你想多写点东西的话我推荐你学学.net或者ruby，这样感觉更有分量。

你表达意思一般使用中国话，但是你学过英语之后可以用另外的语言来表达自己的想法，而且感觉表达的程度不一样。这就是为什么劝你多学几种语言的用意。

归根到底，你需要提高你对软件的理解、对面向对象的理解、对不同项目的理解、对身处环境的理解。

ps:怎么我说的感觉这么别扭呢，像个道士或者和尚说的吧。哈哈…

最近IBM给我们做项目，有个基于Hessian的远程调用的工具，死活不肯开放源代码
而且感觉过渡设计了。一不做二不休解剖了，重新做一个。唉，用开源的东西用习惯了……

好久不写blog了，这篇就当我的一篇文章吧

CMM 评估

    今天我作为一名开发人员接受CMM3级的评估，和评估师聊了差不多一个下午。因为一直关心敏捷方法论所以一直带着评估师跑题跑到方法论的谁是谁非上了。评估师一再强调：
1、软件是一个工程概念，这有别于前些年的软件艺术（英雄主义）概念。
2、软件需要从企业的宏观角度来来审视，而不是开发的微观角度。

 我一开始还和评估师瞎侃，后来他们开始说这些了。我赶快见好就收：闭上嘴巴，对着他们频繁点头、微笑。

我认为：

1、软件是一个结合工程和艺术的概念，可能因为你的视角不同而重点不同。就像我经常举的那个例子：开发软件是照着菜谱做菜还是发明菜谱，答案肯定是
发明菜谱。你我无法知道新的配料如何炒出可口的菜肴。如果你认为你黄瓜、冬瓜的炒法你很熟练的话，你就可以写出任何瓜类的新菜谱的发明步骤，那就是大错特
错了。再说了，我还真没有见过哪个设计师写过的设计经过实践不反复修改的。

if (我对浪费视而无睹&&我没有项目压力&&我的工资很丰厚)
我会完全按照CMM的要求，生成所有详细设计并进行评审之后再开始编码。
else
概要设计评审之后，我就进入交互设计和编码阶段并同时自动化生成详细设计

2、一个企业应该从自身的角度来审视软件开发，但是不能忽略人的因素。就像有些软件企业的老板在程序员们下班之后的感慨：我感觉现在我一无所有。确实这是个问题，但是如果文档写得都背离了初衷，没有人在看，只有人在检查的话。我认为完全没有存在的必要。沟通是有很多种方式：

如果你感觉不能喊一嗓子完成命令的传达，你就需要打电话。
如果你感觉这次传达的命令需要进行记录，你就需要写邮件。
如果你感觉你以后可能需要频繁的查询的话，你就需要查询功能强大的邮件客户端。

一切都不是银弹，没有解决一切的方法论。我喜欢极限编程书中的一句话：如果你在想我如何能解决这个问题的时候，说不定为了达到目标而出现问题的方法本身就是一个错误。