法則二十七：
Be like the doctors 用醫生的方法
當病人已經藥石罔效時，醫生通常會對病情有所保留，避免病人太過悲觀或恐懼，并且盡量鼓勵病人保持希望，最好能讓病人有個期望完成的目標。
醫生絕對不會斬釘截鐵地斷言什么醫療行為一定會有什么樣的結果，反而是以
一種自在且充滿信心的口吻說：“試試看吧，一切都還沒有確定呢。
另外一件應該向醫生學習的事情是，即使是再小再簡單的醫療行為，都帶著幾分風險，所以醫生會說：“當然，任何情況都是有可能的，治愈率再高我都不能跟你說百分之百沒問題。
法則二十八：
Remember the triangle:features, resources, times 軟件開發金三角：特色、資源和時間
作為一位軟件開發的領導人，你得集中注意力在三件事情：資源（人和錢）、特色（產品與其品質）和時間。這三件事是軟件開發的核心，其他的都是外圍。
資源、特色和時間是三角形的三個邊，任何一邊的變化，都會影響到另外一邊或兩邊。所以如果時間落后了，去看你的三角形，看看對特色和資源的影響；當有人談到可以增加什么功能特色時，你得立刻談起時間和資源，以顯得你思慮周
詳反應敏捷。所以，管理者的第一要務是把這個三角形放在心里，隨時利用這個模式來思考問題，你會發現答案都在這個三角形內。
法則二十九：
Don't know what you don't know 不懂別裝懂
法則三十：
Don't go dark 建立適當的檢查點
法則三十一：
Beware of a guy in a room 留心沒有檢查點的組員
法則三十二：
If you build it, it will ship 軟件要經常建構，就能順利推出
法則三十三：
Get a known state and stay there 掌握實際情況
法則三十四：
Use ZD milestones 零缺點里程碑
零缺點不代表軟件中沒有錯蟲，也不表示沒有遺漏的功能，而是指團隊的成品達到了事先規劃的品質水準，也經過測試驗證，就是零缺點里程碑。
法則三十五：
Nobody reaches the ZD milestone until everybody does 所有組員一起到達零缺點里程碑
法則三十六：
Every milestone deserves a no-blame postmortem 完成每個里程碑后，心平氣和地檢討
法則三十七：
Stick to both the letter and the spirit of the milestones 把握里程碑的實質意義與精神
法則三十八：
Get a handle on "normal" 培養正常的團隊運作
法則三十九：
A handful of milestones is a handful 里程碑不宜太多，才好掌握
法則四十：
Every little milestone has a meaning (story) all its own 每一個里程碑應有專屬的宗旨
法則四十一：
Look for the natural milestones 尋找自然出現的里程碑
以下是六種自然出現的里程碑：
1. 產品設計趨于穩定。
2. 中間產品被明確定義。
3. 團隊真正了解要花多少時間和努力才能完成目標（通常這會發生很多次，而且多半是進度落后的時候）。
4. 產品設計被刪減，或是資源增加，或是進度延誤，
或是三者同時發生。
5. 開發活動停止。
6. 產品進入除錯或穩定階段。
法則四十二：
When you slip, don't fall 如果滑了一跤，別就此倒地不起
- 進度落后與道德無關，請切記！
- 不要隱瞞事實。
- 化阻力為助力，利用進度落后來激發效率。
進度落后不是問題，被進度落后嚇倒才是問題。進度落后并不代表產品的難度太高而無法開發。但是如果進度已經落后卻未被察覺，那表示組員們不思考、不觀察、不討論，此時組織可說是瀕臨瓦解了。
善用你的遲延，這是最能看出你領導能力的時候，此時也是組員最脆弱也最需要你的時候，在這個時候組員最能把你的話聽進去，此時組員的學習能力最強。如果你在辦公室內激動得大喊大叫，指天罵地，那就錯失了贏得組員的心的大好機會。你必須說：“O K，進度落后了，讓我們來看看問題出在那里？??今天下午五點在會議室，我們要檢討每一個細節，問題一定要設法解決！”當組員了解到你不是企圖卸責或算帳，而是真誠地想解決問題，就會樂意把一切開誠布公地攤開來談，大家一起研究問題，從各種角度去設法克服問題。“進度落后”反而變成大家寶貴的成長經驗。
法則四十三：
Don't trade a bad date for an equally bad date 不要因為進度落后而更改最后期限
進度落后的程度是與計劃的不確定性成正比。
法則四十四：
After a slip, hit the next milestone, no matter what延誤了這個里程碑，就一定要如期到達下一個里程碑
我們必須明白，每一次的延誤，就是你和團隊信心的一次受挫，所以，延誤這個里程碑時，最好的補救辦法就是無論如何絕不延誤下一個里程碑。團隊必須挽回對自己的信心和對理想的承諾；因此，下一個任務必須準時完成的意義更重大，團隊需要重建信心。
法則四十五：
A good slip is a net positive 把延誤當作寶貴的學習機會
法則四十六：
See the forest 見樹亦見林
如果本項目有六個模塊，各有9 0 %的部分已經完成，那么你已經完成了5 4 %。每個模塊完成了九成，聽起來是個挺不錯的成績，但不能當成整個項目完成了百分之九十，它們之間不是相加的關系。你必須“見樹亦見林”。如果任何一個模塊完成比率是零，那么整個項目的完成率也是零。
法則四十七：
The world changes, so should you 世界在變，所以你也得跟著改變
雖然你想做些改變，你未必有勇氣實行。
偉大的軟件必定只有一個中心思想，至于品質能夠實現到什么程度，依賴領導者能否帶領團隊融合無數個小而重要的改變。如果你能在混亂中辨識出對項目最有意義的改變，并且引導團隊去適應它，將它融入團隊的精神中，將來就會在產品中表現出這項改變，呈現在顧客眼前。
法則四十八：
Violate at least one sacred cow 關懷多于要求
法則四十九：
Beta is not the time to change Beta測試版不是修改功能的時候
法則五十：
The Beta is for spin development Beta測試是暖身活動
法則五十一：
Triage ruthlessly 急救術
法則五十二：
Don't shake the Jell-0 小心保持軟件的穩定
法則五十三：
Compete with the superior story 偉大的軟件應該有一個偉大的故事
法則五十四：
Create a winning image 建立贏家形象
客戶虐我千百遍，我待客戶如初戀！