一. 偉大的軟體開發
1.偉大軟體開發的秘密在於時時執行開發循環。因為客戶總是會改變他們的心意
2.每個開發循環都包含：
（1）需求
（2）設計
（3）撰碼
（4）測試
3.只要你具有可以跟客戶討論的軟體片段，就可以開始執行開發循環。通常是 20 個工作天或 30 個日曆天
4.有效的建置版本匯兌團隊的生產力形成重大的影響，因為你不必在進行自己的任務之前還得先去修正別人的程式碼
5.你應將問題分解成較小的功能區塊，每個區塊都可以獨立展示給客戶看，而不要一次建造好整個網站
6.若某個開發循環的最後一項功能會讓整個開發循環的時間超過一個月以上，則應考慮將此功能移到下一個開發循環。愈長的開發循環，會導致愈大的風險
7.當某功能依賴另一項功能時，試著將這些功能組織在一起，確認它們被安排在同一個循環中，即使那表示你必須在高優先性功能之前先做一些低優先性的功能，也是無妨
8.一旦需求有變更，你應：
（1）估計新功能會花多少時間
（2）讓客戶為這些新功能決定優先性，並讓他檢視其他尚未實作的功能，比較相對的優先性
（3）重新修訂你的開發循環計畫
（4）檢查專案的最後期限
二. 收集需求
1.進行腦力激盪時，應盡可能讓每個人的職務、頭銜及種種包袱遠離，讓每個人都有平等的發言權，確保所有人（包含客戶）完全投入腦力激盪的過程
2.假如讓所有人共聚一堂的成效不彰，就讓每個人先自行腦力激盪，再讓大家聚在一起，將眾人的想法放在白板上，接著再一起進行腦力激盪。
有時候，可以先散會，反芻會議上所發生的事，再回來進行第二個會議
3.找出人們真正在做的事：
（1）角色扮演: 假如客戶覺得很難將軟體的運作具象化，就將它演出來。假裝自己是軟體，而客戶企圖指示你做他們要你做的事，接著，將軟體必須做的每一件事寫到一張需求卡片上
（2）觀察: 藉由多個觀察者多次觀察同一個互動，才能避免只捕捉到某人對某件事的單一印象。可以的話，讓每個人在不同的場合中進行觀察。此外，盡量不要讓你的觀察影響到使用者
＊需求卡片包含標題、敘述、估計天數、優先性
4.需求應該以顧客的語言、站在顧客的觀點與立場撰寫而成，並且讀起來就像一段使用情節
使用情節應該：
（1）描述軟體必須為客戶做的「一件事」
（2）以「客戶瞭解」的語言撰寫而成
（3）源自於「客戶」。這表示由客戶驅動，不管是誰將它記錄在卡片上
（4）「簡明扼要」，盡量不超過 3 個句子。假如使用情節太長，應該試著將它分解成多個較小的使用情節
不應該：
（1）長篇大論
（2）使用客戶不熟悉的術語
（3）提到特定技術
＊在撰寫使用情節時，若是發現有一些技術性的決策可以加進來，則應將這些想法記錄在另一組卡片上（以「標題」交叉參考），當你在準備撰碼工作時就可以拿出來。不要把這些技術性決策寫在使用情節裡
5.要計算出估計值，去除假設是最重要的活動，任何殘存下來的假設都會變成風險。計算時應確認你的估計是針對「整個」使用情節，而不只是一部分
不同估計之間的差異愈大，表示當中有誤解，就必須消除愈多的假設
6.完成使用情節所估計的天數不應超過 15 天。一旦超過 15 天，你應再跟客戶溝通一次，或是將使用情節分解成較小、較容易估計的使用情節。任何在標題或敘述中具有「以及 / 並且」的使用情節都可能可以被分解
7.當你對於特定情況下軟體應該做什麼有疑問，或者有假設被發現時，跟客戶接觸就非常重要；當你發現團隊做的是技術性的假設，不需要跟客戶做澄清，就不用去打擾他們
三. 專案規劃
1.在進行使用情節優先性的排列時，你必須以客戶為焦點。當論及使用情節的「取捨」時，你可以提供一些專業上的協助，然而，最終決定權還是在客戶的手上
2.當客戶按優先順序排列玩使用情節後，接著讓客戶選出一組要在軟體的第一版(Milestone 1.0)中交付的功能。在這個階段，你只需要問客戶哪些是最重要的使用情節，先不要卡在哪些使用情節會花多少時間
3.建置 Milestone 1.0 時，若功能太多，應：
（1）重新排定優先順序或砍掉更多功能
（2）盡早交付 1.0 建置版本
（3）把焦點放在運作基本功能上
4.保持你的軟體持續不斷地在建置，並且總是可以執行，你才能總是在開發循環結束時得到客戶的回饋
5.開發循環應保持簡短，愈短能讓你愈早得到客戶的回饋，以及額外的細節，也更能讓你的團隊集中注意力並且士氣高昂
6.每個開發循環都應該在處理變更、增加新功能、消除臭蟲、與人力運用的實際狀況之間維持平衡。每個開發循環不應超過20 個工作天（30 個日曆天）
7.折減率（velocity） = 「實際投入的工作天 / 理想可用的工作天」或「理想所需的工作天 / 實際完成的工作天」
＊第一個開發循環中的折減率通常從 0.7 開始
8.一頭埋入開發循環前先處理折減率。首先，將團隊的人數乘上開發循環的工作天，再乘上團隊的折減率，即可得知一個開發環中可產出多少人天（person-day）的實際工作量，最後，再將所有開發循環的實際工作量加起來，即可得知整個 Milestone 的實際工作量
9.萬一有些需求無法在 Milestone 1.0 達成，你可以：
（1）為 Milestone 1.0 再增加一個開發循環
（2）解釋超出範圍的工作不會被棄置不管，只是要被遞延到後面
（3）將你的想法、估計過程解釋給客戶聽。另外，告訴客戶你「想要」交付給他們成功的軟體，而這正是為什麼你得捨棄一些功能，才能得到一個有信心成功交付的計畫
10.一旦為 Milestone 1.0 找出一組大家同意並且可以達成的使用情節，就開始設置你的大看板（Big Board，包含使用情節、＂實際正在＂「進行中」的任務、「已完成」的任務、Burn Down），進行開發工作
11.Burn Down Chart 圖形中，X軸為「剩餘的天數」，Y軸為「剩餘的工作」
四. 使用情節與任務
1.使用情節是給使用者看的；任務則是由「一個」開發者完成的工作片段，以便建構使用情節的一部分。每個任務都有一個「標題」方便你參照它、一個「描述」大略說明如何開發此任務的細節、一個「估計」與「優先性」
2.在估計活動的「一開始」就從使用情節分解出任務往往是最好的，因為「任務估計」總是最可靠的
3.理想的任務估計應維持在 1/2 到 5 天
4.同時進行兩項工作的基本原則：
（1）特別注意彼此相關連的任務，或者至少要把焦點擺在軟體中共同的部分
（2）試著不要讓任務具有太大的估計值
5.每日的 Stand-Up 會議應該激勵每個人，並且：
（1）追蹤記錄進度
（2）更新 Burn Down Rate
（3）更新任務
（4）討論一下昨天發生的事，以及今天即將發生的事
（5）將任何議題提出
（6）進行時間約 5 到 15 分鐘
6,Stand-Up 會議應盡量安排在每日的早晨，且最好是固定時間、固定地點開會。應把焦點與注意力集中在：
（1）有任何問題嗎？
（2）完成了什麼事？
7.一旦出現了未計畫的任務，應以紅色的便利貼記錄，與一般的任務區隔開來
8.大看板一次只捕捉一個開發循環
9.若有人一直錯估工作所需花費的時間，你們應試著在估計期間處理掉不良的估計，並且記住，估計是整個團隊的事，試著提醒大家，不是在為自己做估計，而是為團隊的「平均」開發者做估計
假如還是不能解決這個問題，試著記錄任務被移到「進行中」區段的日期，然後記錄任務被完成的日期，在開發循環結束時，使用該項資訊來校準你的估計，記住，這不是為了讓任何人難堪，而是為了從頭校準你的估計
五. 「夠好」的設計
1.遵守單一責任原則（SRP）：系統裡的每一個物件都應該具有單一責任，物件的所有服務都應該聚焦在實現此單一任務
2.SRP 分析：
（1）寫下 The「空格」「空格」itself
（2）在每一行的第一個空格裡寫下「類別名稱」；第二個空格裡寫下「類別的方法之一（包含參數）」
3.遵守不自我重複原則（DRY）：透過將共同之物抽取出來，置於單一處，避免程式碼重複
4.DRY 關乎將一個功能片段放在單一地方，像是一個類別；SRP 關乎確認一個類別只做一件事，而且把事情做好，此外，也沒有其他類別共同分擔這項行為
5.在估計任務所需的時間時，所牽涉到的不只是撰碼，還包含 demo 或者與利害關係人開會等時間
六. 版本控制
1.版本控制又稱組態管理（CM），是用來記錄檔案的變更，並且幫助你協調多名開發者同時對系統各個部分進行作業
2.已釋出版本的臭蟲對客戶的優先性通常比實作新功能還要高
3.主幹是當前開發工作進行的地方，它代表軟體的最新版本；標籤是貼附到儲存庫裡特定修訂版的名稱，好讓你能夠在稍後輕易地將它們擷取出來；分支是你能夠對它做改變的程式碼複本，而且不會影響到主幹上的程式碼。分支往往從被標上標籤的程式碼版本開始發展
4.標籤只是程式碼的快照，你應該總是將改變 commit 到 分支，而非標籤
5.「標籤是靜態的」－你不會將改變 commit 給它們，分支是「你不想要放在主幹中的改變」（或者讓程式碼不受主幹中的改變所影響）
6.當你真正要釋出包含修補的 Version 1.1 時，要記得在 tags 目錄中建立 version 1.1 的標籤，以便在以後需要時可以參照回來
7.該進行分支的情況：
（1）你已經釋出需要在「主要開發循環以外」進行維護的軟體版本
（2）你想要嘗試將一些重大改變放到程式碼中，而這些改變也有可能被放棄掉，你想要在作業期間「不要對其他團隊成員造成影響」
8.不該進行分支的情況
（1）可以透過將程式碼「分解到不同的檔案或程式庫」（可在不同平台上適當地建置）而達成你的目標
（2）有一群開發者無法讓他們的程式碼在主幹中編譯，因此，你試圖分別為他們「提供他們自己的沙箱（sandbox）」以進行作業
9.充分地使用標籤記錄專案的重要里程碑（開發循環的結束、版本釋出、臭蟲修正等）。假如有可能需要知道改變前的程式碼，就為你的程式碼版本貼上標籤
10.使用分支維護程式碼的獨立複本，但只有在絕對必要時才做分支
11.應經常將改變 commit 到儲存庫，但小心不要破壞別人的程式碼
12.利用建置工具與建置指令稿，建置軟體、打包、測試、及佈署你的應用程式
13.確認你有建立某種方式「清理」指令稿所產生的任何檔案
14.建置工具是為「團隊」服務的，而不只是為你。選擇適合所有團隊成員的建置工具
15.建置指令稿「也是程式碼」，應該被 Check in 到儲存庫，做好版本控制
16.Ant 是 Java 專案的建置工具，將建置資訊捕捉在名為 build.xml中
七. 測試與持續性整合
1.黑箱測試（從使用者的觀點）應尋求：
（1）功能性: 檢查資料是否如使用情節所描述般地被輸入，並且得到使用情節所說的結果
（2）使用者輸入驗證: 刻意輸入錯誤的輸入值(例如餵給系統 -1 的日期)，測試結果為何
（3）輸出結果: 手動檢查系統所傳回的數值，確保所有的功能路徑(function path)都被測試過(例如使用者輸入無效的目的地位址，接著點擊「取得路徑規劃」...)。組織一張表格顯示你能夠餵給系統的各種輸入，以及你所預期的結果，會對這項工作很有幫助
（4）狀態移轉(state transition): 有些系統必須根據一組特定規則，從一種狀態移轉到另一種狀態，這類似於「輸出結果」，但關係到確保你的系統如預期般地從一種狀態移轉到另一種狀態。準備一張對映表，記錄狀態以及經過什麼動作會讓它移轉到另一種狀態，也會很有幫助
（5）邊界案例(boundary case)與差一錯誤(off-by-one): 你應該以稍微超出邊界一點點的值來測試系統(例如檢查月份值 13)，會讓你知道是否把邊界情況弄對，或者某個開發者是否忘了陣列索引是從 0 開始
＊聚焦在輸入與輸出
2.灰箱測試（從測試者的觀點）應尋求；
（1）驗證稽核與紀錄
（2）供其他系統使用的資料
（3）系統所增加的資訊: 確保系統所產生的時間戳記在正確的時區中被建立，並且伴隨著正確的資料被存放
（4）意外被留下的殘餘資料
3.白箱測試（從開發者的觀點）應尋求：
（1）測試程式碼的所有邏輯分支: 你應檢視「所有」的程式碼，你可以檢查一下所有的 if/else 與 switch/case 陳述式，看看需要輸入什麼資料才能夠讓你正在檢視的類別執行到每一個邏輯分支
（2）妥善的錯誤處理: 假如你將無效資料餵進方法中，會得到適當的錯誤嗎？你的程式碼在使用資源之後是否適切地釋放它們？
（3）如文件說明所說的那樣運作
（4）適切處理資源受限的情況: 假如方法無法取得所需要的資源，程式碼會做什麼事？這些問題被優雅地處理嗎？你能夠撰寫程式強制程式碼面對這類的問題狀況嗎？
4.測試包含：
（1）建立測試組
（2）使用一個命令執行所有測試: 不要只針對新增的程式碼進行測試，還要執行所有既存的測試
5.讓測試所需花費的時間盡量縮短。測試組花費的執行時間愈長，就可能愈不常被執行
6.JUnit 可自動化執行測試
7.持續性整合（CI）將版本控制、編譯、與測試包裹在可重複執行的單一流程裡
8.持續性整合工具可在你 check in 程式碼時執行你的測試
9.CruiseControl 可掌控 CI
10.你的程式碼直到通過測試才算完成
11.訂定測試涵蓋度的目標應循序漸進。先將目標訂在 10%，當你達成時，再提升到 15%，以此類推
12.良好的測試的測試程式碼與產品程式碼的比例約 2 比 1 或 3 比 1
13.確認持續性整合的建置結果與涵蓋度報告「對整個團隊公開」，讓團隊對專案覺得有責任感
14.假如自動化測試失敗，持續性整合工具的建置工作應該也要跟著「失敗」，接著，「寄送電子郵件」通知 commit 錯誤程式碼的人，直到完成修復為止
八. 測試驅動開發
1.測試驅動開發（TDD）：先撰寫測試，再撰寫產品程式碼。TDD 全然關乎為「特定」功能建立測試，接著才撰寫程式碼滿足該功能
2.撰寫測試的第一步是判斷「應該測試什麼」。你應該從小處著手，進行「單元測試」
3.在 TDD 中，最初撰寫測試時，你應該先讓它失敗，測試的重點在於建立「可量測的成功」。先建立 OrderInformation 類別開始
4.TDD 規則：
（1）實作任何產品程式碼之前，你的測試應該總是失敗
（2）實作讓測試通過的「最簡單」程式碼
5.TDD 的循環：測試失敗 -> 測試通過 -> 重構
6.測試的好習慣：
（1）每個測試應該只驗證一件事
（2）避免重複的測試程式碼
（3）將測試保存在原始碼的鏡像目錄(Mirror Derictory)
7.Mock Object 框架會處理介面實作的建立，並且記錄應該被呼叫的方法、當它們被呼叫時應該傳回什麼、以及什麼不應該被呼叫等。它針對我們的的介面所產生的實作會記錄這一切，並且在某事不能按照給定計畫進行時丟出例外
藉由 replay()，你告訴 Mock Object 你已經描述完即將發生的事。一旦呼叫 replay()，它會驗證在那之後所得到的任何方法呼叫，假如它得到它沒有預期的呼叫、以不同順序、或者以不同引述，就會丟出例外
九. 結束開發循環
1.你應該盡量用「不同組人馬」來進行系統測試，至少，不要讓開發者對自己的程式碼做黑箱測試，因為他們對自己的程式碼太過瞭解以致無法客觀看待
2.開發循環是團隊必須對系統做改變的固定時間量，團隊需要時間完成工作，而不應該在開發循環期間擔心程式碼要放進哪個建置版本
3.系統必須在每個開發循環結束時才能夠被用來進行系統測試
4.良好的系統測試需要兩組獨立循環：
開發團隊: 開發循環1（交付「循環1」的建置版本，並進入「開發循環2」）-> 開發循環2（交付「循環2」的建置版本，並進入「開發循環3」）-> 開發循環3（交付「循環3」的建置版本）
測試團隊: 準備「循環1」（熟習相關的使用情節、將測試環境設置好等）-> 測試「循環1」的建置版本（將臭蟲報告送回，並併到「開發循環3」中）-> 測試「循環2」的建置版本（將臭蟲報告送回，並併到「臭蟲修復」中）-> 測試「循環3」的建置版本（在此，測試團隊同意可運作的軟體版本、里程碑、或釋出版本）
＊處理臭蟲時，你可以每個禮拜切割出一部分時間，專門用來修正臭蟲。當你在做開發循環規劃時，要將這段時間從有效工作時間中排開來，因此，你不用擔心它會影響到你的折減率
5.當你一想到某事可能改變時（如功能性有變動），馬上進行溝通，確保測試者知道某些討論正在進行，某些領域很可能會被重新檢討，舉行一個正式的會議，說明新功能、要修復的臭蟲、以及已知的議題。尤其是要特別針對「流程如何運作」充分做溝通，確認測試團隊瞭解「改變預期會發生」
6.有效系統測試的特點：
（1）客戶、開發團隊、與測試團隊之間「良好且頻繁的溝通」
（2）「知道系統的開始與結束狀態」。確認你從一組已知的測試資料開始，而那些資料最後會在測試結束時像你所預期的那樣
（3）「文件化你的測試」。別依賴某個熟知系統內外狀況的超級測試者，並且不要總是由他來回答問題。捕捉住每個測試者在做什麼，並且在每一輪系統的測試中做相同的事(伴隨著新增的測試)
（4）「建立清楚的判斷標準」。系統何時才算夠好？什麼叫「完成」？
（5）盡可能自動化你的測試
（6）開發團隊與測試團隊之間協同合作的動力
（7）「測試團隊對整體圖像的良好觀點」。確認你的測試者瞭解系統整體，以及整個片段如何協同運作
（8）「精確的系統文件說明」(使用情節、使用案例、需求文件、操作手冊等)。除了測試文件以外，你應該捕捉開發循環期間所發生的細微改變，特別是不同開發循環之間的改變
7.記錄與修正臭蟲的步驟：測試者找到臭蟲（臭蟲不必然是明顯發生的事，也可以是文件說明中模糊不清之處、漏掉的功能、或者網站風格規範的違反）-> 測試者提出臭蟲報告（你必須「記錄臭蟲」。總是要記錄你試圖做的事情，最好能附上重新產生此臭蟲的步驟、任何錯誤訊息、臭蟲發生前所做的事、以及原本預期發生的事）-> 建立臭蟲的使用情節與任務（你可以使用臭蟲記錄器(bug tracker)跟「客戶」一起針對「哪些臭蟲需要先被解決」進行優先性排定，並且不為「不打算在當前開發環境中修復的臭蟲」建立使用情節與任務）-> 修正臭蟲（一旦開發團隊修正臭蟲，就在臭蟲記錄器中將它標示為「已修復」）-> 檢查修復結果，驗證它確實有效（測試者驗證新的建置版本，確認對修復結果感到滿意後，就將臭蟲標示為「已關閉」或「已驗證」）-> 更新臭蟲報告（更新的報告可被作為重新測試的參考。不要刪除它，因為你不知道何時需要回頭參照它）
8.臭蟲記錄器軟體（如 Bugzilla 或 Mantis）的使用不應該只記下臭蟲，還應：
（1）記錄及溝通優先性。挑選一個優先性層級，該優先性層級的所有臭蟲會被轉化成使用情節，並且跟開發循環的其他事情一起進行優先性排定
（2）記錄每一件事。記錄討論、測試、程式碼修改、驗證、與臭蟲有關的決策歷程。藉由追蹤記錄每一件事，整個團隊知道臭蟲的進展狀況、如何修正、或者原開發者認為要怎麼修正它
（3）產生統計數據
9.良好的臭蟲報告應該具備：
（1）總結
（2）重新產生臭蟲的步驟
（3）預期會發生什麼以及實際發生什麼
（4）版本、平台及地區與語言資訊
（5）嚴重性與優先性
10.準備一組可以在每個開發循環結束時檢查的標準回顧問題，假如有人想要增加問題，或者某個問題真的不適用於你的專案時，這組問題是可以改變的。擁有一些可反覆討論的主題表示人們會預期問題並且預做準備（甚至在開發循環期間也會不自覺地想到這些問題）
11.開發循環的回顧問題：
（1）每個人對工作、文件說明、與測試的品質都滿意嗎？
（2）每個人對開發循環的步調感覺如何？
（3）每個人對他所負責的區域都感到很自在嗎？
（4）有什麼工具對生產力特別有幫助或者有損傷？
（5）流程有效嗎？有進行什麼審查嗎？有效嗎？有什麼流程上的變更要考慮嗎？
（6）有任何程式碼被識別出需要重新檢視、重構、或重寫嗎？
（7）有任何效能問題被識別出來嗎？
（8）有什麼臭蟲被識別出來要優先討論嗎？
（9）測試有效嗎？我們的測試涵蓋度夠嗎？每個人對系統感到有信心嗎？
（10）系統的佈署(deployment)在控制中嗎？可重複進行嗎？
12.假如開發循環中還有一些額外時間，你可以：
（1）修正臭蟲(這裡指的是在開發當前使用情節之外找到的臭蟲)。記得要跟客戶一同排定優先性
（2）提前進行下一個開發循環的使用情節。要小心客戶對這個使用情節的優先性或想法可能會改變，另外，最好也要知道測試團隊是否有時間測試你所增加的使用情節
（3）為下一個開發循環提供原型解決方案(prototype solution)。假如你對下一個開發循環可能出現的東西具有某種想法，或許想要利用額外的時間先行探索，你可以試著撰寫一些原型程式碼，或者研究一下可能會想要使用的測試技術或程式庫，你可能不會將這些程式碼 commit 到儲存庫，但你可以為下一個開發循環打算使用的東西先取得一些經驗
（4）訓練或學習時間
（5）為可能出現的新使用情節進行腦力激盪
＊萬一將之前額外的使用情節拉到當前的開發循環中，而即將超過時間，你只需將該使用情節放回下一個開發循環即可，而不是把半成品、未經測試的程式碼 commit 到儲存庫裡
假如在開發循環的尾端有一些額外的時間，你可以在即將放入任何額外的東西到儲存庫之前，先為程式碼貼上標籤，如此一來，若事情進行得不順遂，就可以利用該標籤，釋出穩定的建置版本
＊不要貪圖完成下一個開發循環的低優先性簡單功能，或者做一點點沒什麼用處的重構工作，你才剛剛把事情搞定，別又把事情搞砸了
十. 下一個開發循環
1.當你正在準備下一個開發循環時，總是要「跟客戶一起檢查」，並和他們「重新排定使用情節的優先性」，確保你所計畫的工作正是他們想要完成的工作
2.為每一個開發循環重新修訂你的估計與折減率，將你從上一個開發循環中所學到的東西應用到當前的開發循環
3.決定利用第三方程式碼時要小心，當你這麼做時，你正假設該程式碼能夠有效運作。除非你已經看到它能成功執行，或者針對它執行過你自己的測試，否則「不要相信任何人」
4.你得對你的軟體負責，當中有問題的程式碼無論是不是你撰寫的，臭蟲就是臭蟲，你要對即將交付的軟體負起「所有」責任
5.切勿假設其他人會遵循你們的流程，對別人所開發的每一行程式碼要抱持著懷疑的態度，直到你測試過它
十一. 臭蟲
1.做任何改變（包括臭蟲修復）之前，要先將程式碼納入版本控制並且建置成功，充分掌握它的「所有權」
2.焦點在於功能性，只需要修正使用情節所依賴的程式碼
3.一切根據「客戶導向的功能性」而演進
4.雖然美麗的程式碼很棒，但符合功能性、測試過、具可讀性、準時交付的程式碼總是比它還重要
5.Spike Testing：在一段時間內試著解決一部分問題（從失敗的測試中隨機採樣），看看你完成了什麼，再利用它來推斷要花多少時間才能完成其他事
＊修復的臭蟲 / Spike Testing 進行的天數（理想是五天，每個人五天） = 臭蟲修復速率
6.誠實面對客戶，特別是有壞消息出現時
7.有效運作的軟體是你的第一要務；可讀可瞭解的程式碼是你的第二要務；最後才是美麗的程式碼
十二. 真實世界
1.除非情勢緊急，否則別在開發循環途中做流程的改變，無論它被規劃得有多好。好的開發循環總是短的。假如必須改變你的流程，就「等到當前的開發循環結束」
2.任何流程改變的決策都應該出現兩次：一次「決定是否要做」，一次「評估是否有效」
3.發展統計數據，以判斷你的改變是否有幫助
4.避免在多個地方記錄需求，那會導致維護工作變得複雜
沒有留言:
張貼留言