進度與質量的衝突

敏捷開發一千零一問系列之三十七：進度與質量的衝突

眾所周知，敏捷實施中，每個task的時間是團隊自己定的，這樣才能保證有效而高質量地完成。這是不是和客戶要求的deadline衝突了呢？團隊自己定的時間如果過多，就會影響按時交付，而如果想要不影響交付，必然會產生加班以至於質量問題。在實際中怎麼去協調這個呢？

總則上講，就是牢記一句話：進度是質量之敵，質量是進度之友。

因進度而損失的質量是不可挽回的，很多人說以後再改好就是了，但我見到最多的就是要末不改，要麼扔了重新來。

因質量而損失的進度是可以挽回的，因為後期沒有bug，**又能復用，如果還比別人慢，就沒道理了。

但具體做的時候，還是要注意一些事情的：

剛才提到乙個詞，叫做「後期」，這是個很矛盾的詞，因為一定要把「後期」「提前」。也就是說，不能為了質量而質量，不能無視進度的需求而盲目搭建龐大的底層庫和平台。

在松結對程式設計系列的l型**結構的幾篇文章中提到，底層庫（l的水平部分）必須是為了上層應用（l的垂直部分）而出現的。

真正的高手，如果給他乙個很急的活，讓他「隨便做」，做完之後，會發現**很漂亮，完全符合「不急的活」的標準。這是因為在高手眼中，高質量的就是快速的，兩者都是一樣的，否則就不能稱之為高手。

高手做完「很急的活」之後，會說這麼幾句話：「因為……，所以我沒考慮……的情況。」「另外，效能上……」「還有就是……」而不能這麼說：」這堆**你看不懂，是因為……「」為了打字快點，這個變數被叫做a……「」以後這段**可能會拆成10個函式……「

實際上，編寫高質量的底層庫不花費額外的時間。真正花費時間的是「需求鍍金」，就是做了額外的事情，做了不需要的內容。

高手如此，新手就不然了，他們是真的會幹出蘿蔔快了不洗泥的活的。

這個在松結對程式設計系列中有比較多的描述了，就是讓高手監督、指導新手的工作。

這裡邊可能有幾個誤區：

招聘徒弟這件事情，必須是由高手驅動的，不能塞給他乙個徒弟。而高手去招聘徒弟的時候，必須招收乙個自己每天付出乙個小時去指導，新手能回報兩個小時的徒弟，否則就別招。如果做不到這樣，可能是師傅水平還不夠高（沒有高到能用新人的水平），或者徒弟招的不合適（沒有「好」——不是「高」——到能被師傅帶的水平）。

我見過的工作了很久但水平奇爛的程式設計師（包括95～01年這六年中間的我），無外乎兩種情況：一，自己埋頭程式設計，從來沒見過什麼是好**；二、人生三大憾集於一身（遇良師不學，遇好友不交，遇良機不握）

在試用期期間（徒弟是他找來的），高手要迅速判斷新手是一還是二。如果是一，利用呼叫**的機會傳授一下程式設計方法；如果是二，送回社會以待天時。

還是2.1的思想，高手要以完成專案為目標，而不要以帶徒弟為目標。因此，應該循序漸進地招徒弟，培養徒弟。

換言之，師傅招徒弟這件事情，很像l型**結構。沒有乙個徒弟是為了培養而招聘來的，都是為了更快地完成工作才找來的；否則就是團隊級別的「需求鍍金」了。

人類天生尊重專家，而蔑視奴才。

若我們的專業性說服自己：「保證質量才是快速完成這個專案的真正方法」，那麼就要堅持它；若不能堅持，則說明我們還沒有真正把客戶的價值放在首位，而只是把「自己當下千萬不要擔當責任」放在首位了。

畢竟客戶，以及老闆，最後的目標都是快速拿到好的產品，而不是聘用一堆唯命是從的奴才。

所以如果我們能在最終（這個最終，也是和之前的「後期」一樣，不要遙遙無期的那種，要快）證明我們是正確的，自然而然他們就會被說服了——因為按他們的進度蠻力編碼的團隊最後都陷入泥潭，唯有這個開始有點固執己見的團隊的產品是最好的，還有比這更能說明問題的嗎？

我還沒見過因為堅持專業性被開掉的人，但是的確見過無視客戶的進度，只為自己心目中的「理想」而工作的人被開掉的。後者就是完全將質量和進度對立起來，忽視l的垂直部分而過度追求l的水平部分的人。