“Software development using scrum”讀書筆記

“Software development using scrum”讀書筆記

Part I. Overview

敏捷(Agile)對於中國的軟體Team Dev和個人來說，一直是一個比較新鮮的概念，雖然很多優秀的中國公司也有幾年的敏捷實踐經驗了，但同國外的積累相比，仍然屬於比較初級的階段。最近閱讀了敏捷實踐的一部非常經典的書籍，結合自己從業這些年和現在所在公司、團隊實踐敏捷的經驗，寫下一些心得和讀書筆記，以供自己和他人蔘考。

首先明確概念：Scrum是一種迭代式增量軟體開發過程，通常用于敏捷軟體開發。Scrum在英語的意思是橄欖球裡的爭球。在書中有一段話非常準確的描述了剛接觸Scrum的人需要銘記於心的：”Scrum轉型意味著一場變革，在轉型的過程中，人們的思維方式和行為方式都必須隨之發生改變，它不僅是指技術層面的轉型，更意味著理念的革新。人們需要學會在沒有大而全的計劃的情況下開始工作；人們要學會在沒有詳細需求文檔的情況下，通過使用者故事和交串流分析和理解需求，開始設計和編程；人們要習慣於頻繁遞交代碼和持續的整合……”

回想起大學時代所接觸的正統軟體課程，特別是在軟體工程中提到的軟體生命週期模型，從需求分析到概要設計、詳細設計在到開發實現和整合測試等階段。那裡所提到的都是被稱之為”順序式”軟體開發的流程，如果習慣了順序式開發，要轉型為Scrum，確實需要在觀念上首先接受思維的變革。

那麼到底Scrum式的敏捷開發到底是什麼樣子？筆者個人的理解仍然是一堆零散的片段：持續改進，保持高效的溝通，通過測試驅動開發和儘早的引入自動化測試，保持在每一個短暫的周期裡都能交付甚至發布一部分穩定的可以使用的功能，然後及時的得到使用者和相關人員的寶貴反饋，讓需求在整個軟體周期中可以隨著開發和客戶的反饋同步得到不斷細化。在這個過程中，團隊成員彼此協同共同建立對產品品質的責任制，每個人也可以不斷的感受到開發出客戶滿意功能的成就感，並且把個人的意見和靈感持續靈活的整合進軟體產品中，保持產品一直在市場上具備一定的競爭力甚至走在領域的前端。這就是筆者所理解的Scrum，簡而言之就是一句話：通過永不止盡的迭代式改進使得軟體產品能迅速的響應市場的任何變化。

Scrum以及敏捷的出現來自一些必然的原因驅使。其中來自企業外部的原因是非常公用的：市場瞬息萬變，客戶當下提出的需求，在6個月甚至3個月之內有可能變得面目全非；而競爭者的動作也可能讓你當初的設計不得不堆到重來，最有價值的資訊，也不可能在項目的初期就憑空想象出來。畢竟，當今世界，變化來得比以往更快了！另外，來自企業內部的原因，可能稍顯複雜，因為每個企業都有自己的特性，其中常見的向敏捷改革的動力包括：堅持傳統的方式，員工在高強度的工作下，無法感受到成就感和實現自我價值，團隊之間的溝通過於依賴冷冰冰的文檔，大夥總是預設了經理和老闆才是應該對產品負責的人，多團隊共同協同時，也經常因為各自掌握的資訊都是片面的而產生諸多誤會，以至於最後共同開發出來的產品，以品質的缺失甚至需求的誤解來還這筆債。

Part II. What’s Scrum

實施Scrum又包括哪些方面呢？首先要接觸幾個Scrum和敏捷中新的概念：在Scrum式的軟體開發中，整個開發週期被劃分成一個個短暫的時期，通常叫做一個個Sprint。每個Sprint的長度可以因公司和產品而異，但一般是2周到4周，且不宜過長。Sprint的意義在於，在每個短暫的周期裡，團隊的責任是交付一些可以使用但並不一定完美的功能，而目的是能及時的得到客戶、產品負責人的反饋，也可以儘早的得到整個系統整合這些功能所帶來的隱患反饋。在Scrum式的理念裡，Scrum團隊應當具有自組織的特性，大家都有著公開一致的願景，並且根據個人的特長通過結對程式設計等方式，自由的提出改進產品品質的想法，共同對產品來負責，這裡也許弱化了以往所謂的專案經理的權威和實施的管理工作，由整個團隊來承擔責任。這裡會產生一個新的角色叫做ScrumMaster，他的作用並不是做任何決定發布任何命令，而是協助團隊、引導團隊始終在堅持著Scrum的原則，做最正確的事。即使他將實行任何的權力，這種權力也應該是團隊一直通過授予他去做的。

關於一個優秀的ScrumMaster應該具有的品質，書中提到了這樣幾點：能夠並且願意承擔責任，這種責任是指最大化團隊的產出並支援小組成員實施Scrum；不會以自我為中心，能理解全體團隊成員的價值，並以身作則促成其他人也達成這樣的共識；確保團隊成員能夠把問題拿出來公開討論，鼓勵團隊用共贏的方式來思考；對項目以及目標具有高度的奉獻精神；最好具有較廣的知識面和交際能力，能夠高效正確的傳達來自市場、客戶甚至銷售人員對產品的反饋資訊給整個團隊。

在Scrum式的軟體開發過程中，團隊不再死盯著需求文檔(當然並非說完全拋棄需求文檔)，而是借用一種有序隊列來分析和掌控整個開發過程的重心導向，這樣的隊列叫做Backlog。產品Backlog包括所有有待添加功能的列表，它由產品負責人維護並根據優先順序從高到低順序儲存。它具有很高的動態性，隨著Sprint的功能交付和反饋資訊，Backlog中的事項會被增加或者減少，其中將要被實現的事項也可能得到進一步的細化和修改，當然這些事項也會因為有了更多的反饋和團隊對產品的瞭解而重新排列優先順序。

Part III. How to Scrum

在筆者工作過的幾家公司，大家似乎都意識到了要想Scrum的一些概念靠攏，產生了一些與Scrum不謀而合的想法。即使那個時候大家甚至都沒有聽說過敏捷或者Scrum。比如團隊營造一個彼此分享持續學習的氛圍；互相review代碼提出不同的看法；更頻繁的check in代碼，做到每天的產品整合中並且迅速的檢驗整個系統的健康；弱化早起需求的神話效果，讓使用者的反饋和市場的競爭來引導功能發布的優先順序…諸如此類等等。

儘管如此，由於沒有系統的瞭解過Scrum，仍然有做得不到位的方面。這裡筆者不得不提的一點就是：為了讓Scrum最宣稱的一點，團隊產出最大化，非常重要的一步就是在整個開發流程中儘早的引入自動化測試。無數事實證明，最後再測試是沒有多少效果的，因為到那個時候，往往有些錯誤為了顧全產品架構的大局而不得不放棄或者延緩修改，你已經錯過了最佳的反饋時機。在Scrum所倡導的每個Sprint中，當穩定的功能被按時交付了之後，持續的整合會產生新的build或者installer，這時都應該對整個系統所全面的整合測試，而且在開發coding的過程中，單元測試也應該儘早的發揮作用，整個Sprint的核心都是為了保證交付的功能穩定健康而且盡量不會對系統的其他部分造成影響。試想一下，如果這些測試都交給手工來做，我想無論任何一家公司，都承受不起這個成本。如果能讓自動化測試更早的發揮作用，包括自動化的單元測試和整合測試，無論是開發人員還是測試人員，都可以迅速的得到反饋並把大部分的精力投入到改善和迭代、重構，專註於實現每一個Sprint的目標中去。書中提到的一句話很有道理：”在Sprint的第一天和最後一天都應該有同樣多的測試活動”，直至最後一個Sprint產品順利發布。相比之下，手工測試應該主要作為”探索式測試”，以短為特色，它產生的周期類似於測試驅動開發應該具有的測試->寫代碼->重構的短周期風格。

Scrum中非常重要的一點就是保持資訊的透明化和高效的溝通。筆者現在的項目團隊會按照Scrum的思想堅持一系列的碰頭，包括兩周一次的Sprint Planning Meeting(因為我們的Sprint長度是兩周)，還有每天團隊的Standup Meeting(大概15分鐘)。在Sprint Planning Meeting上，大家著重討論的是產品Backlog中靠前(優先順序較高)的事項，對上一個Sprint交付功能的評審，以及一些持續改進的建議。在這裡我們做的並不好的是，團隊的每個成員並不會時刻都有機會看到Backlog的變化，這樣就錯過了很多一閃而過的好的想法和不錯的質疑。而在Standup
Meeting上，大家只是簡短的描述一下每個人的進度和模組之間協作的疑問，保證大家都能對整個Sprint產品的變化保持全域的瞭解。

這裡值得借鑒的一點是書中提到：有經驗的Scrum團隊必須始終保持深度協作，跨職能團隊一起工作，而不是講工作從一個組交接給另外一個組。摒棄一個任務必須在下一個任何開始前完成的概念，用”完成-完成”的關係取代”完成-開始”的關係。

另外，許多企業在實施Scrum的時候也會引入一些工具。在筆者的公司，我們使用的是傳統的JIRA來管理項目，通過購買JIRA的一個外掛程式叫GreenHoper，來構建我們的Backlog、燃盡圖 (burndown chart)以及管理每一個Sprint。筆者一直認為JIRA是個出色的順序式專案管理軟體，但是它並不能很好的傳達Scrum思想。一個無法改變的概念是JIRA分配任務是以issue的形式，每個issue只能有一個assignee，這在筆者看來似乎有違敏捷中倡導的團隊責任制。理想的狀態是：代碼是團隊的代碼，任何人只要提出足夠的理由來，都有義務去讓代碼的品質變得更好。結對程式設計說的也是這個概念，兩個人面對同一份代碼，各自操作一個鍵盤，互相輪流寫一段，融合各自對產品、對技術的經驗，最終產出品質更高更穩定的代碼。

Part IV. Guide of Scrum

筆者閱讀完這本書，反思了許多過往的經驗教訓，也記錄了書中對實施Scrum所給出的指導性意見。這裡把它們零散的羅列出來，希望其中的某一點或者某幾點能在將來持續的給自己或者他人帶來啟發：

最好用Scrum自身來管理Scrum實施過程，由於它的迭代本質、固定的時間箱(Sprint)以及對團隊協作與實際行動的重視，使其看上去特別適合實施Scrum而實現敏捷的大型項目。

有許多對Scrum和敏捷的誤區極易出現：”Scrum要求每個人都是通才，Scrum團隊不做計劃，Scrum忽略系統全域架構，Scrum不適用於過於複雜的系統。” 這些誤區有時是因為對瀑布式和順序式的流程深信不疑，或者對變革充滿恐懼，其實這些誤解只要做到：合理的任務劃分、共同責任制的建立、每個Sprint都交付有價值的成果、持續的整合以及通過結對程式設計和TDD(測試驅動開發)等手段提高代碼品質，這些問題和誤區都會不攻自破。

優秀的團隊需要兩個角色才能取得成功：產品負責人為團隊指出正確的目標，ScrumMaster協助團隊儘可能有效達到目標。產品負責人應該分享誘人的願景而創造激情洋溢的氛圍，優秀的產品負責人應當具有的品質是：始終Available、熟知業務、善於溝通、行事果斷。

Scrum團隊的自組織性消除了團隊技術領導這個角色。個體需要跨越他們本身的專業而儘可能的協助團隊其他成員 (這有力的反駁了Scrum要求團隊成員都都是通才)；團隊也從強調編寫需求文檔轉變到廣泛討論需求；團隊需要在每個Sprint結束時產生一些切實的交付物。個人選擇任務是團隊成員能做到自組織最根本的因素，必須留給團隊自己做決定。

在Scrum團隊中，程式員很大的變化之一就是他們將不能呆在自己的隔間裡等待有人來告訴他們具體改寫什麼程式，他們需要積極主動的理解產品需求。在敏捷團隊中，測試工程師會對開發過程有著更多影響，更重要的是對最終產品本身的影響。

堅持TDD(測試驅動開發)，你將得到一個巨大的好處是：系統中所有的代碼都可以被測試。它能協助程式員通盤思考他們的設計。重構是指改變代碼的結構，而不是代碼的行為，重構不僅對TDD的成功至關重要，也有助於防止代碼腐爛。越是複雜的代碼模組，越是應該考慮使用結對程式設計的方式來完成它。這些都屬于敏捷編程的概念，敏捷編程為變更而做設計，它的目標是設計出能接受變更、甚至期望變更的程式。理想情況下，敏捷編程允許以簡單的、局部的方式來適應變更，以避免或大大減少重大重構、重新測試和系統構建。

Scrum團隊的兩個關鍵因素：保持小團隊和定位每個團隊基本上可以交付端到端的、使用者可見的功能。團隊規模越大，溝通的開銷就越大，個人的力量發揮的空間就越小。所以，一個Scrum團隊基本應該保持5~9人。Scrum團隊一成俱成，一敗俱敗，這裡沒有我的工作和你的工作，而只有我們的工作。

每日站會在團隊成員以及可能的其他參與人員中傳播資訊，Wiki和大的可視圖表給出了Sprint和項目進展狀況的一個概覽，團隊成員或者其他的人可以很容易的瞭解項目狀況。在團隊中對新的想法應該持開放態度，鼓勵犯錯誤，然後用改進的方式繼續做。敏捷轉型其實就是想方設法取得預見性和適應性之間合理的平衡。敏捷開發的目標是找到文檔和討論之間的合理的平衡。例如，使用者故事是將團隊焦點從編寫功能需求轉移談論它們的最佳方式。好的使用者故事，應該詳略得當，能湧現出使用者真實的需求，並且隨時適應外界因素的變化而更新(包括它的優先順序)。

對Sprint產生的可交付的定義是通過了測試可運行，並不一定完整，但能成功的整合進整個系統的功能。快速的提供可工作的軟體勝於全面的文檔，使用者能夠更加直觀的感受到這是不是他們想要的東西。不要輕易改變Sprint的長度，保持一個比較固定的節奏，儘管不同團隊特別是跨地區的團隊共同開發一個項目時，各自Sprint的起始時間可以有2~3天的不同。無論何時，都不要延長Sprint的長度，因為這會給出計劃內的工作可以完不成這種跡象。除非有非常特殊的理由，否則不要輕易改變Sprint的目標，儘管它的外部世界可能正在變化，Sprint的短暫正式為了適應外界的變化，但它本身對目標是非常強調保持貫徹始終的。

比起加班，更好的做法是給團隊增加能源。增加能源最好方法之一是增加熱情。為此，產品負責人需要傳達一個令人信服的願景，讓開發這個產品的團隊滿腔熱情的工作。每天堅持兩次長一些的精神放鬆，每天兩次符合人類的亞節律。人的身體逐漸從精力旺盛狀態過度到生理的低穀期大概是90~120分鐘。

保持產品Backlog大小的合理，一位人類學家說人腦對於自己維持正常社會關係的人有一個大概150人的上限。我們大概最多隻能記住150人。同理，太過於細化和龐大的產品Backlog會變得不可管理，也不可能讓團隊成員都熟悉。在一些很龐大的功能描述上可以藉助史詩故事(Epic)或者主題故事(Theme)來做代表，總之使得Backlog的size不超過100~150。另外針對不同的模組或者組件團隊可以從Backlog衍生出多個不同的視圖，來保持每個團隊都在清晰的關注這自己正在開發的功能。

CMMI標準與Scrum並不衝突，在追求某個特別的CMMI層級時，很多企業忘記了最終的目標是改進他們的軟體以及交付的產品，相反，它們關注於填寫按照CMMI文檔描述的假想的缺陷，卻不關心這些變化是否能改進過程或者產品。但當CMMI目標與Scrum與生俱來的關注價值以及”最近你為我完成了什麼”的意識結合時，這個問題就會被消除。

ScrumMaster作為團隊的傳道者和保護者，應該緊挨這團隊地區的主要入口就坐。充分保證團隊能免受幹擾的繼續這Scrum的正確行為。同時在工作空間，Scrum團隊成員應該能明顯看見的東西包括：大的、可見的圖表，額外的反饋裝置(如果可以的話，自己開發出來)，團隊裡的每一個人，還有就是最重要的Sprint List和產品Backlog。一個好的建議是有一塊大白板，鼓勵任何範圍團隊成員間突發的會議和討論，使用這個白板來記錄創意和發現的問題。至於食物和飲料什麼的，這就要看各個公司的文化了。(在筆者的團隊裡，筆者鼓勵購買一些大家愛吃的零食，在大家注意力都開始下降的時候停下來，吃點東西，聊一聊工作之外的話題來協助每個人放鬆)

Part V. End

終於總結完了，到了尾聲筆者想說的是，Scrum和敏捷的理念是在這個瞬息萬變的世界中應運而生的。其實它並非是IT行業特有的，每個學習和實施Scrum的人都應該牢牢記住的是：Scrum的持續改進是沒有終點的！今時今日的理論和經驗，可能隨著世界的變化繼續進化和演變，世界上也沒有任何一套理論和流程是足夠完美的，我們都必鬚根據所在的公司文化、團隊現狀、項目情況來反思總結出最適合自己團隊的Scrum版本來，最終無論我們給它一個什麼樣的名字都無所謂，最重要的是它能讓團隊成員深度協作、快樂的工作，讓團隊共同肩負起對項目和產品的責任，高效而高品質的開發出在市場上具有競爭力的產品。