Scrum靈活開發沉思錄

總結一下Scrum流程。

　　計算機科學的誕生，是世人為了用數字手段解決實際生活中的問題。随着時代的發展，技術的進步，人們對于現實世界中的問題了解越來越深刻，描述也越來越抽象，于是對計算機軟體的需求也越來越高，越來越複雜，變化也越來越頻繁。

　　而軟體技術的發展也是随着人們認知水準和抽象能力的不斷提高，從面向過程程式設計，進化到了面向對象程式設計，再到日漸紅火的面向服務的程式設計。伴随着思維的不斷進步，實作軟體的技術手段也随之變遷，從最古老的瀑布流程，到RUP統一過程，到靈活軟體開發，它們的出現無一不展現了需求，變化，效率，時間與品質的多方博弈。

　　今天，我們的主角就是炙手可熱的靈活軟體開發。靈活軟體開發老早就炒的如火如荼了，本人曆經幾家公司，也都在不同程度上受到這個理念的波及。

靈活思想

　　傳統瀑布模型的弊端很明顯：過于強調文檔，開發和測試介入較晚、風險高，無法快速響應回報，修改和重構成本過高。靈活開發就是針對傳統的瀑布開發模式的這些弊端而産生的一種新的開發模式，目标是提高開發效率和響應能力。

　　靈活開發是一種以人為核心、疊代、循序漸進的開發方法。在靈活開發中，軟體項目的建構被切分成多個子項目，各個子項目的成果都經過測試，具備內建和可運作的特征。換言之，就是把一個大項目分為多個互相聯系，但也可獨立運作的小項目，并分别完成，在此過程中軟體一直處于可使用狀态。

　　為了了解靈活開發，需要先了解靈活開發宣言，為了表示對各位先驅的尊重，特抄錄在這裡：

個體和互動 > 過程和工具
可以工作的軟體 > 面面俱到的文檔
客戶合作 > 合同談判
響應變化 > 遵循計劃
雖然右項也有價值，但是我們認為左項具有更大的價值。      

　　然後需要了解一下靈活開發的核心價值觀：

溝通：不但包括團隊内部的開發人員之間溝通、還包括團隊和利益相關人員之間的溝通。
簡單：簡單的實作和設計。正因為簡單，随着對軟體了解的加深，也更容易的改進。
回報：更早更快速的從使用者獲得回報，這樣能保證軟體在做正确的事。
勇氣：當需要做出重大的決策，放棄或重構(refactor)你的工作，修正你的方向時，勇敢去做。
謙遜：尊重每一個參與項目的人，無論是團隊，還是客戶，甚至其他的利益相關人員，他們對項目都有價值。      

　　純理論的不想說太多，當你實踐過靈活開發以後再回頭來看看這些簡單的字眼，你會發現它們簡直就是至理名言(不管你信不信，反正我是信了)。

靈活實踐

　　偉大的哲學家王守仁先生最偉大的觀點就是：知行合一，是以接下來就來看看靈活開發的實踐。

　　踐行靈活開發理論的流程很多，但是要說最有名的，那應該還是Scrum和XP(極限程式設計)，前者重在管理流程，後者重在程式設計實踐。實際使用中，能把這兩者結合起來的公司是少之又少，大多數的公司都是使用Scrum去管理項目，而XP，更多的是程式員們自己的興趣和愛好。由于本文重在管理，是以重點解析Scrum流程。

　　Scrum的流程基本可以用下圖來概括：

按照傳統的記叙文的寫作方式(時間、地點、人物，事情的起因、經過、結果)來描述一下Scrum流程就是：

時間：每個Release和每個Sprint
地點：辦公室，這個毋庸置疑，至于站着還是坐着，那就看個人愛好了
人物：整個團隊，包括管理人員，市場人員，客戶代表，程式員，測試人員，設計人員，通常分為3類：
    Product Owner：通常包括産品經理，産品負責人，營運人員；
    Scrum Master：通常包括項目經理，項目負責人；
    Team Member：通常包括開發人員、測試人員、美工設計等全職能性團隊。
事情的起因：客戶或客戶代表提出需求或者産品的回報，公司研究決定推出新産品或新版本。
經過：
    1.Product Owner把需求和回報轉化成User Story放到Backlog中；
    2.規劃Roadmap，然後集合Team所有人員讨論決定最終Overview；
    3.Product Owner規劃Release Plan，根據Plan中的時間劃分Sprint；
    4.開始每個Sprint(2-6周不等，視實際情況而定)：
        1).Plan Meeting (可進行多次)：
            a).整個團隊根據Product Owner設定的任務優先級，標明該Sprint中需要完成的User Story和要處理的Bug。
            b).整個團隊讨論標明的任務中的功能，確定每個人對功能的表現都有相同的認識。
            c).Scrum Master與開發團隊拿出撲克牌，估算每個任務的時間和難點。
            d).開發人員領取任務(先估算，後領取是有道理的)。
            e).測試團隊根據每個任務的描述，設定驗收的标準和案例。
        2).編碼與測試
            a).開發完成功能，進行單元測試。
            b).測試完成功能測試，有問題的報Bug。
        3).Standup Meeting (每天，或每幾天一次)
            a).Scrum Master與開發團隊，測試團隊一起同步一下開發與測試的進度。
        4).Review Meeting (可進行多次)
            a).整個團隊讨論一下該Sprint的執行情況，驗收完成的功能，需要調整的方面加入到Backlog中或Bug中。
            b).整個團隊反思與總結一下該Sprint的經驗、教訓。
            c).根據反思的結果，指定一些Action Item，配置設定給相關人執行。
結果：Release新産品或新版本
道具：這個通常很重要，這裡主要是管理Backlog和Bug的工具，比如我用過的JIRA，Rally等等，當然看闆，燃盡圖等工具也很有意義，不管使用何種方式，目的都是管理項目的進度。      

Scrum反思

1.産品與文檔

　　瀑布模型的弱點之一就在于文檔驅動；能工作的産品才是王道，但是簡明扼要，清晰的文檔也還是很有必要的，特别是對于團隊的新人來說，但是文檔的作用又不僅限于此。很多時候，一份好的WIKI Page可以讓其他的人快速的了解産品的設計與功能。

2.合作的真意與以人為本

　　這是我所在團隊做的很不足的一點，很多時候QA(測試人員)并不知道某一個Feature(功能)的設計與表現是什麼樣的，往往是在測試的時候才會去向Dev(開發人員)了解該Feature的全部情況。而且很多時候，PD(美勞工員)與Dev在商量Feature的表現的時候，QA并沒有參與進來。我們也想了很多的辦法去改善這種情況，比如一個Feature完成的時候，Dev給PD，QA一起示範一下Demo，但最終這個方法并沒有得到執行，原因很多，大家的時間安排也不一樣。

　　看樣還是符合那句老話：計劃容易執行難。人天生就是懶的，特别是IT人士，如何提高團隊的認識和執行力還真是一個問題。不論什麼做法，前提還是需要得到大家的一緻認同，這樣才會有基本的執行力。

　　我認為，靈活開發中合作的真意就在于那份人的責任感，那份以人為本的核心理念。大部分靈活開發中的問題就是由于Team中的許多人還不是具有“靈活”思維的人所造成的。沒有靈活開發的思維，沒有工作的激情，隻有上司自以為是的訓示，和拼命趕進度的急促步伐，這可能是很多國内開發者與國外的靈活團隊最大的差别，這也是國内很多靈活項目失敗的根本原因。

3.Meeting的頻率與内容

　　開會很多時候是很無聊的，這個大家一定深有體會了；但是Sprint中的各個會不應該是這樣的。在靈活團隊的會議中，不存在上司驅動問答的形式，而是整個團隊針對會議議題暢所欲言，主體明确，目的達到以後就應該結束。這樣就能提高開會的效率。而開會的頻率，特别是Standup Meeting的頻率，很多團隊固守每天一次的頻率，個人覺得沒什麼太大的必要，我們采取的就是兩天一次，覺得感覺很好。

4.User Story和Developer Story

　　User Story自然不必說，那大多數來自客戶的需求或者是Team的回報。還有一些任務是來自QA或者是Dev的需要，比如自動化測試，架構的探索與設計，這些我們通常是處理成Developer Story，也算有點道理，不過感覺總是怪怪的，因為從我的角度來說，這些應該是分解，合并到各自的User Story中去的。

　　此外，由于User Story基本都是Product Owner添加的，是以開發中的的很多情況它們并不完全清楚，是以整個團隊在每個Sprint之前需要對這個Sprint中所有的任務進行讨論和初步的可行性研究。

5.簡單設計，疊代，重構與演進式架構

　　按照靈活開發的核心價值觀，代碼應該盡量簡單直接，不用太多的去考慮以後的擴充性，因為未來是不确定的。這麼說是不是就不用考慮軟體的架構了呢？答案當然是否定的。

　　架構與開發流程根本就是兩個不同的概念，架構是軟體的骨架，而靈活開發是建構軟體的過程，靈活開發可以影響架構的最終面貌，但是卻不能消滅它。靈活開發出現後，軟體架構設計的方式隻不過是産生了如下的變化：靈活開發把原先軟體過程前期的架構設計，分散到了整個靈活開發軟體過程中，也就是每次疊代中。

　　在每次的疊代中，随着功能的增加，需要不斷的重構以便使代碼滿足擴充性的需求。在先讓軟體運作，再重構其代碼的過程中，軟體的架構随着重構自然而然的在軟體過程中産生，這中做法通常就稱為演進式架構，以前是設計完後開發，現在是邊設計邊開發。

6.臆想的需求

　　在軟體的開發過程中，我們團隊經常使用的一個口頭禅就是“如果客戶這麼做了，就有....問題了”，但是客戶是不是真的會這麼做嗎？這麼做對客戶有什麼實際意義嗎？我們不知道，測試人員也不知道。這種工作我稱之為“臆想的需求”。有的時候，臆想出來的需求真的是會耗費太多的時間和成本。我想，靈活開發中讓軟體盡早能工作，讓客戶或客戶代表參與到開發中，就是為了讓軟體能正确的工作，為了提高工作的效率，這些臆想出來的東西還是盡量少有吧，即使搞一些BrainStorm，如果真的要加入到軟體中，還是需要依靠真實的客戶資料去嚴密論證。

7.盡早的測試與回報

　　這一點的重要性就不必說了，盡量早的發現軟體的問題，收到客戶的回報，然後根據這些真實的資料做出調整，規避完敗的風險，這是相對于瀑布開發來說最自然的想法之一。

8.持續編譯與內建

　　可工作的軟體是軟體工程最重要的産出，持續的內建，持續的編譯，持續的測試，持續的回報，持續的疊代，持續的重構，這是靈活開發的核心，也是每個Sprint保證品質的前提。

9.應對變化

　　變化是唯一的不變，這又是我們常用的一句口頭禅。确實，變化發展是唯物主義最重要的觀點之一，擁抱變化不僅對人來說是一件困難的事，對于軟體來說，也是一大挑戰。為了滿足需求的頻繁變更，軟體工程不斷研究應對變化的政策，靈活開發的核心思想就是改善流程，應對變化，規避風險。對于軟體技術來說，應對變化與重用也是其向前發展的最原始的動力，從過程的重用，到算法的重用，到對象的重用，再到方案的重用(設計模式)，這個過程中最根本的導因就是變化。

最後是一些參考的連結：

http://developer.51cto.com/art/200803/68222.htm

http://dearymz.blog.163.com/blog/static/2056574200881235317338/