第二部分有效開發

第15章生產率工具

生產率工具對于開發者而言，誘惑力是相當大的，它也確實在快速軟件開發當中扮演了重要角色。采用新工具可以成為提供效率最有效的手段之一，但同時也是最具風險的方法之一。

關于生產率工具，有三個關鍵事實：

l 生產率工具很少達到它的賣家宣稱的效果。

l 學習任何一種生產率工具，在開始時都是以降低生產率為代價的。

l 之前表現不怎么樣的工具，有時候也能極大的節約時間。不過第一條仍然成立。

1.快速開發中生產率工具的作用

沒有銀彈，軟件開發中的次要復雜度和必要復雜度。

次要復雜度，是指在軟件活動中，由人引起的問題。比如需求采集中的問題，語言和框架選擇的問題，編程語言本身的問題等。這些問題是可以解決的。必須一些項目管理方法論，比如高級編程語言的出現等。

必要復雜度，是指軟件本身要解決的問題而衍生出來的。比如軟件包含三十個必要的功能，這三十個功能就是必要復雜度。

軟件功能面臨的問題，在于我們能夠清除大部分次要復雜度，而剩下的必要復雜度無法改變。

良好的組織與管理，比起技術來，似乎是更加關鍵的因素。

2.生產率工具的戰略

與常理相悖的是，工具的采用是一個長期的戰略問題，而不是一次性的選擇。生產率工具的戰略包含以下一些基本因素：

l盡早識別有希望的新工具。

l及時與準確的評價新工具。

l快速部署被證明有效的新工具。

l避免使用被證明低效的新工具。

l繼續使用久經考驗的舊工具。

3.生產率工具的獲取

以隨機的方式獲取軟件工具的組織，大致將使投資被浪費一半。獲取工具時常常碰到的問題如下：

l軟件工具市場總是言過其實。

l獲取到不好的工具后，往往會阻礙更多有效工具的獲取。

l一些工具獲取后，被放棄了。

l一些工具由于缺少培訓，而沒有得到充分利用。

l一些工具與現有的工具嚴重不兼容。

1.獲取計劃

等到需要的時候，才開始調研的組織，其等待時間太長了。對新工具的調研，評價與交付應該是一項常抓不懈的事情。

1.工具組

一個有效的方式就是指定一個人或一個工作組來負責軟件工具信息的發布。他們的職責范圍包括：

信息收集。

評價。

協調。一個公司的不同項目組可以試用不同的新工具，但如果不加協調的話，不同的組很可能就會試用同一個新工具。對于組織而言，這是非常低效的做法。

傳播。

2.建立工具組的風險

建立一個集中的工具組會產生一些風險，其中最壞的就是工具組控制過多。工具組應當只是收集發布有效的工具信息，然而在面對快速開發項目時，工具組需要警惕僵化成一個官僚化的標準組織。

建立工具組的初衷是服務機構，而不是標準組織。處于項目一線的人才清楚什么是他們最想要的。工具組可以推薦工具，給出意見，提供幫助，但他們絕不能替項目組做出決定。

另外，工具組的成員，他們說話必須非常有分量。如果工具組都是不被重視的人，那么他們的建議也得不到重視。

2.選擇標準

預計收益。對于快速開發項目，預計收益的度量是苦難的，而且必須是保守的。

供貨商穩定性。

質量。

成熟度。

培訓時間。

適用性。

兼容性。

發展規劃。

定制選擇標準。

3.承諾

一旦工具選定之后，你就需要堅持使用。不要東張西望。因為你每一個項目，每一個工具都會遇到一次大障礙。當你碰到障礙時，你必須意識到，在項目進行中更換工具，將預示著很有可能你將再次碰到大障礙。

4.生產率工具的使用

如何實現生產率工具與項目間的結合，對提高快速開發能力同樣有著重大的影響。

1.何時使用

軟件項目通常存在著熟悉新工具的學習曲線，和因新工具而帶來生產率收益之間的平衡。

從單一項目的角度去看，如同上圖所示，如果你計劃在項目A的時間長度內完成項目，就最好不要使用新工具。如果你計劃在項目B的時間長度內完成項目，就可以嘗試新工具了。

從組織的角度去看，考慮的問題就有所不同了。如果你擁有較多的類似項目A的短期項目，你在每一個項目中都不必引入新工具，但是為了組織的長期發展，你有時就不得不引入新工具了，盡管這個工具對某一單個項目并非最合適，但這個新工具是對組織來說，是存在長期生產率的提高的。

因此，你可以為快速開發得出兩條結論了：

l從長期考慮，你必須經常性的引入能提高生產率的工具。這種引入并不能單純的從某一個項目的基礎來看待。

l從短期考慮，快速開發項目并不適合引入新工具。所以你要盡量在對時間要求不太高的項目中引入新工具，以吸納新工具的學習曲線。

2.培訓的重要性

3.進度縮減的期望值

軟件項目通常存在著熟悉新工具的學習曲線，和因新工具而帶來生產率

5.銀彈綜合癥

第16章項目修復

往往有些項目在進行了很久之后，才發現需要快速開發，而且通常都是在延誤了里程碑之后。這些項目通常有以下一些特征：

l沒人對項目何時結束有概念。

l產品滿目瘡痍。

l開發組人員工作超時，加班嚴重。

l管理層已經無法控制進度。

l客戶對開發組不再抱有信心。

l開發人員，質量保證，市場人員，客戶與管理層之間的關系非常緊張。

l開發組士氣低落。

對于一個如此千瘡百孔的項目，小修小補已經無濟于事了，強有力的措施必不可少。本章中將對這些措施進行討論。

1.一般修復方案

對于想挽救項目的人來說，一般有三個基本方式可以選擇：

l縮減項目規模。

l把注意力放在短期改善上，以提高生產率。

l面對軟件不可能按時完成的現實，放棄原計劃，著手準備危害控制。

通過將三個方式結合，我們得到了第四種方式：

l扔掉一些功能，盡量提高生產率，拋棄原計劃。

本章將主要討論第四種方案。

1.修復理念

在項目修復模式中，注意力很容易可能放在錯誤的問題之上，比如一些具體項目的具體問題，而忽略了本質問題。

項目陷入困難的首要原因就是控制不力。而想要收回一度放棄的控制權是很困難的。

2.修復計劃

本章中討論的計劃，是專門為那些深陷泥潭中的項目準備的。假如你的項目還不至于那么慘，你也就可以用一個不那么徹底的方法。

本章中討論的計劃，與支撐起項目快速開發的四維相當一致：避免典型錯誤，采用最基本的開發實踐，風險管理，尋求面向進度的實踐方式。

第一步，準備工作。

l評估你的處境。

確定截至日期到底有多關鍵，找出到底什么才能滿足它。你或許會發現真正的硬性期限根本不存在。

l應用W理論分析。

為了獲取成功，你的開發組需要什么，客戶需要什么，為了維護良好的客戶關系需要什么。過去的已經過去了，你要著眼于現在，如果無法找到每個人根據自己的價值標準，都能覺得成功的方式的話，就干脆結束這個項目。

l自己做好修復項目的準備。

你需要讓開發組和管理層都知道，項目如果按照以前的做法，顯然是于事無補的。想挽救項目就必須有大舉措。如果人們不愿意采取重大舉動，就表明你已經輸了，不如結束項目。

l問問你的開發組需要什么。

向你的開發組每一個成員詢問至少五種拯救項目的觀點。然后對這些觀點進行討論。

l變得現實一些。

如果你處于項目修復模式，你的開發組極為需要的是清醒的，現實的項目領導。在你沒有一個很好的理由來確認一個日期之前，千萬不要承諾。

第二步，人員。

人員是快速開發中最重要的杠桿支點。在進入過程和產品這兩個維度之前，一定要把人員基礎打的牢固一些。

l采取一切措施恢復開發組的士氣。

士氣對于開發有著至關重要的作用，而在項目修復期間，恢復士氣才是正確的問題。

恢復士氣最佳的辦法之一，就是采取一個象征性的行動，來表明你把開發人員放在了首位。要實現此目的，最好就是犧牲一個組織上神圣不可侵犯的事物或觀點，想公司表明公司是位于員工之后的。

l確保你已經為開發組創造了保健類因素。

比如去掉過多的進度壓力，改善惡劣環境，剔除管理上的行政臃腫，或其他不利因素。

l消除重大人員問題。

開發組對領導最常見的抱怨就是，他們很少過問組織內有問題的員工帶來的麻煩。如果你覺得你的組里有這樣的人，你就要勇敢的面對并且處理好。

l消除重大領導問題。

一個將項目帶到災難邊緣的領導人，不可能做出任何重大舉措，將項目引向成功。當你發現項目領導人有問題時，撤換是一個方式，但并不是唯一的方式，你可以嘗試一下方案：

改變領導的領導。

把領導的角色改成參與型。

為領導配備一名助理。根據情況，讓助理來處理具體業務，領導只需要關注全局問題。

l增加新手一定要謹慎。

牢記brooks法則，向一個已經延誤的項目中增加新手，無異于火上澆油。不要盲目的增加人手。

其實這個問題，關鍵點在于項目剩余的任務，還能不能繼續分解。如果能分解到新人的加入不影響其他人，你就可以放心的加人。

l充分利用開發人員的時間。

有很多方式可以集中開發人員的力量：給他們單獨的辦公室，確保他們不被行政事務打擾，

l允許開發組成員有所不同。

總有人會起來應對項目修復的挑戰而成為英雄，也總有人覺得英雄太累而不愿意全身心投入，那都沒有關系。在項目后期，你應該容忍那些安靜而穩定的員工，他們不可能達到英雄的高度，但他們知道自己的角色。但是不能容忍那些斥責想成為英雄的人，他們對于士氣的破壞力是巨大的，而項目修復時期的士氣是寶貴的。

l觀察開發人員的節奏。

第三步，過程。

識別，并改正典型錯誤。以下是一些需要問的最重要的問題：

產品定義是否改變？

項目是否存在設計不足而導致的隱患？

目前是否有準確最終項目狀態的管理控制？

是否有為了進度而犧牲質量的行為？

截至時間是否現實？

人們工作是否努力？

是否有采用了全新的技術而浪費的時間？

是否存在有問題的員工，拖累了開發組和其他人？

l修正明顯支離破碎的開發過程。

l創建詳細的小型里程碑。

在項目修復期中，絕對有必要建立一個追蹤機制，以便你準確地知道項目進展情況。

里程碑必須具有小型性，二元性和徹底性。小型性是指里程碑可以在一兩天之內完成。二元性是指里程碑要么完成，要么未完成，不存在中間情況。徹底性是指你完成最后一個里程碑時，項目也就完成了。

l根據里程碑的完成來安排進度。

為每一個里程碑設置完成日期，千萬不要打加班的主意。最好這樣安排進度：開發人員如果在一個小型里程碑上落后了，那么他們最多當天加一下班就可以完成。這樣就能保證項目按照計劃逐日進展。

l細致地追蹤進度進展情況。

如果設置了里程碑而不跟蹤的話，相當于沒有。絕對要保證開發人員在小型里程碑上的二元性，只有完成和未完成，99%也不叫做完成。絕不能讓開發人員在小型里程碑上偏離正軌。

l記錄里程碑未完成的原因。

記錄每一個里程碑未完成的理由，這樣就能從中間發現一些潛在問題。

l短期之后再調整，1周或2周。

如果開發人員總是比里程碑慢半天的話，1周或2周之后就可以開始調整了。如果開發人員需要7天來完成4天的工作，就把以后的工作量乘以7/4。不要幻想在以后把時間補回來。

l在得出一個有意義的進度前，不要固守一個進度。

不要把新的進度給到領導，因為你需要時間才能掌握和校正進度，這個進度需要計劃，校正，再修改，再校正的過程。

l不辭辛勞的進行風險管理。

要根據第五章的風險管理來集中進行風險管理。創建出十大風險清單，并堅持持續監控。

第四步，產品。

l穩定需求。

如果在整個產品生命期中需求一直不停變化的話，你就沒有必要再去找其他原因了。項目順利結束，必須先把需求穩定好。

l修正特性集。

要毫不猶豫的刪掉優先級低的功能和特性。

l評估你的政治地位。

如果你更多地陷入了政治漩渦而不是產品開發，本章中討論的修復計劃的作用就極為有限了。

l去除沒有用的垃圾。

找出產品中每個人都知道的，質量極其低劣的部分，仍掉它們。

l降低缺陷數目，并持續降低。

當我們遇上進度麻煩的項目，通常對進度和范圍非常感興趣，而自然就忽略了質量。

l達到一個可知的，良好的狀態，并在此基礎上繼續。