中大型軟件開發(fā)，免不了團隊開發(fā)，團隊開發(fā)少不了分工合作。在團隊開發(fā)中，當然每個人的能力都很重要，但是我認為可信賴的工作是團隊開發(fā)的首要條件，也是團隊開發(fā)存在的基本保證。沒有可信賴的工作，沒有團隊分工合作，即便有團隊存在，也會變成一只內耗極高的團隊，管理協(xié)調的代價超過團隊的優(yōu)勢，團隊的價值會被堙沒，便沒有存在的價值了。

軟件開發(fā)中可信賴的工作，是指：團隊開發(fā)中，向小組或者個人分配的一個模塊、一項任務應該開始前應該有可信賴的評估和分工，在開始時候被可信賴的計劃，在執(zhí)行中可信賴的反饋，執(zhí)行過程中完成時間應該被可信賴，執(zhí)行結束后要有可信賴的質量和可信賴的測試與后繼補充性開發(fā)和修正工作。相反的為軟件開發(fā)中的不可信賴工作或者不可信賴因素。

大多數新團隊的開發(fā)工作中的組員的工作是不可信賴的，舉個簡單的離子，架構師或者主程序員分工好以后，交給一個小組一個模塊，或者交給一個人一個模塊。雖然有過反復的叮囑，應該仔細，應該做好細節(jié)。但是每次員工遞交上來的模塊后，經過測試，會發(fā)現很多的問題，根本不可信賴。有時候一個模塊交給團隊組員去開發(fā)，用了三天時間，為了修正他們的錯誤，不得不把所有的代碼去看一遍，后修正工作似乎也用了三天時間，而這些問題中的絕大多數問題為不小心或者不細致導致的問題，這些問題中的絕大多數問題會反復出現在后繼工作中，即便你重申過多次。當你把某項工作交給某個人的時候，你不敢相信他可以按質按時的完成，等他完成后遞交，你不能確認他的工作真的完成了，或者只是為了應付差事，他自己認為完成了。以至于大家都認為完成的東西，到后才發(fā)現原來根本沒有完成，讓團隊無法托付工作給組員。讓客戶無法托付產品給公司。這樣的問題非常嚴重，輕則耽誤工期，延誤時機，增加開發(fā)成本和團隊管理內耗，重則可能影響到產品成敗，甚至公司的前途，所以不得不把可信賴工作放到所有的管理的首位。

根據以前項目開發(fā)的經驗，我做了以下整理，反應到真實的軟件開發(fā)中大概如下：

首先、任務開始前，管理者應該對問題的描述、任務的規(guī)模、要求、開發(fā)完成后的質量和約束有著清晰而深刻的立即。同時對團隊組員的技術水平、時間安排、工作效率和態(tài)度有著清晰的認識，知道誰可以勝任，誰不能勝任。應該如何去分配工作，大概需要用時多少，會出現什么狀況有著清晰的認知。這個是可信賴工作的前提。

其次、任務分配后，組員開始開發(fā)前，應該確保和管理者進行過有效的溝通，雙方對任務的理解一致而且無歧義。然后組員應該對任務作出基本的計劃和規(guī)劃，列出任務要點以及分工的先后次序，同時對任務作出自我評估，判斷是否可以勝任，同時估計該項任務完成的時間和工作量。并且應該以正式報表的形式進行遞交。團隊雖小，個人認為這個報表少不了，不必太過擔心在這樣的報表中花費的時間和成本，切記磨刀不誤砍柴工。

然后、任何開始執(zhí)行以后，要有一個定時的回報，方便管理者知道的進度。回報的內容應該包括：當前已經完成的工作，剩余的工作以及計劃的調整。以及開發(fā)中遇到的難點和遺漏點�；貓蟛皇菫榱粟s進度，而是為了準確的了解信息，在回報中，管理者不可過分干預工作進度，但求做到心中有數即可。同時任何團隊的組員應該明白：可信賴的工作不僅僅是在時間上可信賴，而且更應該是在質量上可信賴。質量上的要求要遠遠高于時間上的可信賴。

再次 、任務執(zhí)行完成以后，必須有一個報表：這個報表要求明確的寫明開發(fā)者是誰，測試者是誰。同時要簽入源代碼，因為團隊水平不可能完全一致，允許有無法完成的任務點，但是報表必須寫明什么沒有完成，原因是什么。允許完不成的任務，但是完成的任務一定是可信賴的。即功能上沒任何遺漏、質量上沒任何技術缺陷或者粗心帶來的遺漏性缺陷。同時時間上沒明顯的逾期。

后、對簽入的代碼加入框架進行測試，然后對任務應該有一個基本的評估，根據開發(fā)前的報表和開發(fā)后的報表，以及軟件模塊的實際質量做一個評估，要求評估客觀有威信。然后做出賞罰。

以上即為可信賴工作的幾個要點，看上去簡單可行，但實際操作中卻很難執(zhí)行。根據個人帶領團隊的經驗，做出以下幾點措施。
第一、讓團隊每一個人都能明白：一個人能力可以有大小，技術可以有差異，但是服從性和細致性的工作方面的要求沒有區(qū)別，不管是技術大牛還是實習小菜，交給的任務，完不成可以提出來超出自己的能力范圍，但是一旦去做，要做好！保證每個細節(jié)都不會出現問題，經得起測試和推敲。每個測試人員都應該明白可信賴的重要性，切實把握好關。同時對于任何一次沒有經過嚴格測試而遺留下來的Bug進行評估，如果因為非不可預見因素導致的，要進行懲罰。對于無法勝任可信賴工作的人，建議直接清理。培養(yǎng)可信賴的工作意識，是以第一要務。

第二、分配工作的時候留足余地，考慮到非可信賴發(fā)生后的補救工作，同時根據工作的難度和生疏程度，應該乘以一個時間系數，一般工作可以乘以1.2，自己陌生的團隊和陌生的工作，應該乘以 3。同時每次根據以往的工作，對每個組員做一個系數評估。方便以后工作分配。

第三、明確工作內容、范圍和質量的約束，在分工前讓組員明白自己要完成的任務要求，包括功能要求和非功能要求，特別應該了解非功能部分的質量約束，比如魯棒性要求、擴展性和健壯性的要求。同時鼓勵組員提升質量標準和細節(jié)標準，確定明確的獎罰制度。
第四、不要把一項工作和任務安排周期太長，每三天到五天應該有一次小規(guī)模的驗收行動，確保每個組員的短期可信賴的工作，因為非可信賴因素會慢慢出現和積累，如果安排一個較長期的工作，往往到后容易失去控制。短期非可信賴容易控制和踢出不良因素。
第四、做好獎罰制度，一個團隊中，不可信賴的工作應該是懲罰較重的懲罰點。同時每個小組要指定可信賴度監(jiān)督和檢測員，保證不良因素在底層解決，而非到上層以后再去解決。任何一個小的Bug在程序設計環(huán)節(jié)想到如何處理，成本低，后而進入程序開發(fā)環(huán)節(jié)，后進入測試環(huán)節(jié)，到簽入質量檢測環(huán)節(jié)，遞交客戶，到售后環(huán)節(jié)，每增一個環(huán)節(jié)，增加一份成本。

第五、開發(fā)未動，測試先行，我們嘗試過按照接口去分配類庫，后把類庫組合在一起的做法，發(fā)現：很多人在無法測試的情況下，去做開發(fā)，然后拼裝在一起后去測試，無法發(fā)現一些問題，而且這樣過分依賴開發(fā)人員的經驗和技術，非常不同。同時問題遞交到軟件上去測試，容易掩蓋問題。并且增加問題解決的復雜度。

第六、建立良好的信賴跟蹤體系，要建立良好的質量跟蹤體系，必須明確每個環(huán)節(jié)的每個開發(fā)人員、測試人員，以及任何形式的決策和貢獻者。對出現問題的原因和人員做記錄和跟蹤，質量體系不僅僅要跟蹤 軟件開發(fā)中遇到的bug，還要跟蹤進度、時間、工作量、質量等等。這樣可以方便后期把一些常見的問題規(guī)范化和文字化，同時還有助于分工的時候對每個員工的把握以及后期的選拔等等。