幾個軟件研發團隊管理的小問題

最近在與一位總經理交流的時候，他談到他們公司的軟件研發管理，說：「咱們公司最大的問題是項目不能按時完成，總要一拖再拖。」他問我有什麼辦法能改變這個境況。從這樣一個問題開始，在隨後的交談中，又引出他一連串在軟件研發管理中的遇到的問題，包括：

 

. 現有代碼質量不高，新來的開發人員接手時寧願重寫，也不肯意看別人留下的「爛」代碼，怎麼辦？

. 重構會形成回退，怎樣避免？

. 有些開發人員水平相對不高，如何保證他們的代碼質量？

. 軟件研發到底需不須要文檔？

. 要求提交代碼前作Code Review，而開發人員不作，或敷衍了事，怎麼辦？

. 當有開發人員在開發過程當中遇到難題，工做沒法繼續，於是拖延進度，怎麼解決？

. 如何提升開發人員的主觀能動性？

 

其實，每一個軟件研發團隊的管理者都面臨着或曾經面臨過這些問題，也都有着本身的管理「套路」來應對這些問題。我把個人「套路」再此絮叨絮叨。

 

1. 項目不能按時完成，總要一拖再拖，怎麼改變？

 

找解決辦法前，固然要先知道問題爲何會出現。這位總經理說：「總會不斷地有需求要改變和新需求提出來，使原來的開發計劃不得不延長。」原來如此。知道根源，固然解決辦法也就有了，那就是「敏捷」。敏捷開發因其迭代（Iterative）和增量（Incremental）的思想與實踐，正好適合「需求常常變化和增長」的項目和產品。在我講述了敏捷的一些概念，特別是Scrum的框架後，總經理也表示了對「敏捷」的認同。

 

其實仔細想一想，這裏面還有一個很是廣泛的問題。對於產品的交付時間或項目的完成時間，每每由高級管理層根據市場狀況決策和肯定。在不少軟件企業中，這些決策者在決策時每每忽略了一個重要的參數，那就是團隊的生產率（Velocity）。生產率須要量化，而不是「拍腦門子」感受出來的。敏捷開發中有關於如何估算生產率的方法。因此使用敏捷，在估算產品交付時間或項目完成時間時，是相對較準確的。Scrum創始人之一的Jeff Sutherland說，他在一個風險投資團隊作敏捷教練時，團隊中的資深合夥人會向全部的待投資企業問同一個問題：「大家是否清楚團隊的生產率？」而這些企業都很難作出明確的答覆。軟件企業要想給產品定一個較實際的交付日期，就首先要弄清楚本身的軟件生產率。

 

2. 現有代碼質量不高，新來的開發人員接手時寧願重寫，也不肯意看別人留下的「爛」代碼，怎麼辦？

 

這多是不少軟件開發工程師都有過的體驗，在接手別人的代碼時，看不懂、沒法加新功能，讀代碼讀的頭疼。這說明什麼？排除接手人我的水平的因素，這說明舊代碼可讀性、可擴展性比較差。怎麼辦？這時，也許重構是一種一箭雙鵰的辦法。接手人重構代碼，既能改善舊代碼的可讀性和可擴展性，又不至於因重寫代碼帶來的時間上的風險。

 

從接手人心理的角度看，重構還有一個好的反作用，就是代碼重構以後，接手人以爲那些原來的「爛」代碼被修改爲爲本身引以自豪的新成就。《Scrum敏捷軟件開發》的做者Mike Cohn寫到過：「個人女兒們畫了一幅特別使人讚歎的傑做後，她們會將它從學校帶回家，並想把它展現在一個明顯的位置，也就是冰箱上面。有一天，在工做中，我用C++代碼實現了某個特別有用的策略模式的程序。由於我認定冰箱門適合展現咱們引覺得豪的任何東西，因此我就將它放上去了。若是咱們一直對本身工做的質量特別自豪，能夠驕傲地將它和孩子的藝術品同樣展現在冰箱上，那不是很好嗎？」因此這個積極的促進做用，將使得接手人感受修改的代碼是本身的了，並且指望可以找到更多的能夠重構的東西。

 

3. 重構會形成回退，怎樣避免？

 

重構確實很容易形成回退（Regression）。這時，重構會起到與其初衷相反的做用。因此咱們應該儘量多地增長單元測試。有些老產品，舊代碼，可能沒有或者沒有那麼多的單元測試。但咱們至少要在重構前，增長對要重構部分代碼的單元測試。基於重構目的的單元測試，應該遵循如下的原則（見《重構》第4章：構築測試體系）：

- 編寫未臻完善的測試並實際運行，好過對完美測試的無盡等待。測試應該是一種風險驅動行爲，因此不要去測試那些僅僅讀寫一個值域的訪問函數，應爲它們太簡單了，不大可能出錯。

- 考慮可能出錯的邊界條件，把測試火力集中在哪兒。扮演「程序公敵」，縱容你心智中比較促狹的那一部分，積極思考如何破壞代碼。

- 當事情被公認應該會出錯時，別忘了檢查是否有異常如期被拋出。

- 不要由於「測試沒法捕捉全部Bug」，就不撰寫測試代碼，由於測試的確能夠捕捉到大多數Bug。

- 「花合理時間抓出大多數Bug」要好過「窮盡一輩子抓出全部Bug」。由於當測試數量達到必定程度以後，測試效益就會呈現遞減態勢，而非持續遞增。

說到《重構》這本書，其實在每一個重構方法中都有「做法（Mechanics）」一段，在重構的實踐中按照上面所述的步驟進行是比較穩妥的，同時也能避免不少不經意間製造的回退出現。

 

4. 要求提交代碼前作Code Review，而開發人員不作，或敷衍了事，怎麼辦？

 

若是每一個開發人員都是積極主動的，Code Review的做用能落到實處。但若是不是呢？團隊管理者須要一些手段促使其有效地進行Code Review。首先，咱們採用的Code Review有2種形式，一是Over-the-shoulder，也就是2我的座在一塊兒，一我的講，另外一我的審查。二是用工具Code Collaborator來進行。不管哪一種形式，在提交代碼時，必須註明關於審查的信息，好比：審查者（Reviewer）的名字或審查號（Review ID，Code Collaborator自動生成），天天由一名專職人員來檢查Checklist中的每一條，看是否有人漏寫這些信息，若是發現會提醒提交的人補上。另外，某段提交的代碼出問題，提交者和審查者都要一塊兒來解決出現的問題，以最大限度避免審查過程敷衍了事。

 

博主Inovy在某個評論說的很形象：「木（沒）有賞罰的制度，就是帶到廁所的報紙，看完就能夠用來擦屁股了。」沒有獎懲制度做保證，固然上面的要求沒有什麼效力。因此，當有人常常不審查就提交，或審查時不負責任，它的績效評定就會所以低一點，而績效的評分是跟每一年工資漲落掛鉤的。說白了，可能某我的會由於屢次被查出沒有作Code Review就提交代碼，而到年末加薪時比別人少漲500塊錢。

 

5. 軟件研發到底需不須要文檔？

 

軟件研發須要文檔的起原可能有2種，一是比較原始的，須要文檔是爲了當開發人員離職後，企業須要接手的人能根據文檔瞭解他所接手的代碼或模塊的設計。二是較高層次的，企業聽從ISO9001質量管理體系或CMMI。

 

對於第一種，根源可能來自於兩個方面：

- 原開發人員設計編碼水平不高，其代碼可讀性較差。

- 設計思想和代碼只有一我的瞭解，此人一旦離職，無人知道其細節。

在編碼前寫一些簡單的設計文檔，有助於理清思路，尤爲是輔以一些UML圖，在交流時也是有好處的。但同時，咱們也應該提升開發人員的編碼水平增長其代碼的可讀性，好比加強其變量命名的可讀性、用一些被你們所瞭解的設計模式來替代按本身某些獨特思路編寫的代碼、增長和改進註釋等等，以減小沒必要要的文檔。另外推行代碼的集體全部權（Collective Ownership），避免某些代碼只被一我的瞭解，這樣能夠減小以此爲目的而編寫的文檔。

 

對於第二種，狀況有些複雜。接觸過敏捷開發的人都知道《敏捷宣言》中的「能夠工做的軟件勝於面面俱到的文檔」。接觸過CMMI開發或者ISO9001質量管理體系的人知道它們對文檔的要求是多麼的高。它們看起來勢不兩立。可是，它們的宗旨是一致的，即：構建高質量的產品。

 

對於敏捷，使用手寫用戶故事來記錄需求和優先級的方法，以及在白板上寫畫的非正式設計，是不能經過ISO9001的審覈的，但當把它們複印、拍照、增長序號、保存後，能夠經過審覈。每次都是成功的Daily Build和Auto Test報告沒法證實它們是否真正被執行並真正成功，因此不能經過ISO9001的審覈。但添加一個斷言失敗（相似assert(false)的斷言）的測試後，則能夠經過審覈。

 

CMMI與敏捷也是互補的，前者告訴組織在整體條款上作什麼，可是沒有說如何去作，後者是一套最佳實踐。SCRUM之類的敏捷方法也被引入過那些已經過CMMI5級評估的組織。不少企業忘記了最終目標是改進他們構建軟件及遞交產品的方式，相反，它們關注於填寫按照CMMI文檔描述的假想的缺陷，卻不關心這些變化是否能改進過程或產品。

 

因此敏捷開發在過程當中只編寫夠用的文檔，和以「信息的溝通、符合性的證據以及知識共享」做爲主要目標的質量體系文檔要求並不矛盾。在實踐中，咱們能夠按如下方法作，在實現SCRUM的同時，符合審覈和評估的要求：

 

- 製做格式良好的、被細化的、被保存的和能跟蹤的Backlog。複印和照片一樣有效。

- 將監管須要的文檔工做也放入Backlog。除了能夠確保它們不被忘記，還能使監管要求的成本是可見的。

- 使用檢查列表，以向審覈員或評估員證實活動已執行。團隊對「完成」的定義(Definition of 「Done」)能夠很容易轉變爲一份檢查列表。

- 使用敏捷項目管理工具。它其實就是開發程序和記錄的電子呈現方式。

 

總而言之，軟件研發須要文檔（但文檔的形式能夠是多種多樣的，用Word寫的文字式的文件是文檔，用Visio畫的UML圖也是文檔，保存在Quality Center中的測試用例也是文檔），同時咱們只需寫夠用的文檔。

 

6. 當有開發人員在開發過程當中遇到難題，工做沒法繼續，於是拖延進度，怎麼解決？

 

這也是個常遇到的問題。若是管理者對於某個工程師的具體問題進行指導，就會陷入過分微觀管理的境地。咱們須要找到宏觀解決辦法。一，咱們基於Scrum的「團隊有共同的目標」這一規則，利用前面提到的集體全部權，當出現這些問題時，用團隊中全部可使用的力量來幫助其擺脫困境，而不是任其餘人袖手旁觀。固然這裏會牽扯到績效評定的問題，好比：提供幫助的人會以爲，他的幫助無助於本身績效評定的提升，爲何要提供幫助。這須要人力資源部門在使用Scrum開發的團隊的績效評估中，儘可能消除那些傾向我的的因素，還要包含團隊協做的因素，普遍聽取個方面的意見，更頻繁地評估績效等等。

 

二，即便動用全部可使用的力量，若是某個難題真的沒法逾越，爲了減小不能按時交付的風險，產品負責人應當站出來，並有所做爲。要麼從新評估Backlog的優先級，使沒法繼續的Backlog遲一點交付，先作一些相對較低優先級的Backlog，以保證總體交付時間不至於延長；要麼減小部分功能，給出更多的時間去攻克難題。總之逾越技術上難關會使團隊的生產率降低，產品負責人必須做出取捨。

 

7. 有些開發人員水平相對不高，如何保證他們的代碼質量？

 

固然首先讓較有經驗的人Review其要提交的代碼，這幾乎是全部管理者會作的事。除此以外，管理者有責任幫助這些人（也包括水平較高的人）提升水平，他們能夠看一些書，上網看資料，讀別人的代碼等等，途經仍是不少的。但問題是你如何去衡量其是否真正有所收穫。咱們的經驗是，在每一年大約3月份爲每一個工程師制定整個年度的目標，每一個人的目標包括產品上的，技術上的，我的能力上的等4到5項。半年後和一年後，要作兩次Performance Review，目標是否實現，也會跟績效評定掛鉤。咱們在制定目標時，遵循SMART原則，即：

 

Specific（明確的）：目標應該按照明確的結果和成效表述。

Measurable（可衡量的）：目標的完成狀況應該能夠衡量和驗證。

Aligned（結盟的）：目標應該與公司的商業策略保持一致。

Realistic（現實的）：目標雖然應具挑戰性，但更應該能在給定的條件和環境下實現。

Time-Bound（有時限的）：目標應該包括一個實現的具體時間。

 

好比：某我的制定了「初步掌握本地化技術」的目標，他要肯定實現時間，要描述學習的途經和步驟，要經過將技術施加到公司現有的產品中，爲公司產品的本地化/國際化/全球化做一些探索，並製做Presentation給團隊演示他的成果，並準備回答其餘人提出的問題。團隊還爲了配合其實現目標，組織Tech Talk的活動，供你們分享每一個人的學習成果。經過這些手段，提升開發人員的自學興趣，並逐步提升開發人員的技術水平。

 

8. 如何提升開發人員的主觀能動性？

 

提升開發人員的主觀能動性，少不了激勵機制。不能讓開發人員感到，5年之後的他和如今比不會有什麼進步。你要讓他感到他所從事的是一個職業（Career），而不僅是一份工做（Job）。不然，他們是不會主動投入到工做中的。咱們的經驗是提供一套職業發展的框架。框架制定了2類發展道路，管理類（Managerial Path）和技術類（Technical Path），6個職業級別（1-3級是Entry/Associate，Intermediate，Senior。4級管理類是Manager/Senior Manager，技術類是Principal/Senior Principal。5級管理類是Director/Senior Director，技術類是Fellow/Architect。6級是Executive Management）。每一個級別都有13個方面的具體要求，包括：範圍（Scope）、跨職能（Cross Functional）、層次（Level）、知識（Knowledge）、指導（Guidance）、問題解決（Problem Solving）、遞交成果（Delivering Result）、責任感（Responsbility）、導師（Mentoring）、交流（Communication）、自學（Self-Learning），運做監督（Operational Oversight），客戶響應（Customer Responsiveness）。每一年有2次提升級別的機會，開發人員一旦具有了升級的條件，他的Supervisor將會提出申請，一旦批准，他的頭銜隨之提升，薪水也會有相對較大提升。從而使每一個開發人員以爲「有奔頭」，天然他們的主觀能動性也就提升了。

 

上面的「套路」涉及了軟件研發團隊管理中的研發過程、技術實踐、文檔管理、激勵機制等一些方面。但只是九牛一毛，研發團隊管理涵蓋的內容還有不少不少，還須要管理者在不斷探索和實踐的道路上學習和掌握。