軟體研發之道:微軟開發團隊的經驗法則
目 錄
開局階段 1
組織 1
質保人員是“少數民族”嗎 2
到底誰負責產品設計 2
經驗法則1 建立共同前景 3
經驗法則2 使大家主動投入 11
經驗法則3 制定多版本的技術計劃 13
經驗法則4 不要認為別人是笨蛋 17
死亡行軍 19
經驗法則5 蒐集情報 22
經驗法則6 注意團隊成員組成的比例 24
經驗法則7 組建功能監督小組 25
經驗法則8 專案經理的重要性 32
團隊精神 33
經驗法則9 做權威,而非掌權者 35
競爭 38
人類學簡介 38
軟體競爭 40
經驗法則10 缺乏競爭對手?未必是好事 41
經驗法則11 與競爭對手不相上下?進行功能競賽 43
經驗法則12 落後於競爭對手?更頻繁地推出新版本 43
經驗法則13 領先於競爭對手?絕不放鬆 46
經驗法則14 緊跟潮流 46
客戶 48
簡單的購買模型 50
經驗法則15 讓客戶驚喜 51
經驗法則16 找到靶心 52
經驗法則17 與客戶建立良好的關係,而不只是生意往來 54
經驗法則18 加快產品週期 55
設計 57
經驗法則19 追求偉大 57
經驗法則20 確定主題 58
經驗法則21 將依賴減至最少 60
經驗法則22 平息客戶的抱怨 60
經驗法則23 軟體的可移植性 62
經驗法則24 在設計階段考慮時間因素 62
開發 62
經驗法則25 拒絕錯誤指示 64
經驗法則26 以遊戲的心情開發軟體 67
中期階段 68
經驗法則27 像醫生一樣 68
經驗法則28 記住軟體開發金三角:功能、資源和時間 70
經驗法則29 不要不懂裝懂 71
經驗法則30 提交中間產品 74
經驗法則31 小心“閉門造車型”開發人員 79
經驗法則32 經常、定期構建軟體產品 82
經驗法則33 始終完全瞭解產品的狀態 84
掌握進度 86
經驗法則34 利用零缺點裡程碑 86
經驗法則35 帶領全體成員到達零缺點裡程碑 88
經驗法則36 完成每個里程碑後進行事後總結,但不要指責 88
經驗法則37 把握里程碑的字面意義與精神 89
經驗法則38 掌握什麼是“正常的” 90
經驗法則39 里程碑的合理數目 94
經驗法則40 每一個小的里程碑都有專屬的意義(故事) 94
經驗法則41 尋找自然出現的里程碑 95
經驗法則42 雖落後,別趴下 99
經驗法則43 不要落後多久就把原定日期延後多久 108
經驗法則44 延誤了這個里程碑,一定要按時到達下一個里程碑 109
經驗法則45 從延誤中學習經驗教訓 109
經驗法則46 要有全域性觀 110
經驗法則47 與時俱進 110
推出階段 112
推出階段:啟動 112
推出階段:移交 113
推出階段:收尾 114
經驗法則48 關懷多於要求 115
經驗法則49 Beta版不是修改產品的時候 116
經驗法則50 利用Beta測試來調整宣傳策略 116
經驗法則51 嚴格執行類選法 116
經驗法則52 小心保持軟體的穩定 118
釋出階段 119
經驗法則53 偉大的軟體應該有一個偉大的故事 120
經驗法則54 建立贏家形象 123
結束語 124
附錄:聘用和留住人才 125
僱用聰明的人 125
適才適任 126
賽馬必須奔跑 127
好高騖遠者需要你的推動 128
軟體開發領先者資源的不完全清單 132
新的經驗法則 134
經驗法則55 做完美的老闆 134
經驗法則56 老闆就是你最重要的客戶 136
一種更好的方式 136
在如何看待老闆上的轉變 137
經驗法則57 支付“lumber tax”和下alpha賭注 139
Alpha(或Alpha能量) 139
The Core System V. 3.0的元素 142
形成共同前景的4個步驟 143
第1部分:“簽到”的元素 143
第2部分:決策過程的元素 145
第3部分:校正的元素 147
第4部分:共同前景的元素 148
The Core Protocols V. 3.0 151
核心承諾 151
核心準則 152
放棄/取消放棄 152
簽到 152
離開 153
求助 154
準則檢查 155
目的檢查 155
決策過程 156
解決 157
完美行動 158
個人校正 159
調查 160
譯 者 序
本書是軟體工程領域的經典之作,它的第一版創作於1995年,到現在已經有15年曆史了,你現在看到的是它的第二版(2006版)。這一版包括3個部分,第一部分是原來第一版內容,第二部分介紹了人際關係準則和行為模式的系統,第三部分是作為多媒體補充的視訊資料 。值得注意的是,原來1995版內容大部分沒有做修改,因為這些思想經過10餘年的事實檢驗,被證明一直是正確的,作者對這部分內容只是增加了一些補充性的文字資訊,並指出了這些思想的後續發展。我想15年前的大部分軟體書籍可能都早已過時了吧,而這本書經過歲月的洗禮,依然熠熠生輝。雖然軟體領域瞬息萬變,技術革命的步伐也越來越快,但有些東西是永遠不變的,就像牛頓三大定律一樣。
把軟體工程理論與軟體開發實踐結合到一起,生產力就會呈幾何級增長。自從軟體工程成為一門正式的學科以來,人們對軟體工程理論的探索和研究就從未停止過,人們對於開發的認識也從單純逐步走向成熟,並對它進行科學的分析和研究,進而實現人們把軟體工程理論成功應用於軟體開發專案的理想。本書所介紹的很多思想,特別是第二部分中的思想,將會給軟體開發方式帶來一場革命,也將會把軟體開發推向一個全新的階段。和歷史上每一次超越的過程一樣,只有依靠嚴謹的科學理論和不斷的實踐,才能夠真正實現自我發展與超越,這也正是本書的主旨。
本書中有些經驗法則是我們所熟知的,但大部分人可能只是下意識地使用它們,而沒有形成一個清晰的認識,通過仔細閱讀本書,你可以系統地掌握它們。有些經驗法則則是我們以前從不知道的,例如有關人際競爭的alpha理論。這些新鮮的思想使我有所頓悟,相信讀者也會同樣受到啟發。
翻譯本書是一個巨大的挑戰,畢竟,要在短短數月之間讀懂作者多年職業生涯中在各個方面積累的思想、感悟和智慧並不容易。雖然我幾乎放棄了所有的週末和節假日休息時間,但仍然感覺時間緊張而且壓力巨大。這是一本博大精深的書,如果由於我的理解問題而致使沒有完整地表達出作者的深邃思想,那將是我最大的過錯和遺憾。因此,我全力以赴,盡最大努力保證翻譯的準確,但由於水平有限,在翻譯過程中難免會出現錯誤,懇請讀者批評指正。在此我必須感謝我的同事為我分擔了大量我份內的工作,使我能夠騰出更多時間來翻譯本書。最後感謝圖靈各位編輯所付出的努力,感謝他們在翻譯過程中給予的幫助和提出的寶貴意見。
相關文章
- 軟體研發之道——有關軟體的思考
- 軟體開發組的團隊精神 (一個程式設計師在IBM的開發經驗) (轉)程式設計師IBM
- 記憶體洩漏治理實戰:TDengine 研發團隊使用 Windbg 的經驗分享記憶體
- 軟體開發之道
- 軟體配置管理——團隊開發的基石
- 團隊開發_軟體專案風險管理
- 軟體開發團隊組織機構
- 軟體研發之道——智慧財產權
- 軟體開發與軟體研發
- Chromium團隊的安全開發核心準則
- 如何營造高效軟體開發團隊(轉)
- ocr文字識別軟體it外包公司專業團隊經驗豐富定製開發
- QCon 全球軟體開發大會 | 大型團隊研發效率持續改進實踐
- 軟體開發中團隊首領的好壞之分
- 讀軟體開發安全之道:概念、設計與實施02經典原則
- 分析如何使用專案管理軟體管理軟體開發團隊專案管理
- 產品研發團隊Scrum敏捷開發協作流程Scrum敏捷
- 軟體開發的22條法則 ——《程式設計師修煉之道》讀書筆記程式設計師筆記
- 案例:低迷的產品研發團隊
- 我的程式人生 (三)在百人團隊參與遊戲研發體驗遊戲
- 我的軟體開發中經驗教訓
- 軟體開發團隊主管易犯的10個錯誤
- Google極客談軟體開發團隊的不良行為Go
- 報表軟體it外包公司專業團隊經驗豐富成品原始碼二次開發原始碼
- 研發團隊如何實施OKROKR
- The Joel Test: 軟體開發成功 12 法則
- Linus 談軟體開發管理經驗
- 開發團隊的效率
- 微軟軟體研發策略轉變之路 從瀑布式走向敏捷開發微軟敏捷
- 軟體開發:需求分析的20條法則(收藏) (轉)
- 建立軟體開發團隊時要避免的7個問題
- 20+條軟體開發的經驗教訓
- Facebook、微信團隊、Twitter、微軟開源軟體列表一覽微軟
- 有機性整體:開發團隊
- Google+開發團隊分享的5個提升網頁生成速度的經驗Go網頁
- 揭祕亞馬遜雲科技軟體開發工程師團隊亞馬遜工程師
- VMware北京軟體定義網路團隊招聘容器開發
- 中小遊戲開發團隊如何保持創作力?<經驗篇>遊戲開發