中大型軟件開發(fā)，免不了團(tuán)隊(duì)開發(fā)，團(tuán)隊(duì)開發(fā)少不了分工合作。在團(tuán)隊(duì)開發(fā)中，當(dāng)然每個(gè)人的能力都很重要，但是我認(rèn)為可信賴的工作是團(tuán)隊(duì)開發(fā)的首要條件，也是團(tuán)隊(duì)開發(fā)存在的基本保證。沒有可信賴的工作，沒有團(tuán)隊(duì)分工合作，即便有團(tuán)隊(duì)存在，也會變成一只內(nèi)耗極高的團(tuán)隊(duì)，管理協(xié)調(diào)的代價(jià)超過團(tuán)隊(duì)的優(yōu)勢，團(tuán)隊(duì)的價(jià)值會被堙沒，便沒有存在的價(jià)值了。
軟件開發(fā)中可信賴的工作，是指：團(tuán)隊(duì)開發(fā)中，向小組或者個(gè)人分配的一個(gè)模塊、一項(xiàng)任務(wù)應(yīng)該開始前應(yīng)該有可信賴的評估和分工，在開始時(shí)候被可信賴的計(jì)劃，在執(zhí)行中可信賴的反饋，執(zhí)行過程中完成時(shí)間應(yīng)該被可信賴，執(zhí)行結(jié)束后要有可信賴的質(zhì)量和可信賴的測試與后繼補(bǔ)充性開發(fā)和修正工作。相反的為軟件開發(fā)中的不可信賴工作或者不可信賴因素。
大多數(shù)新團(tuán)隊(duì)的開發(fā)工作中的組員的工作是不可信賴的，舉個(gè)簡單的離子，架構(gòu)師或者主程序員分工好以后，交給一個(gè)小組一個(gè)模塊，或者交給一個(gè)人一個(gè)模塊。雖然有過反復(fù)的叮囑，應(yīng)該仔細(xì)，應(yīng)該做好細(xì)節(jié)。但是每次員工遞交上來的模塊后，經(jīng)過測試，會發(fā)現(xiàn)很多的問題，根本不可信賴。有時(shí)候一個(gè)模塊交給團(tuán)隊(duì)組員去開發(fā)，用了三天時(shí)間，為了修正他們的錯(cuò)誤，不得不把所有的代碼去看一遍，后修正工作似乎也用了三天時(shí)間，而這些問題中的絕大多數(shù)問題為不小心或者不細(xì)致導(dǎo)致的問題，這些問題中的絕大多數(shù)問題會反復(fù)出現(xiàn)在后繼工作中，即便你重申過多次。當(dāng)你把某項(xiàng)工作交給某個(gè)人的時(shí)候，你不敢相信他可以按質(zhì)按時(shí)的完成，等他完成后遞交，你不能確認(rèn)他的工作真的完成了，或者只是為了應(yīng)付差事，他自己認(rèn)為完成了。以至于大家都認(rèn)為完成的東西，到后才發(fā)現(xiàn)原來根本沒有完成，讓團(tuán)隊(duì)無法托付工作給組員。讓客戶無法托付產(chǎn)品給公司。這樣的問題非常嚴(yán)重，輕則耽誤工期，延誤時(shí)機(jī)，增加開發(fā)成本和團(tuán)隊(duì)管理內(nèi)耗，重則可能影響到產(chǎn)品成敗，甚至公司的前途，所以不得不把可信賴工作放到所有的管理的首位。
根據(jù)以前項(xiàng)目開發(fā)的經(jīng)驗(yàn)，我做了以下整理，反應(yīng)到真實(shí)的軟件開發(fā)中大概如下：
首先、任務(wù)開始前，管理者應(yīng)該對問題的描述、任務(wù)的規(guī)模、要求、開發(fā)完成后的質(zhì)量和約束有著清晰而深刻的立即。同時(shí)對團(tuán)隊(duì)組員的技術(shù)水平、時(shí)間安排、工作效率和態(tài)度有著清晰的認(rèn)識，知道誰可以勝任，誰不能勝任。應(yīng)該如何去分配工作，大概需要用時(shí)多少，會出現(xiàn)什么狀況有著清晰的認(rèn)知。這個(gè)是可信賴工作的前提。
其次、任務(wù)分配后，組員開始開發(fā)前，應(yīng)該確保和管理者進(jìn)行過有效的溝通，雙方對任務(wù)的理解一致而且無歧義。然后組員應(yīng)該對任務(wù)作出基本的計(jì)劃和規(guī)劃，列出任務(wù)要點(diǎn)以及分工的先后次序，同時(shí)對任務(wù)作出自我評估，判斷是否可以勝任，同時(shí)估計(jì)該項(xiàng)任務(wù)完成的時(shí)間和工作量。并且應(yīng)該以正式報(bào)表的形式進(jìn)行遞交。團(tuán)隊(duì)雖小，個(gè)人認(rèn)為這個(gè)報(bào)表少不了，不必太過擔(dān)心在這樣的報(bào)表中花費(fèi)的時(shí)間和成本，切記磨刀不誤砍柴工。
然后、任何開始執(zhí)行以后，要有一個(gè)定時(shí)的回報(bào)，方便管理者知道的進(jìn)度�；貓�(bào)的內(nèi)容應(yīng)該包括：當(dāng)前已經(jīng)完成的工作，剩余的工作以及計(jì)劃的調(diào)整。以及開發(fā)中遇到的難點(diǎn)和遺漏點(diǎn)�；貓�(bào)不是為了趕進(jìn)度，而是為了準(zhǔn)確的了解信息，在回報(bào)中，管理者不可過分干預(yù)工作進(jìn)度，但求做到心中有數(shù)即可。同時(shí)任何團(tuán)隊(duì)的組員應(yīng)該明白：可信賴的工作不僅僅是在時(shí)間上可信賴，而且更應(yīng)該是在質(zhì)量上可信賴。質(zhì)量上的要求要遠(yuǎn)遠(yuǎn)高于時(shí)間上的可信賴。
再次 、任務(wù)執(zhí)行完成以后，必須有一個(gè)報(bào)表：這個(gè)報(bào)表要求明確的寫明開發(fā)者是誰，測試者是誰。同時(shí)要簽入源代碼，因?yàn)閳F(tuán)隊(duì)水平不可能完全一致，允許有無法完成的任務(wù)點(diǎn)，但是報(bào)表必須寫明什么沒有完成，原因是什么。允許完不成的任務(wù)，但是完成的任務(wù)一定是可信賴的。即功能上沒任何遺漏、質(zhì)量上沒任何技術(shù)缺陷或者粗心帶來的遺漏性缺陷。同時(shí)時(shí)間上沒明顯的逾期。
后、對簽入的代碼加入框架進(jìn)行測試，然后對任務(wù)應(yīng)該有一個(gè)基本的評估，根據(jù)開發(fā)前的報(bào)表和開發(fā)后的報(bào)表，以及軟件模塊的實(shí)際質(zhì)量做一個(gè)評估，要求評估客觀有威信。然后做出賞罰。
以上即為可信賴工作的幾個(gè)要點(diǎn)，看上去簡單可行，但實(shí)際操作中卻很難執(zhí)行。根據(jù)個(gè)人帶領(lǐng)團(tuán)隊(duì)的經(jīng)驗(yàn)，做出以下幾點(diǎn)措施。
第一、讓團(tuán)隊(duì)每一個(gè)人都能明白：一個(gè)人能力可以有大小，技術(shù)可以有差異，但是服從性和細(xì)致性的工作方面的要求沒有區(qū)別，不管是技術(shù)大牛還是實(shí)習(xí)小菜，交給的任務(wù)，完不成可以提出來超出自己的能力范圍，但是一旦去做，要做好！保證每個(gè)細(xì)節(jié)都不會出現(xiàn)問題，經(jīng)得起測試和推敲。每個(gè)測試人員都應(yīng)該明白可信賴的重要性，切實(shí)把握好關(guān)。同時(shí)對于任何一次沒有經(jīng)過嚴(yán)格測試而遺留下來的Bug進(jìn)行評估，如果因?yàn)榉遣豢深A(yù)見因素導(dǎo)致的，要進(jìn)行懲罰。對于無法勝任可信賴工作的人，建議直接清理。培養(yǎng)可信賴的工作意識，是以第一要?jiǎng)?wù)。
第二、分配工作的時(shí)候留足余地，考慮到非可信賴發(fā)生后的補(bǔ)救工作，同時(shí)根據(jù)工作的難度和生疏程度，應(yīng)該乘以一個(gè)時(shí)間系數(shù)，一般工作可以乘以1.2，自己陌生的團(tuán)隊(duì)和陌生的工作，應(yīng)該乘以 3。同時(shí)每次根據(jù)以往的工作，對每個(gè)組員做一個(gè)系數(shù)評估。方便以后工作分配。
第三、明確工作內(nèi)容、范圍和質(zhì)量的約束，在分工前讓組員明白自己要完成的任務(wù)要求，包括功能要求和非功能要求，特別應(yīng)該了解非功能部分的質(zhì)量約束，比如魯棒性要求、擴(kuò)展性和健壯性的要求。同時(shí)鼓勵(lì)組員提升質(zhì)量標(biāo)準(zhǔn)和細(xì)節(jié)標(biāo)準(zhǔn)，確定明確的獎(jiǎng)罰制度。
第四、不要把一項(xiàng)工作和任務(wù)安排周期太長，每三天到五天應(yīng)該有一次小規(guī)模的驗(yàn)收行動，確保每個(gè)組員的短期可信賴的工作，因?yàn)榉强尚刨囈蛩貢霈F(xiàn)和積累，如果安排一個(gè)較長期的工作，往往到后容易失去控制。短期非可信賴容易控制和踢出不良因素。
第四、做好獎(jiǎng)罰制度，一個(gè)團(tuán)隊(duì)中，不可信賴的工作應(yīng)該是懲罰較重的懲罰點(diǎn)。同時(shí)每個(gè)小組要指定可信賴度監(jiān)督和檢測員，保證不良因素在底層解決，而非到上層以后再去解決。任何一個(gè)小的Bug在程序設(shè)計(jì)環(huán)節(jié)想到如何處理，成本低，后而進(jìn)入程序開發(fā)環(huán)節(jié)，后進(jìn)入測試環(huán)節(jié)，到簽入質(zhì)量檢測環(huán)節(jié)，遞交客戶，到售后環(huán)節(jié)，每增一個(gè)環(huán)節(jié)，增加一份成本。
第五、開發(fā)未動，測試先行，我們嘗試過按照接口去分配類庫，后把類庫組合在一起的做法，發(fā)現(xiàn)：很多人在無法測試的情況下，去做開發(fā)，然后拼裝在一起后去測試，無法發(fā)現(xiàn)一些問題，而且這樣過分依賴開發(fā)人員的經(jīng)驗(yàn)和技術(shù)，非常不同。同時(shí)問題遞交到軟件上去測試，容易掩蓋問題。并且增加問題解決的復(fù)雜度。
第六、建立良好的信賴跟蹤體系，要建立良好的質(zhì)量跟蹤體系，必須明確每個(gè)環(huán)節(jié)的每個(gè)開發(fā)人員、測試人員，以及任何形式的決策和貢獻(xiàn)者。對出現(xiàn)問題的原因和人員做記錄和跟蹤，質(zhì)量體系不僅僅要跟蹤 軟件開發(fā)中遇到的bug，還要跟蹤進(jìn)度、時(shí)間、工作量、質(zhì)量等等。這樣可以方便后期把一些常見的問題規(guī)范化和文字化，同時(shí)還有助于分工的時(shí)候?qū)γ總�(gè)員工的把握以及后期的選拔等等。
