在2005年11月份左右，我還是微軟一個普通的合同工，當(dāng)時我和Volt Computer Services的合同差不多過期了，我剛剛把我的夫人接到美國，不找份正式工作心里不踏實。我一開始先嘗試著在微軟找份工作，我去了一個MS Office測試組的面試，結(jié)果面試發(fā)現(xiàn)這個組使用手動測試居多，自動化測試很少。我的能力和方向和他們相差還很大，自然沒有通過。我當(dāng)時所在的小組又沒有任何全職機(jī)會，所以我就開始尋找雷德蒙地區(qū)（華盛頓州的微軟的老窩）其他機(jī)會。有一天我收到了一封來自Peter Stroeve的信，可能是我在HotJob上張貼的Resume引來的注意。我和他來回了幾封電子信，我最后決定去這個名叫Net Objectives 的公司進(jìn)行一個面試。當(dāng)時我們就聊了聊天，我和Peter見了面，他是個很沉默的人，和他一起的還有David Moynohiem（不知道有沒拼錯），后來還來了一位Kevin Yu（廣東人）。我和他們海吹山侃地聊了25分鐘，然后又做了些他們出的題目。他們對我非常滿意，就派我到MSN旗下一個搞上網(wǎng)安全軟件的小組面試。我輕松搞定了這個簡單面試。
隨后我開始了我事業(yè)生命中最光彩，最難忘的經(jīng)歷。當(dāng)時David告訴我說，這是一個微軟MSN的外包項目，我們準(zhǔn)備用了Lean & Agile的管理模式來進(jìn)行這個項目的設(shè)計和制作。我不知道這個Lean & Agile究竟是什么，我當(dāng)時心想不管怎么樣，先當(dāng)優(yōu)秀的士兵，在連長安排下沖鋒陷陣，做好本職工作，發(fā)揮110%的自我能力，肯定沒有問題。我打心里就不相信所謂的Lean & Agile能夠做好一個軟件。當(dāng)時我看到的微軟在Vista上的人員互動，我對軟件設(shè)計管理丟失了信心，我只知道自己能力不錯，能處理任何問題，當(dāng)時的信念是“一夫當(dāng)關(guān)，萬夫莫開”。我對自己的能力的信任是沒有任何疑問的。
第一個星期整個小組在招人，和我同時選上的還有一名叫 Nadim Rubeiz 的黎巴嫩人，Kevin是項目負(fù)責(zé)人。后來我們又招了一個叫Brian Young的測試員。他是個硬件驅(qū)動高手，對視窗內(nèi)核和驅(qū)動設(shè)計了如指掌，是個不折不扣的高手。我們又招了一個叫Said Fathababel的埃及人，此人對視窗內(nèi)部的構(gòu)造十分了解，也是高手。Brian和Said都有一定的問題，我后面再慢慢敘述。這第一周我們先是選定辦公地點，是公司中一個稍大的會議廳，Kevin定購了一張很大的會議桌，我們四人團(tuán)團(tuán)圍著桌子坐，當(dāng)時我覺得這樣辦公好寒慘。幾分鐘后才知道這才是Lean & Agile的最佳工作方式。我們隨后安裝了新買的Dell電腦，開始將所有的任務(wù)寫在紙上，貼在窗上。我們的開發(fā)就此開始。
第一個星期的工作基本上是投石問路，我們大概知道我們的用戶期待的是什么，我們大體把前三個星期該做的事列舉下來了，第一周過后，我們和客戶見面進(jìn)行了45分鐘的會談，首先Kevin介紹了Lean& Agile的管理原理，我們外包人員是一輛汽車，我們的客戶是駕駛員，客戶的意愿加上我們的做事程序，將完成客戶所期待的價值。隨后我們把該做的事和客戶進(jìn)行溝通，選出了兩周左右該做的事。這些都叫“故事”（Stories），最準(zhǔn)確的名稱應(yīng)該是“任務(wù)”。我們把故事的重要性進(jìn)行分類；最重要最急迫的被劃分并放入“Front Burner”；不急不緩的“故事”被放入“Back Burner”；最不急的“故事”被放進(jìn)“Cold Frig”。所有最重要的“故事”必須在第一個開發(fā)周期（兩周）內(nèi)完成。這并不是硬性指標(biāo)，因為完不成的任務(wù)往往是重要“故事”中最不重要的任務(wù)。這些完不成的任務(wù)和“Back Burner”中的任務(wù)重新被衡量，最重要的這些未完成的“故事”被選擇到“Front Burner”中，作為下一周期中該進(jìn)行的任務(wù)。就這樣周而復(fù)始地，所有的任務(wù)要么在最后基本完成，要么時間全部用完但是一部分任務(wù)根本沒有完成，而這些“故事”正是客戶不需要的。這就是Lean & Agile。
我們開完會，回到公司開始開工。我們先總結(jié)了一天的工作，這是一個15分鐘的短會，叫“Scrum”。每個人必須站立著，向工程負(fù)責(zé)人匯報昨天作的事，這是每個開發(fā)人員每天做的一件事。然后在每個周期開始，我們要進(jìn)行設(shè)計會議，我們把故事細(xì)化，然后把所有的故事列在白板上，大家每人選擇一個自己有興趣的“故事”去做，做完驗收后，再選擇一個新的“故事”去做。我們第一個開發(fā)周期的進(jìn)度完成地非常順利，我們設(shè)計了一個簡單的用戶界面，然后是一個簡單的中間件，最后是一個后臺數(shù)據(jù)存儲件。設(shè)計的時候我們遵循了“測試為先，開發(fā)隨后”（Test Driven Development）的設(shè)計準(zhǔn)則，利用CxxText作為我們的單元測試框架，事實上我們好多測試都是用CxxUnit來完成的，我們除了硬件，操作系統(tǒng)，和Visual Studio .Net 2005外所有的資源都是自己搞出來的，微軟貢獻(xiàn)的，或是開源資源。我們五個人組成的開發(fā)團(tuán)隊最大的價值是我們過硬的技術(shù)能力，這些基本上就能在外包行業(yè)賺取利潤。當(dāng)然，這并不代表我們的團(tuán)隊沒有任何問題。下面我就要談?wù)勎覀兯鎸Φ膯栴}。
從第二周開始，我們的進(jìn)度就開始影響。首先是Brian在第一個開發(fā)周期時沒有完成他所要完成的測試任務(wù)。事實他在整個開發(fā)過程中沒有做什么事，他有一個不滿周歲的小孩，每天不到10：30或11：00我們不一定能見到他走進(jìn)辦公室。下午早在3：30，就見他準(zhǔn)備回家接孩子。好在他的合約簽的是合同制，否則這樣每天五小時的工作算成八小時的工作，我們的公司不是被他騙去不少錢。隨即出現(xiàn)的問題是，Lean & Agile要求組配對設(shè)計，兩人一起解決一個設(shè)計問題，這需要兩人相互給對方提意見，然后相互吸取對方的意見，這種做法就是強(qiáng)迫設(shè)計小組中的任意兩人進(jìn)行取長補(bǔ)短。既然這是一種硬性規(guī)定，我們就必須虛心相互溝通。Brian并不是這樣的人，他的智商可能有156，所以他認(rèn)為所有的人都比他愚蠢。我根本和他合不來，我的意見他根本聽不進(jìn)去。一個簡單的測試程序我們爭吵了三四小時，我覺得這個程序五十行碼就能寫完，他偏偏要用各種鉆進(jìn)牛角尖的方法進(jìn)行設(shè)計，我的簡單設(shè)計他聽不進(jìn)去，我也無法說服他采納我的意見，然后我只好和他抬杠。這種情況本身就是與Lean & Agile背道而馳的。面對這樣的問題我毫無辦法。等到我們的程序突破三百行代碼時，我們才設(shè)計了整個程序的一半。我實在無法控制這樣的局面，在他離開后就只好向Kevin坦白我實在無法和他溝通。Said和Brian幾天前出現(xiàn)過同樣的問題，他們甚至為雙方的專業(yè)背景而產(chǎn)生爭執(zhí)。事情是這樣，Said背雇傭后，Brian問他是否是搞驅(qū)動背景的。當(dāng)時Brian的態(tài)度很不好，給Said的感覺是Brian 藐視了他對小組能做出的貢獻(xiàn)。當(dāng)時大家的心態(tài)都很不好，我們?nèi)耍ㄎ遥珺rian，Said）都在微軟工作過，我們剛剛被Layoff，大家都希望自己在這個新公司里的位置穩(wěn)一點。Brian大概是害怕Said作為一個懂視窗結(jié)構(gòu)的老手來奪取他在公司里的位置，而Said則覺得自己好不容易在丟了工作后找到這么一個來之不易的機(jī)會又受到一個年輕Punk的排擠。Said氣忿之下兩人就爭吵起來，后來我們只好開會互相諒解。后來Nadim花費(fèi)了一個上午才說服Brian嘗試簡單的設(shè)計思路。后面我們發(fā)現(xiàn)Brian和整個小組的配合并不很好，所以我們后面的做法是，盡可能少給他事情做，將他變成一個可以隨便取代的成員。因為他擁有更好的測試手段，和硬件測試技術(shù)，有利用價值，所以我們一直容忍他的不作為到項目結(jié)束，最后我們也發(fā)現(xiàn)他的存在確實在關(guān)鍵是可能幫上忙，正應(yīng)驗了古時候“雞鳴狗盜”故事中的寓意。
在第二個開發(fā)周期的前期， Nadim 重新設(shè)計了后臺數(shù)據(jù)存儲系統(tǒng)。然后我們重復(fù)了幾次有關(guān)UNICODE和ANSI的爭執(zhí)。Nadim希望使用ANSI編碼作為后臺數(shù)據(jù)存儲系統(tǒng)文件的編碼，這樣文件的大小比較小。我覺得視窗都是用UNICODE編碼，如果使用ANSI，我們要用一堆的轉(zhuǎn)換函數(shù)，這是非常繁瑣的操作。具體的原因我也不記得了，我們改了兩次，最終將設(shè)計定為用UNICODE編碼作為后臺數(shù)據(jù)存儲系統(tǒng)文件的編碼。我也在設(shè)計中犯過錯誤，我和Said花費(fèi)了三小時設(shè)計了用戶界面和中間件銜接。Nadim來了以后審核了我們的工作，結(jié)果推翻了我的設(shè)計，我們花了一小時半，將所有的設(shè)計重新搞了一遍。我當(dāng)時非常惱火，但是仔細(xì)看了看他的設(shè)計思路，他的思路更好，完全分開了中間件和用戶界面。這時我才意識到這樣成對進(jìn)行設(shè)計的好處就是取長補(bǔ)短，這種好處是有條件的，兩人都必須是水平相等的；兩人都必須是有一定深度的開發(fā)能力；兩人都必須尊重對方，并能接受成對設(shè)計這種思想。
在第二個開發(fā)周期中，最大的一次問題是第二個星期的星期五。我們把所有的設(shè)計源碼上交后準(zhǔn)備回家，結(jié)果單元測試輸出了六十多個錯誤。結(jié)果我們仔細(xì)察了一下，有人沒有完全做好自己的單元測試，就隨隨便便提交了自己的代碼。這個人是Said。既然出了問題，那我只好留下來陪他把問題解決。那天是2005圣誕前夕，Brian已經(jīng)早退；Kevin好像有事所以也先走了；Nadim腿有上傷，比Kevin還早就走了。既然是程序出錯，我又是QA，所以我就和Kevin說我可以留下幫一下Said。我們花了兩小時，沒有任何進(jìn)展，又是圣誕，所以我們就回家了。事實上這個問題解決方法不難，我們使用了Win32 API的用戶權(quán)限函數(shù)，結(jié)果效果很不理想。后來我在一本叫“Write Secure Code”（我們第一個設(shè)計也是從這本書里抄出來的）找到一段用ATL設(shè)計的代碼，我在家里試了下，效果不錯，就推薦給了Said。后來Said又和Nadim成對進(jìn)行了設(shè)計，最終在第三個星期一完成了修改。這里學(xué)到的教訓(xùn)是，加班是么沒有用的。一周的工作已經(jīng)讓人十分疲倦，將員工的休息時間轉(zhuǎn)換成更多的工作時間完完全全是錯誤做法。疲倦的員工心里只有一件事，休息，放松，不想工作。強(qiáng)迫員工加班或是員工自愿加班的行為只能損傷員工的健康，同時很少的進(jìn)展能在這樣的狀態(tài)下完成，最后公司還要為這樣次等的工作付出加班費(fèi)，這就是一種浪費(fèi)。
和Brian比起來，和Said的合作還算正常。和他的互動我發(fā)現(xiàn)他對單元測試并不感冒，他寫的很多的單元測試都是部分的集成測試（Partial Integration Test）。Said是個C程序員，所以很多他寫的代碼都要看兩遍才能知道他在做什么，但是，這些代碼效率確實很好?？墒怯袝r我們發(fā)現(xiàn)什么錯誤，都要花不少時間來查找問題在什么地方。在這個項目之前，我用Visual Studio的Debugger用得很少，這次我可是實實在在地學(xué)了如何使用這個工具。Said最厲害的地方，可能我現(xiàn)在還沒有學(xué)會這個，就是如何在代碼里挖蟲。我們在第二個周期里設(shè)計了一個壓力測試程序，當(dāng)時Kevin叫我們設(shè)計這么一個程序，我就花了半小時用C#寫了這么一個程序。我們運(yùn)行了一下發(fā)現(xiàn)微軟給我們的TDI驅(qū)動里有嚴(yán)重的內(nèi)存泄漏。我找了幾小時找不出問題，Kevin 就叫我把這個問題轉(zhuǎn)讓給Said。Said在兩小時內(nèi)就發(fā)現(xiàn)了幾個文件柄沒有關(guān)閉的問題。后面兩個設(shè)計周期中，他不斷地在微軟給我們的代碼中發(fā)現(xiàn)這樣的問題。我從他那里學(xué)到了不少查找蟲子的方法，特別是使用像Sysinternal的一些第三方的工具來監(jiān)測內(nèi)存泄漏。當(dāng)然我也學(xué)了一些C編程有關(guān)的技巧。但是和他合作，速度是一個很大問題，有些問題只要45 秒鐘可以解決的，但是他要看4分鐘才能想到這個45秒鐘的問題，這樣反而減慢了整個開發(fā)的速度，這樣的開發(fā)反而有個好處，因為他在思考的時候方方面面都考慮到了，所以速度和周全相互抵消，最后的設(shè)計效果有時反而很好。有時這樣的過多思考反而效果不好。我記得在最后一個開發(fā)周期中，我們有個改進(jìn)要做，假設(shè)兩個用戶一個改變了程序設(shè)定，然后快速轉(zhuǎn)變用戶，換到另一個用戶，這時Systray中的ICON也要同時改變。我和Said嘗試了一個非常復(fù)雜的設(shè)計，當(dāng)然我的技術(shù)沒有那么厲害，所以Said提供了這個方案，在用戶一那里改變設(shè)定，然后用戶一更新Systray中的ICON。接著，程序在用戶一的桌面上向用戶二所在的桌面的同一程序送一個信息，讓這個程序更新Systray中的ICON。然后我們一起編寫了這個設(shè)計。當(dāng)然這么一個想當(dāng)然的方法沒有成功。我回頭一想，每個用戶在快速變換（Fast User Switch）時，程序能夠檢測用戶快速變換，所以在第二個用戶桌面轉(zhuǎn)成屏幕上的桌面時，只要重新將程序設(shè)置更新一下，第二個用戶的Systray中的ICON就更新了。這個第二種方案幾十行代碼就解決了，一點都不麻煩。我們犯的錯誤就是想過頭了，真正的Lean & Agile 就是要從最簡單的解決方法想起。
我和 Nadim 的合作產(chǎn)生的毛病最少，我和他的合作一般是早上我大約在9點多進(jìn)公司，第一件事我先是做些有關(guān)一天要做的任務(wù)的調(diào)查，然后等所有的人進(jìn)了公司后我才和他或Said進(jìn)行成對設(shè)計。這樣的效率也非常高，我早上查找的信息一般在90分鐘到內(nèi)變成可用的代碼。我和Nadim合作設(shè)計了好幾個用戶界面有關(guān)的部分，他是一個很優(yōu)秀的設(shè)計者，我的技術(shù)和他比起來就要差一些。所以我完全可以承認(rèn)我的技術(shù)功底不是很優(yōu)秀，后來微軟沒有招我做正式員工也是能理解的，我畢竟不是異常優(yōu)秀的程序設(shè)計人。但是如果微軟招我做了正式員工，那么我就不可能有機(jī)會和這些微軟以外的高手合作，不可能有機(jī)會在實踐中體驗Lean & Agile這么先進(jìn)的軟件工程管理理論，更無法想象一個工程小組能如此高效，如此精簡敏捷地進(jìn)行客戶能夠滿意的開發(fā)。Nadim讓我佩服的是他的理解能力，我記得那一段時間中最丟人的經(jīng)歷是花了一天時間沒搞出如何用WiX技術(shù)進(jìn)行安裝包的制作。Nadim的耐心讓他在一天中搞出一個很漂亮的安裝包，對這個壯舉我是十分佩服的。我還記得我們兩人搞了一下午的單元測試來摸索微軟給我們的一個特殊字符串處理類，叫MSN::CString，這個庫是專門用來處理URL字符串的。當(dāng)時我們的配合非常好，我和他輪流想出測試這個庫里的函數(shù)的測試單元用來試探這個庫的使用方法，以此，我們在毫無文檔解說的情況下摸索出了這個庫的使用方法。當(dāng)時MSN的開發(fā)人員問我們說，沒有文檔你們怎么知道如何使用這個庫的？我們的部門經(jīng)理很自豪地回答說全靠遵循我們開發(fā)管理系統(tǒng)中的一套制度摸索出來的。我和他還一起解決過一個有關(guān)CListView（MFC）處理大量物件（List View Item）速度太慢的問題。當(dāng)時CListView自己的加入物件并顯示的速度在處理10000個物件時要花幾秒鐘，我們用Google查找了90分鐘，找到了一套自己加載這些物件加入ListView的辦法把整個速度加快到處理100000個物件只需兩秒。一下把效率提高過來。這個改進(jìn)當(dāng)時又一次讓MSN對我們感到非常滿意，加上后來我們在他們的代碼中找到許多文件柄沒有關(guān)閉的問題之后，我們的高效和專業(yè)敬業(yè)完完全全取得了他們的信任。我覺得Nadim最讓我值得尊敬的素質(zhì)是他的領(lǐng)導(dǎo)能力。Kevin是個非常優(yōu)秀的領(lǐng)導(dǎo)，Nadim則是Kevin不在時的替補(bǔ)領(lǐng)導(dǎo)。因為他的技術(shù)基礎(chǔ)過硬，和許多的開發(fā)經(jīng)驗，所以贏得我們所有人的尊重，我們會尊重他的意見，我們在他的帶領(lǐng)下進(jìn)行開發(fā)。沒有他在后面用技術(shù)做領(lǐng)導(dǎo)，這個項目完成后的質(zhì)量不一定是那么好。我同時感覺他在整個過程中對Lean & Agile的領(lǐng)悟非常深，他和我一樣喜歡這套做事方式。
最后說說Kevin。他是一個很優(yōu)秀的領(lǐng)導(dǎo)，沒有他對Lean & Agile管理的深刻認(rèn)識，我們肯定不可能在兩個半月內(nèi)將這項目完成，但是他要是沒有我們這些人，也不可能把這個項目完成。他是一個非常勤奮的人，他的主要職責(zé)不是和我們一樣開發(fā)，他的職責(zé)是和用戶溝通，他把用戶所希望得到的最后期望轉(zhuǎn)化成一個個細(xì)節(jié)的“故事”然后吩咐給我們設(shè)計。我們把他作為我們的客戶，我們做完了一個局部設(shè)計先讓他看，他認(rèn)為滿意，我們就知道客戶對這樣的設(shè)計一定也會滿意。他要是不滿意，馬上會告訴我們應(yīng)該達(dá)到什么樣的效果?？蛻粢_(dá)到的效果，他能仔細(xì)地分析細(xì)化，然后和用戶溝通哪些是重要的，哪些是不重要的，排序以后，我們再簡單討論如何分配這些“故事”給每個人做。他耐心地和Brian還有Said解釋Lean & Agile的理念。特別是Brian，Brian的貢獻(xiàn)最少，但是他還是耐心地和Brian一起成對進(jìn)行設(shè)計。后面我實在沒有興趣和Brian成對進(jìn)行測試，因為Brian每次碰到機(jī)會就反對我的意見，每次他自己出現(xiàn)問題就是花費(fèi)數(shù)小時自己去閱讀，試圖理解這個問題的方方面面，完全不顧整個開發(fā)進(jìn)度，完全不顧其他人是否有這方面的專長能否幫他把眼下工程搞完。Kevin不懂C++，只懂C#，可他還是堅持和Brian成對編程。他不是想學(xué)技術(shù)，他是盡自己最大努力監(jiān)督Brian把Brian 自己該做的任務(wù)做完?？梢钥闯鯯aid是沒有時間Brian糾纏，Nadim似乎也沒有興趣和Brian糾纏，我就完全承認(rèn)，我是沒有好脾氣和Brian扯皮。但是作為一個設(shè)計組的領(lǐng)袖，Kevin不得不做壞人，用威信逼迫Brian做到他想要的結(jié)果，當(dāng)然這樣最終還是逼著Brian做完了該做的事。而且在同時，我們在沒有Brian搗亂的狀態(tài)下做完了我們該做的事。Kevin的表現(xiàn)100%完美地展示了Lean & Agile的管理和開發(fā)過程，他是個非常優(yōu)秀的Scrum Master。由他的帶領(lǐng)下，我們做正事的，遵守了所有Lean & Agile要求，他靈活地運(yùn)用了Lean & Agile的管理模式，而不是死板地遵照書本上寫的教條，所以我們在最短時間內(nèi)做了三倍同樣時間能做的事。我們每個人都接觸了一些我們平時沒有搞過的事，我搞了不少Build有關(guān)的工作。就是微軟內(nèi)部用來建造的系統(tǒng)，就是Win DDK加上Platform SDK。我花了60%的時間在開發(fā)上，但也有40%的時間搞我該搞的QA工作?？偟脕碚f我在這個項目了做了異常多的工作，這是我覺得我應(yīng)該在這么短時間內(nèi)做完這么多的工作量。Nadim完成的工作量比我多，他也和我一樣穿梭在各種各樣的任務(wù)中。Said和Brian各自也最大化地盡了他們的努力。Brian在最后一個周期，特別是臨近交貨的一天中花了9小時測試了整個用戶界面的功能，查找出不少值得改進(jìn)的地方，我這時才發(fā)現(xiàn)他并沒有我想象地那么沒用。Said就不用說了，他在關(guān)鍵的時刻就能為我和Nadim提供一些非常有價值的反饋。Said的代碼修改實在讓人敬佩，他寫的東西就是很靈巧（這個詞大概我五年沒用了）。Kevin在調(diào)度員工讓每個人在必要時發(fā)揮自己的能力做得實在讓我佩服，這也說明他運(yùn)用Lean & Agile十分嫻熟。當(dāng)然和他合作，我也有感到不耐煩的時候，我向他解釋一些比較技術(shù)的問題，我要解釋三遍才能解釋清楚。他經(jīng)常在我正做得興起的時候把我打斷，然后進(jìn)行15分鐘的Scrum會議，這時我在一開始就會覺得有點煩躁。同樣的問題，有時他會在我做事的時候把我打斷，叫我更新用來記錄工程進(jìn)度的Wiki主頁。但是這些小小的愉快根本算不上什么。在這樣的設(shè)計組里工作，合作的愉快遠(yuǎn)遠(yuǎn)大過一些小小的不舒服。
最后總結(jié)一下我對這個工程的感想。這個工程是我覺得自己所參加過最好的一個項目。我們100% 地執(zhí)行了Lean & Agile工程管理模式，我們在規(guī)定的時間內(nèi)為客戶完成了客戶所期待的產(chǎn)品。我們沒有完成所有客戶所希望的產(chǎn)品功能，我們完成了所有客戶認(rèn)為最重要的產(chǎn)品功能，客戶對我們的評價是“You guys are the superstars!”但是等我們做完后，他們沒有其他項目給我們做，允許為我們在其他項目的投標(biāo)中為我們提供好的評價。我們交出工程后，15天內(nèi)，客戶從來沒有和我們聯(lián)系讓我們進(jìn)行維護(hù)，說明我們的工程質(zhì)量完全合格。我們在整個項目中，除了最后一個開發(fā)周期，基本上都沒有加班過。最后一個開發(fā)周期中，我們七天不停地工作，我那一段時間加班賺了不少錢，但是馬上又病了一段時間。說說我對這套工程管理模式感到不滿意的地方，就像我說的，任何工程管理模式都有一些不足的地方。首先是大家工作的時間表，除我以外，大家都在早上10點半甚至是11點才到辦公地點，然后自愿做到晚上8，9點才回家，我挺不喜歡這種工作方式。我在這個工程過程中發(fā)現(xiàn)，能夠保證工程順利進(jìn)行的主要還是人的因素，一個開發(fā)組要有能夠接受這樣的開發(fā)風(fēng)格的人相互協(xié)作，心無二念，能夠服從領(lǐng)導(dǎo)的指揮。一個開發(fā)組必須擁有一個很有能力的Scrum Master，必須能夠準(zhǔn)確地和客戶溝通產(chǎn)品的功能，能夠記錄客戶提出的每一個要求，再和開發(fā)組進(jìn)行溝通，Scrum Master還要有很好的管理能力。每個組員的能力也是一個很重要的因素，沒有能力強(qiáng)，能夠合作的組員，一個工程也很難繼續(xù)。在這個工程開發(fā)中，一個技術(shù)能力很強(qiáng)但是合作能力很差的人，給整個小組的貢獻(xiàn)其實很少，為了保持進(jìn)度，我們其他組員都要承擔(dān)這個人的任務(wù)，這樣讓我們所有人都覺得累。其他問題還包括，我們并沒有完全遵守Lean & Agile的規(guī)則，我們對設(shè)計的細(xì)化做得不夠，我們的單元測試，集成測試做得也不夠，最后我們交給客戶的產(chǎn)品我是滿意的，我覺得它可以被設(shè)計得更好，可惜我們沒有更多的時間來完善。我對這個工程的最后結(jié)果是很滿意的，我的經(jīng)歷告訴我，這樣的工程管理是非常有效的，前提是，這么一個開發(fā)小組需要的高效，技術(shù)好，能合作，能把事情做完的人，需要一個能力高超的管理人員，需要所有的人員都能按照Lean & Agile的規(guī)則做事。一個開發(fā)小組缺少這些因素中任意一個，開發(fā)就不一定能成功。
