深入淺出軟體開發
Head First Software Development
poker "撲"克牌? "樸"克牌?
1 偉大的軟體開發：讓客戶滿意
P.1
要是客戶不爽，大家都會不爽！
P.5
這也被稱為"人間蒸發"(Going Dark)開發法，客戶在專案一開始還能看到你，接著，你就不見蛋，深居簡出，埋頭苦幹，直到最後將軟體交付出來。
P.8
軟體開發不是猜猜看遊戲，你必須讓客戶保持在狀況內，確保你走在正軌上。
假如你不確定客戶要什麼(或甚至你"認為"你確定)，總是得回去問問看他們。
P.9
What is needed, On Time, and On Budget.
(客戶需要什麼？準時交付、符合預算。)
P.11
開發循環就像對軟體所做的經常性檢查，總是能夠知道你的實作現況。
P.12
不管團隊多大，專案時間多長，開發循環都是建造偉大軟體的關鍵之一。
P.14
開發循環: RDCT
每個開發循環都包含完整流程的所有階段(stage): 需求(Requirements)、設計(Design)、撰碼(Code)、測試(Test)。
P.22
以開發循環處理變更
01.估計新功能
02.讓客戶為這些新功能決定優先性
03.重新修訂你的開發循環計劃
04.檢查專案的最後期限
P.24
正確的軟體開發流程就是能夠幫助你開發及交付偉大軟體的流程，準時交付且符合預算。
P.26
開發技術
01.開發循環幫助你保持在正確的路線上。
02.當變更發生時，重新規劃及平衡你的開發循環。
03.每個開發循環都會產生有效運作的軟體，並且從客戶那裡收集到一些回饋。
開發原則
01.交付客戶需要的軟體。
02.準時地交付軟體。
03.符合預算地交付軟體。
要點提示
01.從每個循環所得到的回饋是確保軟體符合客戶需求的最佳工具。
02.開發循環是整個專案的縮影。
03.成功軟體不是憑空開發出來的，需要透過開發循環持續從客戶那裡得到回饋。
04.良好的軟體開發交付偉大的軟體，準時交付與符合預算。
05.交付可有效運作的部分功能總是強過交付不能正確運作的全部功能。
06.好的開發者開發軟體；偉大的開發者交付軟體！
2 收集需求：知道客戶要什麼
P.34
共築遠景(bluesky)
P.36
收集良好需求的方法很多，假如一個行不通，就再試試另一個。
P.37
找出人們真正在做的事：角色扮演(role playing)、觀察(observation)
P.39
需求必須是客戶導向的
使用情節是以客戶的觀點撰寫的，你跟客戶都應該瞭解它的意思是什麼。
P.41
利用客戶的回饋發展需求
01.捕捉基本想法
02.bluesky腦力激盪
03.建構使用情節
04.利用客戶的回饋找出漏洞，釐清細節
05.清楚的、以客戶為焦點的使用情節
P.43
"使用情節"定義專案要建造"什麼"，"估計"定義"何時"被建造
你的專案估計(estimate)是各項使用情節估計的總和
P.47
就計算值得相信的估計而言，去除假設是最重要的活動。
P.49
不同估計之間的差異越大，你對估計就越沒有信心，就必須消除越多的假設。
P.51
雖然無法總是去除掉所有的假設，估計期間的目標是：透過與客戶澄清那些假設，盡可能消除它們。任何殘存下來的假設都會變成風險。
P.53
不要對你的假設做假設....一切都可以討論。
P.54
大而不當的使用情節估計
超過15天的使用情節估計恐怕會藏污納垢。
當估計值太長時，運用AND規則將使用情節分解成較小的片段。
理想上，整個開發循環應該大約一個日曆月，去除掉週末與假日，大約是20個工作天。
P.58
你的估計是你對客戶的承諾，說明你跟你的團隊要在多久時間內完成交付。
P.60
需求與估計的反覆循環
01.捕捉基本想法
02.bluesky腦力激盪
03.建構使用情節
04.找出需要澄清的漏洞(假設)
05.清楚的、以客戶為焦點的使用情節
06.進行計劃撲克牌
07.從客戶那兒取得缺少的資訊，並且分解太大的使用情節
08.估計完成所有的客戶需求要花多少時間
P.66
開發技術
01.共築遠景、觀察、與角色扮演
02.使用情節
03.以計劃撲克牌遊戲進行估計
開發原則
01.客戶知道他們要什麼，但有時候你必須幫他們確定下來
02.需求是以客戶為導向的
03.反覆跟客戶一起發展及精煉你的需求
要點提示
01.當論及需求時，共築遠景(bluesky)讓你的客戶想得更遠。
02.使用情節從客戶的觀點捕捉一項與軟體的互動。
03.使用情節應該簡明扼要，大約三句話。
04.簡明扼要的使用情節是可估計的使用情節。
05.一個使用情節不應該花一個開發者15天以上的時間才能夠完成交付。
06.反覆跟客戶一起發展你的需求，讓他們在流程的每個步驟上保持在狀況內。
3 專案規劃：計劃為成功之母
P.73
何謂"Milestone 1.0"?
Milestone 1.0(里程碑1.0)是你要交給客戶的第一個主要版本(first major release)。這不是你在較小的開發循環中為取得客戶回饋而展示給他們看的東西，而是你第一次實際交付的軟體(並且預期因交付而得到酬勞)。
在計劃Milestone 1.0 時，有一些"要"與"不要"的事項需注意：
01.要......在功能與客戶的焦慮感之間取得平衡
02.不要....只是柿子挑軟的吃
03.不要....擔心時間(還不要)
P.75
假如功能太多，重新決定優先順序
要跟客戶一同重新決定Milestone 1.0 的使用情節優先順序
01.砍掉更多功能
02.盡早交付里程碑建置版本(milestone build)
03.把焦點擺在基線(BASELINE)功能
P.84
保持你的軟體持續不斷地在建置，並且總是可以執行，因此，你總是可以在開發環結束時得到客戶的回饋。
P.85
保持開發循環簡短
保持開發循環平衡
簡短的開發循環有助於你處理變更，讓你的團隊集中注意力並且士氣高昂。
P.89
velocity在你的估計中考量經常性耗費
velocity是一個比例或百分比(percentage)；在特定數量的工作天中，"實際"上有多少工作天被投入真正的生產活動中。
理想上完成工作所需的工作天 / velocity = 實際上完成工作所需的工作天
velocity亦可解釋為一種"折減率"或"折減因子"
P.93
一頭埋入開發循環前先處理velocity
P.98
當你告訴客戶來不及將他們所要的一切完成時....你該怎麼做?
01.為 Milestone 1.0 再增加一個開發循環
02.解釋超出範圍的工作不會被棄置不管，只是要被遞延到後面
03.將你的計算過程攤在陽光下
P.99
對於達成你所允諾的工作要有信心，應該審慎承諾而成功交付，而不是過度允諾卻導致失敗。
P.101
Burn Down Chart，有人譯成燃燒圖或延燒圖，是表達"剩餘工作"對"剩下時間"的圖形(工作正如火如荼地被解決掉)，對於追蹤記錄工作隨時間進展的執行狀況非常有用。
P.103
藉由velocity以及別讓自已與團隊超時工作，你會對你的計劃更有信心。
要點提示
01.規劃你要開發什麼的第一步，是要求客戶就他們的需求進行優先性排列。
02.Milestone 1.0 應該盡早交付。
03.在Milestone 1.0 的開發期間，試著以一個日曆月的開發循環長度反覆進行，讓團隊保持在正軌上。
04.當你沒有足夠的時間建造一切時，要求客戶再一次進行優先性排列。
05.從一開始就將團隊velocity考慮進來，據以規劃你的開發循環。
06.假如你真的無法在給定時限內完成客戶所需要的一切，必須誠實地向客戶解釋原因。
07.一旦為Milestone 1.0 找出一組大家同意並且可以達成的使用情節，就開始設置你的開發儀表版，進行開發工作。
P.106
開發技術
01.開發循環理想上不應該超過1個日曆月，也就是20個工作天
02.將 velocity 應用到你的計劃，讓你有信心實踐對客戶的開發承諾
03.使用牆上的Big Board(大看板)來規劃及監看當前開發循環的工作
04.選擇哪些使用情節可以在 Milestone 1.0 完成，以及哪些使用情節要被安排在哪個開發循環時，要徵求客戶的同意
開發原則
01.保持開發循環簡短且好管理
02.由客戶決定哪些使用情節要被放進 Milestone 1.0
03.謹慎承諾，成功交付
04.面對客戶，誠實為上
要點提示
01.由客戶決定優先性及什麼要放進 Milestone 1.0 。
02.建立短的開發循環，大約1個日曆月，也就是20個工作天。
03.在整個開發循環中，你的軟體應該保持可建置並且可執行。
04.將團隊的 velocity 應用到你的估計，判斷究竟有多少工作是第一個開發循環可實際完成的。
05.規劃切實可行的 Milestone 1.0 ，讓客戶滿意，你也會有信心完成交付並且獲得酬勞，然後，假如你交付得更多，他們甚至會更高興。
4 使用情節與任務：展開實際的工作
P.113
將使用情節分解成任務，為你的估計與計劃增信心。
P.120
同時進行多個任務
基本原則
01.特別注意彼此相關連的任務，或者至少要把焦點擺在軟體中共同的部分。越缺乏考慮，爾後的改變就會越頻繁。
02.試著不要讓任務具有太大的估計，那樣不僅不容易保持焦點，而且也會讓你對你的估計比較缺乏信心。
P.123
每日的Standa-Up會議應該激勵每個人，讓大看板保持在最新狀態、並且將任何問題早一點突顯出來。
P.131
Standa-Up會議讓你的同儕、與經理掌握到最新狀況，並且讓你充分掌握開發工作的脈動。
要點提示
01.每天舉行Standa-Up會議讓你盡早捕捉住問題。
02.讓Standa-Up會議少於15分鐘。
03.Standa-Up會議全然關乎進度、麻煩議題、以及更新大看版。
04.盡量將Standa-Up會議安排在早晨，好讓每個人在一天的開始就能掌握到專案的現況，正所謂"一日之計始於晨"。
P.141
未計劃的任務也是任務，必須被追蹤記錄、放到"進行中"與"已完成"區段、並且包含在Burn Down Rate中，就像其他任務一樣。
P.143
未計劃的任務讓你的Burn Down Rate升高
P.145
velocity不是良好估計的替代物；它是一種將團隊實際執行狀況納入考量的方式。
P.147
成功的軟體開發全然關乎是否能夠即時掌握狀況，透過瞭解你的進度與面臨的挑戰，你可以讓客戶保持在狀況內，準時交付客戶需要的軟體。
5 「夠好」的設計：以良好的設計完成工作
P.153
當你的每一個物件都只有單一理由被改變時，便是實作了單一責任原則。
P.156
萬一你唸出來的東西不合理，你的方法可能違反SRP。該方法很可能屬於別的類別....考慮移掉它吧。
P.165
良好的設計幫助你更具生產力，並且讓軟體更有彈性。
P.166
未計劃的任務還是任務
未計劃的任務在大看板上變成有計劃的
任務究竟如何開始並不重要，一旦出現在你的大看板上，就必須被估計、指派、執行，直到完成。
P.167
你的估計應該完整
在估計任務時，你應該計算完成任務所需時間--有時候，任務所牽涉到的不只是撰碼。假如你必須demo或者與利害關係人(stakeholder)開會，也要將這些活動的時間包含進來。
P.170
當所有工作完成時，開發循環便結束
6 版本控制：防禦性開發
P.200
處理多個釋出版本
你總是蠟燭兩頭燒；已釋出版本的臭蟲以及下一個版本的新功能，由你去跟客戶協調，在兩者間取得平衡。
要點提示
01.已釋出版本的臭蟲對客戶的優先性通常比實作新功能還要高。
02.你的臭蟲修正工作影響到已釋出的軟體，並且會被實作到正在進行中的新版本。
03.有效的臭蟲修正倚賴著是否能夠定位出特定的軟體版本，並且對這些版本進行修復，而不會影響到當前的開發工作。
P.207
標籤只是程式碼的快照，你應該總是將改變commit到分支，而不是標籤。
要點提示
01.主幹是當前開發工作進行的地方；代表軟體的最新版本。
02.標籤是附貼至儲存庫裡特定修訂版的名稱，好讓你能夠在稍後輕易地將它們擷取出來。
03.有時候，你可能需要將相同的改變同時commit到主幹與分支上。
04.分支是你能夠對它做改變的程式碼複本，而且不會影響到主幹上的程式碼。分支往往從被標上標籤的程式碼版本開始發展。
05.標籤是靜態的--你不會將改變commit給它們，分支是你不想要放在主幹中的改變(或者讓程式碼不受主幹中的改變所影響)。
P.212
良好的分支之道
只有在絕對必要時才作分支，每一個分支都可能是你需要維護、測試、釋出，及監控的一大塊軟體，假如你把分支視為不常發生的重大決策，就能夠將分寸拿捏好。
P.215
開發技術
01.版本控制無法確保你的程式碼能夠實際運作....使用版本控制工具追蹤記錄軟體的改變，並且散佈給團隊的其他成員
02.使用標籤記錄專案的重要里程碑(開發循環的結束、版本釋出、臭蟲修正、等等)
03.使用分支維護程式碼的獨立複本，但只有在絕對必要時才作分支
開發原則
01.總是要知道改變應該(或不應該)放到哪裡
02.知道什麼程式碼應該放進特定釋出版本--並且能夠再次取得它
03.控制好程式碼的改變及散佈
要點提示
01.備份你的版本控制儲存庫！它應該包含所有的程式碼以及所有的改變記錄。
02.在commit程式碼時，總是要使用良好的commit訊息--你跟團隊以後會很感謝的。
03.充分地使用標籤。假如有可能需要知道改變前的程式碼，就為你的程式碼版本貼上標籤。
04.經常將改變commit到儲存庫，但小心不要破壞了別人的程式碼，相隔越久commit，合併的動作就越難完成。
05.有許多 GUI 工具可撘配版本控制系統，對你的合併及衝突處理很有幫助。
6.5 建置你的程式碼：自動化建置
P.221
好的程式碼容易使用，且容易瞭解。
軟體必須可以使用
假如你無法確認程式碼被check out之後能夠正確地被使用，將它們放進版本控制伺服器就沒有什麼用處，而這正是建置指令稿(build script)發揮作用的地方。
P.222
Ant: Java專案的建置工具
P.231
自動化讓你把焦點放在程式碼本身，而不是重複性的工作。
藉由良好的建置指令稿，你可以讓相當精巧複建置流程自動化。單一專案存在著多個建置檔並不常見，每一個分別服務不同的程式庫(library)或元件(component)，在這類情況下，你可能會考慮利用一個主要建置檔(有時也稱為bootstrap指令稿)，將所有事情組織起來。
P.232
你的建置指令稿也是程式碼....程式碼隸屬於版本控制系統所管轄，在那裡，它被編製版本編號、貼標籤、以及儲存，可供以後使用。
P.233
要點提示
01.建置工具純粹只是工具，應該讓建置專案更容易，而不是更困難。
02.大部分建置工具利用建置指令稿，在當中，你可以指明要建置什麼、各種操作指示、以及外部檔案與資源的位置。
03.確認你有建立某種方式清理指令稿所產生的任何檔案。
04.建置指令稿也是程式碼，應該被check in到儲存庫，做好版本控制。
05.建置工具是為團隊服務的，而不只是為你。選擇適合所有團隊成員的建置工具。
P.234
開發技術
01.利用建置工具與建置指令稿，建置軟體、打包、測試、及佈署你的應用程式
02.大部分IDE都已經在使用某種建置工具，要熟悉該工具，你夠靠它建置應用程式
03.將你的建置指令稿視為程式碼，將它check in到版本控制系統
開發原則
01.建置專案應該是可反覆進行且自動化的
02.建置指令稿為其他自動化工具奠定基礎
03.建置指令稿不只是一個步驟接著一個步驟的自動化，並且能夠捕捉編譯與部署的決策邏輯
要點提示
01.除了極小的專案之外，所有的專案都具有不可輕忽的建置流程。
02.你想要捕捉及自動化"如何建置你的系統的知識"--理想上，一個命令就能夠完成。
03.Ant 是 Java 專案的建置工具，將建置資訊捕捉在名為 build.xml 的 XML 檔案裡。
04.越是遵循一般的命名約定，你的專案對別人來說就越熟悉，也越容易整合到其他的外部工具。
05.你的建置指令稿也是專案的一部分，就像任何其他的程式碼片段，應該被check in到版本控制系統中。
7 測試與持續性整合：仙人打鼓有時錯
P.238
有三種方式檢視你的系統
01.使用者從外部看系統
你的系統對他們來說是一個黑箱(black box)；不是做到他們所要求的事，就是沒做到。使用者在乎的是功能性(functionality)。
02.測試者稍微探究到表層下的東西
你的系統對他們來說是一個灰箱(grey box)
03.開發者將系統攤在陽光下
開發者則視它為開放的白箱(white box)
P.239
黑箱測試聚焦在輸入與輸出
01.功能性。
02.使用者輸入驗證。
03.輸出結果。
04.狀態移轉(state transition)。
05.邊界案例(boundary case)。
P.240
灰箱測試就像黑箱測試....但你可以窺視一下
01.驗證稽核與記錄。
02.供其他系統使用的資料。
03.系統所增加的資訊。
04.意外被留下的殘餘資料。
P.243
白箱測試運用系統的內部知識
01.測試程式碼的所有邏輯分支。
02.妥善的錯誤處理。
03.如文件說明所說的那樣運作。
04.適切處理資源受限的狀況。
白箱測試傾向以程式碼測試程式碼
P.248
一個步驗測試一切
01.建立測試組
02.使用一個命令執行所有測試
03.免費獲得回歸測試(regression testing)
讓測試所需花費的時間盡量減短，測試組花費執行的時間越長，就可能越不常被執行。
P.252
持續性整合(CI, continuous integration)
P.253
持續性整合將版本控制、編譯、與測試包裹在可重覆執行的單一流程裡。
P.259
不能運作的程式碼是不完整的程式碼！
你的程式碼直到通過測試才算完成。
P.264
測試所有的程式碼表示測試所有邏輯分支
P.265
利用測試涵蓋度報告看看涵蓋那些範圍
P.274
開發技術
01.你的系統具有各種不同的觀點與面向，你必須全部測試到
02.測試必須兼顧成功案例與失敗案例
03.盡可能讓測試自動化
04.使用持續性整合工具讓建置與測試隨著程式碼每次被commit而自動進行
開發原則
01.測試是一項讓你隨時掌握專案現況的工具
02.持續產整合讓你有信心，確保儲存庫裡的程式碼正確且適切地被建置
03.程式碼涵蓋度比較像測試"有效性"的統計數字，而不是測試"數量"
要點提示
01.持續性整合工具總是監看著儲存庫裡的程式碼品質。
02.自動化測試會讓人上癮。你還是要撰寫測試程式碼，所以趣味仍在，有時候你會把事情弄壞，那也是很有趣的。
03.確認持續性整合的建置結果與涵蓋度報告對整個團隊公開--團隊擁有專案，應該對專案覺得有責任感。
04.假如自動化測試失敗，持續性整合工具的建置工作應該也要跟著失敗，接著，寄送電子郵件通知 commit 錯誤程式碼的人，直到完成修復為止。
05.測試整體的功能性對於宣稱專案能夠有效運作是至關重要的。
8 測試驅動開發：讓程式碼負全責
P.279
規則一：實作任何產品程式碼之前，你的測試應該總是失敗。
P.280
規則二：實作讓測試通過的最簡單程式碼。
P.281
這稱為YAGNI原則....YAGNI代表"You Ain't Gonna Need It"。意思是"你不會用到"或"你用不到"，延伸為"用不到的東西勿事先準備"。
測試驅動開發以非常簡單的循環在運作：
01.紅燈：測試失敗。
02.綠燈：測試通過。
03.重構：清理任何重複、醜陋、或舊的程式碼。
P.286
為了保持你的測試可管理且有效，有幾個好習慣是你必須養成的：
01.每個測試應該只驗證一件事
02.避免重複的測試程式碼
03.將測試保存在原始碼的鏡像目錄(Mirror Directory)
P.287
測試驅動開發全然關乎為特定功能建立測試，接著，撰著程式碼滿足該功能。
任何超過該功能的事情對你的軟體都不重要(現在)。
P.293
"依賴"讓你的程式碼更為複雜，但TDD的要點是讓事情盡可能簡單。
P.295
當程式碼難以測試時，請檢視你的設計
P.296
Stratrgy設計模示為單一介面提供多種實作
策略設計模示封裝了一組演算法，讓它們變成可相互交換。
P.300
先測試帶給我們諸多好處：
01.組織良好的程式碼。
02.乾淨俐落的程式碼
03.鬆散耦合的程式碼
P.301
程式碼或許不完整，但具有較佳的型態。
P.302
自動化的測試驅動開發表示大量的測試程式碼。
P.305
以Mock物件替代真實物件
P.306
Mock物件是有效物件的替身
P.312
01.從你即將作業的任務開始
02.為第一個功能片段撰寫第一個測試，你現在處於紅燈階段。
03.撰寫最簡單的實作程式碼讓測試通過，你現在處於綠燈階段。
04.重構任何想要清理的程式碼，接著撰寫下一個測試....再次處於紅燈階段。
05.撰寫程式碼讓你的測試通過、重構、增加另一個測試、再讓它通過。重覆這個循環，直到你完成所有要增加進來的測試。
P.314
開發技術
01.先撰寫測試，再撰碼讓測試通過
02.你的測試一開始會失敗；接著，在它們通過之後，你可以進行重構
03.使用Mock Object，提供測試所需物件的各種變形
開發原則
01.TDD強制你將焦點放在功能性
02.自動化測試讓重構更安全；假如你弄壞了什麼就會立刻知道
03.良好的程式碼涵蓋度在TDD中比較可能達成
要點提示
01.TDD表示你會重構很多程式碼。很怕弄壞什麼東西嗎？只需利用版本控制系統將程式碼倒回(rollback)原先的地方，再試一次。
02.有時候，測試會影響你的設計--要知道當中的平衡點，審慎地抉擇，判斷增加的可測試產是否值得。
03.使用策略設計模示配合相依性注入，幫助各個類別去耦合化(decouple)
04.將測試保存在與原始碼平行的目錄結構，像是tests/目錄，大多數的建置與自動化測試工具都能夠配合這樣的設置。
05.盡量縮短建測試的執行時間，因此，執行完整的測試組也不會阻礙你的開發速度。
9 結束開發循環：涓涓細流匯江河...
P.320
Stand-Up會議的訣竅
01.把人數維持在10人以下。
02.保持會議簡短--理想為15分鐘以下，不得已的話也不要超過30分鐘。
03.在固定時間、固定地點開會，每天舉行，理想時間為早上，要讓團隊正視它。
04.只有對開發循環進度有直接影響的人應該參加；通常是開發團隊與測試人員，行銷人員也有可能。
05.每個人都能夠誠實地暢所欲言：充分溝通，讓整個團隊聚焦在當前的問題上。
06.總是報告你昨天做了什麼、今天打算做什麼、有什麼阻礙你。把焦點放在正在解決的問題上！
07.較大的議題另外解決--切記，15分鐘。
08.會議應該建立團隊的凝聚感：相互支持、解決問題，充分溝通。
P.324
系統測試在真實世界、黑箱情節中從頭到尾運用系統的功能性。
P.325
不要對自已的程式碼做系統測試！你對它太過瞭解以致無法客觀看待。
P.327
良好的系統測試需要兩組循環
P.330
在軟體開發中，多數問題的關鍵在於溝通。
有疑問產生時，跟你的團隊、其他團隊、以及你的客戶進行溝通。
P.333
有效系統測試的前十大特點：
01.良好且頻繁的溝通。
02.精確的系統文件說明
03.測試團隊對整體圖像的良好觀點。
04.開發團隊與測試團隊之間協同合作的動力。
05.盡可能自動化你的測試。
06.良好且頻繁的溝通。
07.建立清楚的判斷標準(criteria)。
08.文件化你的測試。
09.知道系統的開始與結束狀態。
10.良好且頻繁的溝通。
P.334
臭蟲的生與死
01.測試者找到臭蟲
02.測試者提出臭蟲報告
03.建立修復臭蟲的使用情節與任務
04.修正臭蟲
05.檢查修復結果，驗證它確實有效
06.更新臭蟲報告
P.336
臭蟲被記錄在臭蟲記錄器
01.記錄及溝通優先性
02.記錄每一件事
03.產生統計數據
P.337
良好的臭蟲報告應該具備：
01.總結
02.重新產生臭蟲的步驟
03.預期會發生什麼以及實際發生什麼
04.版本、平台、及location(地區與語言)資訊
05.嚴重性與優先性
P.338
對專案的執行來說，正確的事情還需要在正確的時機進行。
P.342
開發循環回顧的要素
01.事前準備
02.一切向前看
03.計算統計數據
04.準備一組標準回顧問題
P.343
開發循環的回顧問題sample
P.344
完成額外工作的一般性優先順序清單
01.修正臭蟲
02.提前進行下一個開發循環的使用情節
03.為下一個開發循環提供原型解決方案(prototype solution)
04.訓練或學習時間
P.346
開發技術
01.注意你的--特別是在開發循環結束之後
02.開發循環的步調很重要--假如你必須讓它順利進展，甚至可以丟棄某些使用情節
03.別因為有人提早完成而處罰他們--假如他們的工作成果確實有效運作，讓他們利用額外的時間繼續向前或學習新東西
開發原則
01.開發循環是一種設定中間期限的方式--務必要堅守
02.總是以平均團隊成員的角度進行估計
03.規劃開發循環時，心中要保持一個整體圖像--那可能會包含系統的外部測試
04.透過開發循環回顧反覆改善你的流程
要點提示
01.如在開發循環結呆時還有餘裕，那是為可能出現的新使用情節進行腦力激盪的好時機，它們將需要跟其他事情一起排定優先性。
02.低抗誘惑，不要在開發循環的最後一、二天忘記你的好習慣不要貪圖完成下一個開發循環的低優先性簡單功能，或著做一點點沒什麼用處的重構工作，你才剛剛把事情搞定，別又把事情給搞砸了。
03.努力跟測試團隊保持健康的關係。要是溝通不良的話，兩個團隊都會讓對方死得很難看。
04.任務實際花費時間與估計時間的比較並非必要，因為你的velocity會考慮到估計的誤差，但是，假如你知道某事真的錯得離譜，就值得在開發循環回顧中好好檢討。
10 下一個開發循環：無事還是要生非
P.353
為每一個開發循環重新修訂你的估計與velocity，將你從上一個開發循環中所學到的東西應用到當前的開發循環。
P.359
velocity告訴你下一個開發循環預期可完成什麼
對你的估計有信心
velocity提供你一種預測生產力的準確方式，利用它確保你在下一個開發循環中安排合適的工作量，並且能夠按照你的承諾將成果交付給客戶。
透過計算velocity，你將團隊開發情形的真實面納入考量，以便計劃下一個開發循環，成功達成目標。
P.369
決定重利用某程式碼時要小心，當你這麼做時，你正假設該程式碼能夠有效運作。
P.373
你的軟體....你的責任
你得對你的軟體負責，當中有問題的程式碼是不是你所撰寫的，根本不重要，臭蟲就是臭蟲，身為一位專業的軟體開發者，你要對即將交付的軟體負起所有的責任。
切勿假設其他人會遵循你們的流程
對別人所開發的每一行程式碼包持著懷疑的態度，直到你測試過它，因為不是每個人都會像你一樣採取專業的軟體開發方法。
不管是誰寫的程式碼，只要是你的軟體，就是你的責任。
P.380
要點提示
01.當你正在準備下一個開發循環時，總是要跟客戶一起檢查，確保你所計畫的工作正是他們想要完成的工作。
02.團隊velocity在每個開發循環結束時被重新計算過。
03.讓客戶為新的開發循環重新排定使用情節的優先性，基於新的開發循環所能負載的工作量。
04.不論是撰寫新程式碼，或者重利用他人的程式碼，都是你的軟體，遵循的流程都一樣。
05.軟體中的每個程式碼片段，不管是你自已撰寫的或者第三方的程式碼，都應該被表示成至少一個使用情節。
06.不要你正在重利用的程式碼做任何假設。
07.程式庫擁有良好的介面不保證程式碼能夠正確運作，別輕信任何事，直到你自己看到或測試過。
08.程式碼被撰寫一次，但會被(其他人)閱讀很多次，必須像你要呈現給其他人看的其他工作片段一樣地處理你的程式碼，它應該是可讀的、可倚賴的、且容易瞭解的。
處理不能有效運作的程式碼也是軟體開發的一部分！
11 臭蟲：專業除蟲
P.386
那是你的程式碼，所以，第一步是建置它....
P.392
第一要務：讓程式碼可建置
P.393
做任何改變(包括臭蟲修復)之前，先將程式碼納入版本控制並且建置成功。
P.395
焦點在於功能性，只需要修正使用情節所倚賴的程式碼。
要點提示
01.一切根據客戶導向的功能性而演進。
02.撰寫及修復滿足使用情節的程式碼。
03.只修正破損的部分。你知道那些是破損的部分，因為失敗的測試會告訴你。
04.測試是你的安全網。你利用測試來確認你並未損毀任何東西，並且知道是否完成修復。
05.假如某功能性片段沒經過測試，就等同於宣告該功能性是破損的。
06.雖然美麗的程式碼很棒，但符合功能性的程式碼總是比它還重要。這不表示讓事情得過且過，但總是讓你牢牢記住處理這段程式碼的初衷：符合客戶所需。
P.400
Spike Testing: 在一段時間內試著解決一部分問題，看看你完成了什麼，再利用它來推斷要花多少時間才能完成其他事情。
除了這裡的定義之外，Spike Testing多半用在效能測試(Performance Test)中，屬於壓力測試(Stress Test)的一種，代表短期極端負載測試(short burst of extreme load)，但廣義來說，Spike Testing亦可代表：在短時間內以大量資料測試應用程式，藉以評估該應用程式的弱點。
P.409
美麗的程式碼固然很棒，但測試過、具可讀性、準時交付的程式碼才是王道。
P.413
真正的成功全然關乎交付功能性。
P.414
開發技術
01.修改任何一行程式碼以前，確認它已經有版本控制並且是可建置的
02.當臭蟲來自於你所不瞭解的程式碼時，利用Spike Testing估計修復他們需要花多少時間
03.估計修復剩餘臭蟲所需的工作量，將團隊的信心度納入考慮
04.利用測試告訴你臭蟲是否已經被修復
開發原則
01.誠實面對客戶，特別是有壞消息出現時
02.有效運作的軟軟體是你的第一要務
03.可讀且可瞭解的程式碼是你的第二要務
04.假如還沒有測試過某個程式碼片段，就假設它不能運作
05.修正功能性
06.為你的程式碼感到驕傲
07.你的軟體的所有程式碼，甚至不是你撰寫的那些，全都是你的責任
要點提示
01.修改任何一行程式碼之前，透過將它增加到建置流程與版本控制系統，充分掌握對它的所有權(ownership)
02.對你的軟體所有程式碼負責，假如你看到問題，切勿抱怨"那是別人的程式碼"；撰寫測試，接著修正它。
03.不要假設任何一行程式碼可運作，直到有測試證明它。
04.有效程式碼第一；美麗程式碼第二。
05.看看你是否對你的程式碼感到驕傲。假如你樂於見到其他人閱讀你的程式碼並且倚賴你的軟體，那麼，它可能是良好的程式碼。
12 真實的世界：落實流程
P.418
軟體開發流程
是強加於軟體產品開發工作上的程序結構。
偉大的軟體流程是讓開發團隊成功的流程。
P.419
01.除非情勢緊急，別在開發循環途中做改變。
02.發展統計數據，以判斷你的改變是否有幫助。
03.重視團隊其他成員。
P.425
選擇對團隊與專案有效的流程....接著調整它的產出，以便符合客戶想要及需要的東西。
P.428
開發技術
01.運用真實的統計數據，嚴格評估流程的任何改變
02.必要時讓你的交付物正式化，但務必瞭解它所提供的價值為何
03.盡量讓流程的改變發生在不同的開發循環之間
開發原則
01.良好的開發者開發軟體--偉大的開發者交付軟體
02.良好的開發者通常能夠克服不良的流程
03.良好的流程幫助你的團隊成功
複習要點
01.每當你要改變流程時，將團隊的觀點納入考慮；他們也必須與你的流程共存。
02.任何流程改變的決策都應該出現兩次：一次決定要做，一次評估是否有效。
03.避免在多個地方記錄需求，那總是維護工作的夢魘。
04.對於神奇、特殊的流程要抱持著懷疑的態度，每個專案都有其獨特之處，你的流程要有彈性。
附錄一 本書遺珠
附錄二 技術與原則
