【文章內容簡介】 的實際工作時間，并和你的估算作比較，你將永遠不能提高你的估算能力。你的估算將永遠是猜測。 19. 只有當任務 100%完成時，才認為該任務完成 使用英寸大小的小圓石的一個好處是，你可以區(qū)分每個小任務要么完成了，要么沒有完成，這比估計一個大任務在某個時候完成了多少百分比要實在的多。不要讓人們只入不舍他們任務的完成狀態(tài)；使用明確的標準來判斷一個步驟是否真正的完成了。 20. 公開、公正地跟蹤項目狀態(tài) 創(chuàng)建一個良好的風氣，讓項目成員對準確地報告項目的狀態(tài)感到安全。努力讓項目在準確的、基于數(shù)據(jù)的事實基礎上運行，而不是從因為害怕報告壞消息而產生的令人誤解的樂觀主義。使用項目狀態(tài)信息在必 要的時候進行糾正操作，并且在條件允許時進行表揚。 這些提示不能保證你的成功，但是它們將幫助你在你的項目上獲得一個堅實的把手，并且保證你做了所有你可以做的事來讓項目在這個瘋狂的世界上成功。 技術管理就像開車。當你做得正確時，沒有人注意，一旦某個環(huán)節(jié)出錯，問題會接踵而來。以下是我 11 年來作為 Interviewing Manager 的 Team 管理體會，排名不分先后，你必須注意每一點。 1. 不要重復過去二三十年來別人犯過的錯誤 這句話來自 Steve Mcconnell， IEEE 軟件編輯和軟件開發(fā) 暢銷書作家。 Mcconnell的作品包括經(jīng)典著作“ Code Complete”。 Mcconnell認為，“大量閱讀”是避免凡重復錯誤的最好方法。 2. 80%的管理就是選擇正確的人選 Scott Adams, Dilbert 漫畫的作者認為一個好的項目經(jīng)理必須創(chuàng)造一個人盡其用的環(huán)境。所有的項目經(jīng)理都應該讀一讀 Tom Demarco 和 Tim Lister 的新書“ Peopleware： Productive Projects and Teams”（ 2nd Edition, Dorset House, 1999）。 3. 總是試圖雇用比你強的人 不要讓你的自負成為項目的瓶頸。組織一支聰明的隊伍，給他們足夠的資源和解決問題的規(guī)則，讓員工自己解決問題。 4. 不要浪費時間 Tom Bragg， Intellisys Technology ，認為太多的項目由于不能如期開始最后陷入麻煩。通常導致延遲的原因包括其它任務的干擾，人事變動，不準時的經(jīng)理等等。 5. 最優(yōu)的未必是最大的 Tom Bragg的另一個建議是：密切注意項目開始后發(fā)生的事情。 Bragg說：“計劃好你的工作然后如期進 行，過分緊張的工作強度反而往往導致生產率的降低，可能保持每周 50 小時以內的工作強度是最佳的。 6. 真實的，公正的估計 項目經(jīng)理應該避免“依照管理者的欲望修改計劃”的陷阱?！耙粋€有效的估計的特征是所估計的時間與金錢比實際情況低和高的概率相等”， Bragg說。 7. 使你的組織結構更有效率 很多情況下，你可以采用另外一種與現(xiàn)在不同的組織結構。看一看 Apache Web server 的開發(fā)小組，他們的層次組織并不分明，卻開發(fā)出了成功的產品。 8. 使用 WWW 上的免費工具 從 Barry Boehm的學生開發(fā)的，能夠把 W理論（ WinWin 模型）和螺旋形模型結合起來的工具。在項目管理研究所的網(wǎng)址 ，你可以下載它的聯(lián)機手冊 ...套工具： Control Panel和 Risk Radar。 Control Panel是 Excel表格形式，由于監(jiān)測生產率和質量； Risk Radar 是一個 Access 數(shù)據(jù)庫，對項目的風險進行量化管理。 9. 不要小看老程序員 重新訓練現(xiàn)有的程序員比雇用新畢業(yè)的大學生要有 價值。老的程序員在以往的多個項目上有豐富的經(jīng)驗，通過新技能的訓練后，他們的經(jīng)驗和知識會幫助年輕的程序員（包括項目經(jīng)理）節(jié)約時間和金錢。 10. 為你的項目選擇定正確的工作流程 并不是所有的項目都適用一種開發(fā)流程。 Intel 公司有規(guī)律地檢查每個開發(fā)小組的工作質量，如果出現(xiàn)了延遲交付或質量問題， Intel鼓勵該小組改進他們的工作流程。 11. 做好你的生存計劃 對開發(fā)過程共享實施猛烈的變革和改變是個什么樣子？除了可能的時間大量損失（好，其實這是很小的 可能，除了正在改變開發(fā)過程時），當它們獲 得了人們支持時就都會成功。 在歷史上，人民，社會的勞動者，通過聯(lián)合推動了社會變革。這就是我們所滿意的應用程序，MeshTV，用二維和三維的有限元網(wǎng)格以圖形的方式可視化和分析數(shù)據(jù)。它也能處理多種不同的網(wǎng)格類型，提供各種方式查看數(shù)據(jù)并去除了大多數(shù)的硬件和廠商的依賴，同時以自身圖形硬件的速度顯示圖形。 MeshTV也可以并行工作，你可以想象得到這需要一些組織級別滿足程序的復雜性，保持有序。最后說一點， MeshTV大約有 450,000 行源代碼。 這是我所作的全部描述。如果你想了解得更多，查看 ，你可以下 ?..⒃創(chuàng) ?/a 受約束的混亂 象許多為內部使用而開發(fā)的程序一樣，在加利福尼亞 Livemore 的勞倫斯 Livemore國家實驗室，對程序必需的修改和增加超出了可用的資源。在 MeshTV項目中，這導致了混亂，（ on the MeshTV project, this led to controlled chaos, where developers implemented new features based on the crisis du jour.）（譯者注：這句話不好譯）沒有人有時間坐下來畫出應用流程。我們都在實驗室的里里外外，忙于我們客戶的貪婪的需求。（有約 150個文檔用戶 可能更多，實際上要靠 5個兼職的開發(fā)人員支持）在我們這種狀況下，這種過程導致了我們用戶更多的抱怨和可靠性匱乏的程序。 三年前，我們的職責很小（幾個用戶，幾個開發(fā)人員，很少有廣泛的應用功能）允許我們在CVS 上用非常不正規(guī)的過程管理源代碼。當用戶數(shù)和他們需求差異增多時，相應的代碼管理的復雜性也增加了。處理我們增長的工作量也變得更加困難，我們知道有些事情必須要改變了。我們 決定加入到我們部門的其他開發(fā)小組中去，并使用 Rational軟件公司的版本控制系統(tǒng) — ClearCase。從此，我們過程的改進氛圍（ our process improvement culture）開始改變，變革的種子已經(jīng)播下了 在我們轉向 ClearCase 前，我們小組的一位經(jīng)理曾經(jīng)誘導我們更多的集中在過程上，她徒勞了。她看到了增長的壓力和用戶的不滿，她想我們應該嘗試用不同的方法提高我們程序的可靠性和在用戶那里的名聲。不幸的是，她的話從來沒有引起重視，同樣我們也認識到了這點，但我們不得不忙于作完我們的工作。 開發(fā)人員認為最好的情況是軟件工程學所論述的那樣，而在最糟和最可能的情況下，會占用大量的時間，提供眾多的文檔，用處不是很大。我們的一些老開發(fā)人員認為改進我們的過程沒有用并且??（ Some of our veteran developers saw no use for improving our process and would have sooner appeared in public in a tutu rather than utter such a sissy phrase.）（譯者注：這句話 太難譯了，單詞也不認識）而且俱樂部所有人，包括我也懷疑我們要收獲的巨大好處。我認為 CVS 工作得很好，我們真的不需要更多先進的東西。 在 CVS 工作的同時， ClearCase 工作得更好。我認為在每個軟件工程生產力上沒有真正的提高，但是可以用我以前不能采用的工作方式工作。這些新的工作方法可以使管理源代碼變得更容易，同時也減少了我曾經(jīng)在 CVS 中遇到的問題。例如，我現(xiàn)在可以輕松的多并發(fā)地開發(fā)，我可以在我完成后可靠的歸并我所作的。新特性彌補了我花在開發(fā)和學習新過程上的時間。 真正的產出 過渡不久，一位 同事和我與一位來自蘋果計算機公司的開發(fā)同行進行了一次有趣的討論。他的工作需要產品開發(fā)過程的急迫應用，包括構建方法學和發(fā)行版本管理過程。當我們敘述我們通常隨意無計劃的方式時，他幾乎震驚暈倒。后來的討論，使我們驚奇的了解到了通過改進我們的過程所獲得的好處。有一位經(jīng)理鼓勵我們是一方面，但是非同尋常的另一面是聽到一位開發(fā)同行稱贊他發(fā)現(xiàn)的好處。這是真正的產出，計算機科學風格的。 我們對其思考的越多，我們越認識到我們需要行動。將新特性和缺少固定發(fā)行日期聯(lián)系起來的狂熱，導致了在發(fā)行新版本和功能性的匱乏測試間長久的延期 。我們的意圖是好的，我們想讓我們的客戶滿意。然而，不知何故，我們的期望事實上很糟糕，似乎看起來我們工作得很辛苦，但是，我們聽到了更多的抱怨。我們需要改變現(xiàn)狀。 首先，我們轉換到有目的的發(fā)行版本日期，使其包含明確的更改和新的功能。像許多的內部產品， MeshTV有著明顯的直接的用戶（ MeshTV had users who lived right down the street.）。新特性的不同的聲音淹沒在所有的目標回應中，我們嘗試經(jīng)常性的從那些所有從會議廳走下來，停下來聊會兒天的用戶那里獲取要求。（這 些打斷也可以避免我們持續(xù)工作）荒謬的是在試圖獲取所有要求中，我們不能滿足他們中的大多數(shù)，我們失望了。所以我們從這種方法上退回來。或者試圖將所有要求放進去（可能匆忙地完成，沒有更多明顯的 bugs） ,或者針對最后的抱怨作一個改正（從而沒有舊的要求）。我們需要一個載明新發(fā)行版本應體現(xiàn)哪些要求的計劃。 這表明另一個過程需要改進。在決定之前，我們通過將 bugs 報告和要改變的要求寫到紙上，保證可追蹤。這片紙經(jīng)常“走向了所有事物的歸途”，或者偶然的扔進了廢紙簍，或者壓在了其他所有的紙張下面。（這點上我堅信我已危險地靠 近制造我自己桌面中子星）（譯者注：黑洞乎）那些紙隨著時間的流逝而不能理解，無心的造成了客戶輸入損失的結果。 我們需要很好的保持我們改變要求的追蹤，這樣我們就可以為下一個發(fā)行版本選擇明確的要求。在對幾個產品調研后，我們購買了 Pure Atria 的 ClearDDTS，幫助我們管理我們的改變要求，我們試圖一年四次發(fā)布新版本應用程序，這作為一策略被我們采納，這樣我們就可以很快的清晰地增加新功能，不用更新得過于頻繁導致沒有時間測試我們的修改。為了達到結束點，我們努力選擇一定量的能夠在三個月內完成的工作。第一次時， 因為我們沒有人知道如何預測一個詳細的修改需要多長時間，我們徹底失敗了。幸運的是，我們可以通過ClearDDTS跟蹤我們曾經(jīng)預測的時間和工作中實際花費的時間，并且個別開發(fā)人員利用這些數(shù)據(jù)預測將來。在為其他版本的選擇工作中，這獲得了重大的成功。變革明顯的站住了腳。 我們也決定與目標發(fā)行版本并進，著手提高質量的工作。為了完成這點，我們要求所有決意要改變的要求要被不具有開發(fā)責任的其他人所驗證。當我們知道其他人會檢查工作時，我們就都會非常仔細，這多么驚奇。我們也開始采用 Mercury Interactive’ s Xrunner 和內部使用的腳本開發(fā)了一個自動測試系統(tǒng)。將來，在我們發(fā)布一個新版本應用程序前，這些測試必須成功的測試過。 持續(xù)的改進 所有這些工作都以我們不能想象的方式的到回報了。我們更好地跟蹤我們的改變要求，也就是我們沒有丟掉它們，我們確實能跟得上用戶的更新狀態(tài)了。用戶喜歡這點，我們也不再面對來自客戶的挫折。他們也喜歡我們更頻繁的更新和更加健壯的程序。 我們正在尋找另外的方式，我們可以從改變我們過程中獲得好處的方式?，F(xiàn)在，我們正在研究軟件開發(fā)成熟度模型（ CMM） ,看是否能通過遵從 2級幫助我 們提供更好的應用軟件（請到 CM...在于核對 boxes。 我們正在進行的另一個改變是，我們能夠更容易地在我們每年四個主版本之間發(fā)布修訂 bugs的版本。這點可以是我們更快的轉向用戶的要求，平息用戶的憤怒。（我們基于用戶認識到的嚴重性和我們察覺的嚴重性的比較，選擇哪些 bugs 被改正，還包括工作區(qū)存在的風格。我們在整體上也為客戶整合了全部優(yōu)先級的感覺） 我們過程改革的更多驚人結果之一是不只影響了程序，更多地影響了程序開發(fā)人員。他們停止了改善用戶的態(tài)度 ，轉向提高應用程序。程序變得更可靠，發(fā)行版本變得更可預測的同時，用戶對應用軟件整體上也更加滿意。 但是我們不僅只關心我們的過程的改革。 MeshTV 的開發(fā)人員同其他的開發(fā)小組并同工作著，我們試著同其他的小組分享我們的經(jīng)驗，學習我們的勝利和錯誤。圍繞我們新的過程，我們提供了四個展示，至少有一個小組已經(jīng)決定采用我們的一些經(jīng)驗。變革在成長。 成功孕育成功 當管理層嘗試推動改變過程時，從最初的懷疑和憤怒，我們在這個過程中經(jīng)歷了巨大的變革。這些曾經(jīng)著名的過程都是那些所有刊物都討論過，當作福音傳授給我們 的同事。當我回頭看看我們的小組，我驚奇于我們從使用一個版本控制系統(tǒng)改變到幾個可重用性、文檔化過程，甚至將那些經(jīng)驗出售給別人。什么能夠允許我們背離我們正規(guī)的商業(yè)方式 對于我們來說