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

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

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

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

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

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

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

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

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

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

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

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

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

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