資管大學生 看 笑談軟體工程 — 敏捷式開發的逆襲 (上)
這是一篇讀書的感想心得與重點整理，內容除了有作者的想法，也要我自己親身遇到的事情。
「理論與實踐並濟才能體會書中的知識。」第一章
本書在第一章就提到：「想看這本書的怨念有多深」，以一個沒有什麼團隊開發經驗的我來說，並沒有太大的想法，但在看到下方的怨念事項，我卻笑了。其中最讓我印象深刻的是 「我不會寫單元測試ㄟ」這句話，這讓我想到與同學共同開發的種種……，總之大家幾乎都是以「我不會」做為起手式去避免掉這些麻煩。
但單元測試的重要性我已經心知肚明。這裡順手擺上一張最經典的測試金字塔。
通常在開發程式的時候發生問題，解決它的「花費」與「時間」最少，等到實際上線再來解決發生的問題，大多都牽涉到幾千行的程式碼，這也讓我想到目前待的公司最近遇到的問題，被要求解決系統上線後有一筆資料沒有顯示表上。但畢竟是工作我也不好多說什麼，只好硬著頭皮上了。經過了將近兩小時從前端、後端、資料庫、底層的腳本是否運行正常……，最終找到了一個在後端計算日期的函式發現邊界值錯誤。解決這個問題的過程實在讓我傷透腦筋，因為中間所有的程式全部都非經過我手，沒有任何文件，沒有撰寫任何的案例，沒有任何的單元測試、整合測試。只有無限的皮球在身旁滾動。
第二印象深刻的「怨念」則是：「團隊分工但不合作」，這也是發生在前不久的事情，情境如下：「A 員工負責開發 a 功能，但是 a 功能本身是被寫死在，某一個函式內，且必須帶著一個 http請求 進去才能執行，但我們要在系統底層自動運行此功能，想當然爾寫一個程式去呼叫它是最快速的選擇，但是請求還需要用到一些函式庫才能解決，於是我提出了以下的請求『能不能把程式從這個 函式 搬出去，然後我的程式可以直接呼叫搬出去的函式』，我卻得到了以下的答覆：『為什麼要這麼麻煩，直接把裡面的函式裡面程式複製一份出去就好了啊』，這個就令我不解，但礙於他寫程式的能力比我強，也待得比我久，我就沒有做太多的無異議的爭執」，一個將程式搬移的動作，讓程式的介面支援的更廣的改變，都不願意去更動，每個人各司其職「分工」但「不合作」。
第二章
在第二章裡作者提出了多數高階主管對於軟體開發的看法：「大老闆與高階主管絕大多數是以代工硬體的思維看待軟體開發」，這一點我就不太理解了，畢竟我一屆大學生對於代工硬體沒有太多涉略，也不好多說什麼，只知道代工硬體和軟體開發有許多本質上的不同，硬體的開發基本上已經成型了，而軟體則是不斷的創新才有新的商機。作者也在最後的部分提到軟硬體開發分工上的不同：「硬體分工很細，遇到問題，背後各有不同的協力廠商會出面協助解決。」
第三章
在第三章中講到了一間公司開發的程式已經經過很長的一段時間……，中間內容大概就像一般公司在開發系統的問題，不再贅述，結論是有 600 多個 bug 要修？！作者提供的方案有以下 5 個步驟：
1. 先將 bug 分類，看看能否找到 bug 出現的模式，例如：記憶體遺漏、資料庫交易處理、使用者介面驗證、商業邏輯、多執行緒控制、例外處理等所造成的 bug。
2. 從這些專案中（公司開發的專案有很多客製化的分支版本）找出功能最多、目前 bug 最少、或客戶最急的專案作為基礎，然後實施程式碼檢視（Code Review）。對照步驟 1 所整理出的 bug 分類，看看能否從程式碼檢視的過程中找出一些發生錯誤的蛛絲馬跡。
3. 補寫測試案例
- 針對每一個準備修復的 bug ，寫出一個自動化測試案例來重現這個 bug 。
- 對於不了解的功能，以測試案例來驗證與理解這些功能。
- 針對準備重構 （refactoring）的功能寫自動化測試。由於古早以 ASP 技術（此公司的專案是用 ASP 開發的）所開發的系統程式碼和使用者介面（user interface；UI）大多都是混在一起，要寫自動化單元測試可能不是那麼容易。所以要依據程式結構實際狀況來研究這種自動化測試要怎麼寫。
4. 導入持續整合（continuous integration）
5. 如果一切順利，看看能不能用同樣的方法來修正其他專案的 bug。
公司的 PM 表示：「可是，要求程式開發人員寫自動化測試不太可能耶。其他專案的 PM 會認為寫程式的時間都沒有了，哪有時間寫測試。程式設計師也會有類似的想法。」
作者 OS：「自動化單元測試不會寫－失敗。不願意寫－失敗中的失敗。」
第四章
第四章中作者提出了某些人對軟體工程的誤解，上述案例公司的老闆說：「客製化和產品是不同的，無法從軟體工程做起，應該是要如何提升程式品質。」這裡我就採和作者同樣的見解「軟體工程就是要改善品質和提升效率」，哪有分是不是產品的，作者還提及「所以，這是說客戶拿到爛軟體算他活該，誰叫這是一個『專案』不是『產品』嗎？」。
第五章
接著是 PART2 第六章 Scrum 到底是？一開始簡單說了一下 Scrum 的意思後，直接跳到了「雙重回饋機制」，在上軟體品質管理的時候也有上到這一部份，但是沒有明講這兩個「回饋」的實際內容該開些什麼，這兩個會議分別是檢視會議（Review meeting）和自省會議（Retrospective meeting），檢視會議是針對需求的回饋，要展示給客戶的，而如果以專題為導入的目標則是展示給專題老師（正好最近有想要把 Scrum 導入到同學的專題小組，比起紙上談兵，不如真槍實彈來的更有收穫），如果沒有達到期望則在之後的 sprint 加以修改。
另一個會議－自省會議則是針對開發過程的回饋，團隊成員們要探討以下幾個問題：
- 哪些開發做法是好的，應該持續下去。例如：導入持續整合，或是有持續做 pair programming。
- 有哪些與開發流程有關的地方沒有做好且需要改善的。例如：自動化單元測試做得不夠好，或是測是硬體設備不夠。
- 擬定改善行動計畫
作者在後面提到，Scrum 並沒有規範要用哪些實務做法，不過要導入 Scrum 就勢必理解以下敏捷實務做法，如：包括持續整合、自動化單元測試、重構、測試驅動開發（TDD）、pair programming、程式碼檢視等，這些知識。
在最後提及了實務上遇到的困難，包括公司的環境及支持與否、團隊是否適合，最佳實務做法是不是該被推崇……等。
總結，Scrum 是一套簡單的方法，但是實施幾個月後會非常的累，很少有團隊能夠按表操課，又由於 Scrum 主張自我管理（老闆不要管），這個團隊自然就會變得又快又好，這也是非常難的，最後 Scrum 的實施還是非常的看中高階主管及老闆的，如果老闆很__的話，那還是得乖乖聽話，這時還是乖乖等每月5日好了。
第七章
第七章，Scrum 的內涵。先上一張 Scrum 靜態圖。圖中包含三個主要的元素，分別是角色（role）、活動（activity）與產出物（artifact）。
角色（role）分為以下三種：
Product Owner（PO）：產品擁有者。
Scrum Master（SM）：協助開發團隊依循 Scrum 的精神來開發軟體，確定 Scrum 所規範的幾個活動都有定時且正確的進行。
Developer：負責開發軟體。Scrum 強調團隊成員的組成應該是一個所謂的「跨職能團隊（cross-functional team）」，也就是說，團隊要包含所有能夠完成專案的人才。而這些人才最好能夠擁有多技能。
活動（Activity）分為以下幾種：
衝刺規劃會議（Sprint plannig meeting）：在每個 sprint 開發活動的第一天，團隊要舉辦此會議，主要的用意有兩點：（1）挑選這個 sprint 開發的
再上一張 Scrum 動態圖。說明上述元素彼此之間的互動關係。（圖片都來自書中作者精心打造的）
最後幫作者打一下廣告
