本文是敏捷開發一千零一問的第三十七篇。（欄目總目錄）
來源：來自提問帖http://blog.csdn.net/cheny_com/article/details/7564388#reply20樓
問題：
我有一個問題，衆所周知敏捷實施中，每個task的時間是團隊自己定的，才能保證團隊有效的高質量完成，這是不是和客戶要求的deadline衝突了呢，團隊自己定的時間如果過多就會影響準時的交付，而如果不影響交付，必然會產生加班以至於質量問題。在實際中怎麼去協調這個呢？
回答：
總則上講，就是牢記一句話：進度是質量之敵，質量是進度之友。
因進度而損失的質量是不可挽回的，很多人說以後再改好就是了，但我見到最多的就是要末不改，要麼扔了重新來。
因質量而損失的進度是可以挽回的，因爲後期（等等會重新定義“後期”）沒有Bug，代碼又能複用，如果還比別人慢，就沒道理了。
但具體做的時候，還是要注意一些事情的
1. 快速收益
剛纔提到一個詞，叫做“後期”，這是個很矛盾的詞，因爲一定要把“後期”“提前”。也就是說，不能爲了質量而質量，無視進度的需求而盲目搭建龐大的底層庫和平臺。
在鬆結對編程系列（http://blog.csdn.net/column/details/agiledeptcheny.html）的L型代碼結構的幾篇文章中提到，底層庫（L的水平部分）必須是爲了上層應用（L的垂直部分）而出現的。
真正的高手，如果給他一個很急的活，讓他“隨便做”，做完之後，會發現代碼很漂亮，完全符合“不急的活”的標準。這是因爲在高手眼中，高質量的就是快速的，兩者都是一樣的，否則就不稱之爲高手。
高手做完“很急的活”之後會說這麼幾句話：“因爲……，所以我沒考慮……的情況；”“另外，性能上……”；“還有就是……”而不能這麼說：”這堆代碼你看不懂是因爲……“”爲了打字快點，這個變量被叫做a……“”以後這段代碼可能會拆成10個函數……“
因此實際上，編寫高質量的底層庫不花費額外的時間；真正花費時間的是“需求鍍金”，就是做了額外的事情，本系統，或者現在，不需要的內容。
2. 管理整個團隊
高手如此，新手就不然了，他們是真的會幹出蘿蔔快了不洗泥的活的。
這個在鬆結對編程系列（http://blog.csdn.net/column/details/agiledeptcheny.html）中有比較多的描述了，就是讓高手監督、指導新手的工作。
這裏邊可能有幾個誤區：
2.1 高手很忙，有時間監督、指導新手嗎？
招聘徒弟這件事情，必須是由高手驅動的，不能塞給他一個徒弟。而高手去招聘徒弟的時候，必須招收一個自己每天付出1小時的指導時間，新手能回報2小時的工作量的徒弟，否則就別招。如果這兩者都做不到，可能是師傅水平還不夠高（沒有高到能用新人的水平），或者徒弟招的不合適（沒有”好“——不是”高“——到能被師傅帶的水平）。
2.2 新手天天”複用“高手的代碼，自己學不到東西怎麼辦？
我見過的工作了很久但水平奇爛的程序員（包括95～01年這六年中間的我），無外乎兩種情況：一，自己埋頭編程，從來沒見過什麼是好代碼；二、人生三大憾集於一身（遇良師不學，遇好友不交，遇良機不握）
高手在試用期期間（徒弟是他找來的），要迅速判斷新手是一還是二。如果是一，利用調用代碼的機會傳授一下編程方法；如果是二，送回社會以待天時。
2.3 新手拖累高手怎麼辦？
還是2.1的思想，高手要以完成項目爲目標，而不要以帶徒弟爲目標。因此，應該循序漸進地招徒弟，培養徒弟。
換言之，師傅招徒弟這件事情，很像L型代碼結構。沒有一個徒弟是爲了培養而招聘來的，都是爲了更快地完成工作才找來的；否則就是團隊級別的”需求鍍金“了。
3. 保持專業性
人類天生尊重專家，而蔑視奴才。
若我們的專業性說服自己：”保證質量纔是快速完成這個項目的真正方法“，那麼就要堅持它；若不能堅持，則說明我們還沒有真正把客戶的價值放在首位，而只是把”自己當下千萬不要擔當責任“放在首位了。
畢竟客戶，以及老闆，最後的目標都是快速拿到好的產品，而不是聘用一堆唯命是從的奴才。
所以如果我們能在最終（這個最終，也是和之前的”後期“一樣，不要遙遙無期的那種，要快）證明我們是正確的，自然而然他們就會被說服了——因爲按他們的進度蠻力編碼的團隊最後都陷入泥潭，唯有這個開始有點固執己見的團隊的產品是最好的，還有比這更能說明問題的嗎？
我還沒見過因爲堅持專業性被開掉的人，但是的確見過無視客戶的進度，只爲自己心目中的”理想“而工作的人被開掉的。後者就是完全將質量和進度對立起來，忽視L的垂直部分而過度追求L的水平部分的人。