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一樣的玩法。