程式碼之道

第1部分 (第3/4頁)

的產品功能。這些人的工作仍然彙報給各自的工種經理。有些功能團隊選擇敏捷方法，有些喜歡精益模型，有些採用傳統的軟體工程模型，有些則根據實際情況混合了上述多種方法。

微軟怎麼能包容所有這些多樣性和產品的區域自治、還能為朝著一個共同的目標有效地工作呢？這就要靠產品線公共的專案協調了。舉例來說，產品線的價值主張為所有的產品單元和他們的功能團隊設定並統一關鍵應用範例、質量尺度和框架體系。

為了促進跨部門和產品線的協調和共享，特別是為提高質量和效率，微軟還設立了一個組織叫Microsoft　Trustworthy　puting　and　Excellence。它是我的上級組織。具體來說，我的工作職責是，要讓微軟全球超過1萬名的開發者在構建令人興奮的、高質量的使用者體驗時，能夠做得更加開心、更富有效力。不用說，這是一項長期的工作。

獻給當初對我說“為什麼不由你來寫？”的人：Bill　Bowlus（3）

我的團隊每月將開發部門的領導層聚集在一起，談論問題並指導我們的工作。我們研究公司範圍內乃至整個行業內的工程方法，以期找到新的機會和領域去提高。我們透過網路共享工具、最佳實務，以及實施職業生涯指導。我們舉辦各種活動和獎項評比，與各種團隊商討，為開發中的各個級別、各種角色提供技術培訓。非常棒的工作！另外，我每月還在寫著觀點欄。

示範工具和文件

本書提到的示範工具和文件，作為本書的附屬內容，都可以透過如下地址下載到：

線上資料列表

工具 欄目 章節

Sprint　backlog：　；

敏捷子彈 2

Product　backlog：　；

敏捷子彈 2

Spec　template：　Spec　 糟糕的規範書：該指責誰？ 3

Spec　checklist：　Spec　 糟糕的規範書：該指責誰？ 3

Pugh　Concept　Selection：；

複審一下這個 5

Inspection　Worksheet：　；　 複審一下這個 5

Interview　Role　Playing；　a　how…to　guide：

面試流程之外 9

本書的支援

為了保證本書及其附屬內容的準確無誤，我們盡了最大的努力。本書所有的修正和改動都會蒐集起來並放到微軟的知識庫中去。微軟出版社透過如下站點對本書及其附屬內容提供支援：。

問題和意見

如果你對本書及其附屬內容有任何意見、建議或問題，並且透過訪問上述站點仍然無法解決，請給微軟出版社傳送電子郵件：　mspinput@，或者按照如下方式郵寄：

Microsoft　Press

Attn：　I。　M。　Wright’s　“Hard　Code”　Editor

One　Microsoft　Way

Redmond；　WA　98052…6399

請注意，上面的地址對微軟的軟體產品不提供支援。

書包　網　。　想看書來

讀者對I。　M。　Wright’s　“Hard　Code”欄目的喝彩

任何大型組織都有危險成為自身文化的犧牲品。關於世界應該是什麼樣子或者事情應該怎樣去做的神話，最後證明都是一個個自圓其說的預言。任何組織都會有這種傾向，但它對於需要不斷創新才能繁榮的技術公司來說，卻是個致命殺手。Eric　Brechner做了件難以置信的事——他亮出了手術刀，深深地切入了組織內部看似無關緊要的東西。他毫不吝嗇地打出了重拳——偶爾也會故意玷汙自己的名聲。儘管有一些隱語和例子對於微軟內部的員工更有吸引力，但他的智慧和至理名言，大都可以成為整個軟體行業的財富。

——Clemens　Szyperski，首要架構師

“I。　M。　Wright”寫的關於開發時間表的文章真的是太棒了！它在我所屬部門參與的基礎設施專案上同樣適用。

——Ian　Puttergill，部門經理

你沒有受到任何死亡威