小談Scrum敏捷開發流程

一晃眼，有兩年沒有寫博客了，回顧前兩年，各類奔波，各類忙碌，也有很多的收穫。從今天開始，我要把這些收穫都分享在這裏。

其實這兩年，對我影響最大的是開發流程。總所周知，一個好的開發流程，對於項目的進行，更新和維護都起着相當重要的做用。Scrum適用於一些開發週期長，需求不明確，或者隨時間漸進明確，頻繁更新的項目。然而，如今國內的一些公司，甚至一些大公司，都對這塊不過重視，或者作得不夠透徹。從而程序猿們每天加班，苦不堪言。

咱們先來看張我經過實際經驗畫的圖流程圖，紅色圈圈出來的是我認爲比較容易忽略的部分，接下來一一說明。

1/二、項目決定啓動後，第一步就是產品組準備需求，整理出需求文檔。這個需求文檔是須要屢次會議協商總結出的。在需求前期，產品組能夠自由發揮，把對產品的任何要求儘可能詳細地列出來，細節方面列不完整也不要緊，可是對於產品的最終呈現出的效果，大的方向，要有一個完全明確的說明，由於這個可能直接關係到產品架構的設計；而後進入需求中期，這個時候必定要引入技術經理以及技術主力，須要從技術角度去評估需求的可行性以及性價比，這讓技術部門可以基本瞭解大的架構方向，（我曾經就有碰到過一個項目，因爲產品組在美國，開發組在國內，產品組在沒有和開發組完全溝通的狀況下，就把需求和客戶達成共識，這以後使得咱們技術部門十分被動，結果就是沒法在規定時間上線，損失是小，在客戶面前失信是大！）；最後在需求後期，就能夠出具項目需求初稿，這個初稿須要產品組根據時間要求以及客戶要求，進行優先級劃分，並將其劃分爲多個模塊，分配給各個開發經理，制定Story或者backlog，再讓開發經理細分task，分配給各個程序猿，從時間的角度，須要設定Sprint，並將各個story分配到各個Sprint中，一個Sprint的週期通常是2個星期（10個工做日），遇特殊狀況可延長到3個星期。這個過程當中，最關鍵的是怎麼規劃Sprint，這個時候，對story時間的估算是很是關鍵的。咱們之前都是程序猿們和產品經理坐在一塊兒，爲每一個story一一估算時間。好比說一個story由2我的完成，2我的固然須要在事先了解需求，而後在對方不知道的狀況下，分別估算對這個2我的完成的story須要花費多少天/人次，若是兩我的時間接近，就去較大的那個天數做爲估算的時間，好比一我的估3天，一我的估2天，那麼這個story估算的總時間就是3天/人*2人=6天；若是兩我的的差距至關大，好比一我的估了2天，另外我的估了10天，那就有須要讓兩我的說明緣由，在排除了干擾因素後，再次估算，最後得出一個合理的時間。項目經理須要根據估算的總時間來安排Sprint裏的story。

這些都準備完成後，就能夠進行項目開發階段了。

三、由於我是微軟平臺的苦B程序猿，因此我接下來用到的都是微軟的工具。首先要有一個代碼版本控制軟件，我要在這裏說的是TFS。微軟的TFS有兩個版本，一個叫Team Foundation Server，一個叫Team Foundation Service，小弟都用過，因此來講明下二者的區別：Server版須要公司用本身的服務器部署，比較適合局域網內開發的項目，固然也能夠部署在公網，優勢是能夠最大程度的customize；Service版是部署在微軟雲上，由微軟託管的，比較適合跨區域中小型公司（缺乏硬件支持的），優勢是方便，和office365帳號綁定，公網也能夠訪問，缺點是沒法自定義流程模板。其餘功能都是同樣的。其實不管那個版本的TFS，功能都是很是強大的，徹底能夠知足敏捷開發項目須要。我曾聽有人抱怨TFS只能給程序猿用，項目組又不裝VS，不用用它來開task啊，開bug什麼的，而後又去買了JIRA什麼的專門給項目組用的流程控制工具，其實不必，TFS有個service portal，相似於sharepoint的站點，能夠用它來給項目組用，兩個版本都有，很是好用。固然JIRA也是很是不錯的，咱們當時也是兩個一塊兒用，JIRA在自定義流程上面仍是至關不錯的，咱們用JIRA來作部署流程控制以及運維流程控制等與代碼自己關聯不深的流程控制。

TFS在對代碼版本及質量管理方面是頗有優點的，咱們會把sprint，story，task等等通通在開發階段開始前錄入TFS，這些都是TFS默認的模板，咱們也能夠本身更換或者修改模板，遺憾的是service版無法改。具體怎麼修改能夠參考MSDN。

 

而後咱們能夠經過規則，強制在check in代碼的時候綁定task/bug/issue，以及強制寫comment以及check in notes，這些都至關重要。固然，代碼不能隨隨便便就能check in啊，最好須要有我的review，這個時候，咱們能夠先Shelve代碼，而後能夠指定一我的來給你review代碼，review代碼的人能夠經過TFS自帶的比較工具，比較shelve的代碼和最新的代碼間的區別，也能夠給代碼片斷寫comment，最後決定是否能夠提交和須要打回去，從新shelve。有人會以爲，這個好麻煩啊，不是會影響進度。我要說的是，若是沒有這個環節，或許你能夠很快速的完成開發，但別忘了，代碼不是寫完就算了的，代碼的質量也是至關重要的，誰都不想，項目進入測試環節由於某個不應發生的問題而影響一輪測試，也不想在項目上線以後，由於性能問題，再來review全部代碼，找到性能瓶頸......

順便說下測試，測試不比開發輕鬆，通常測試分爲smoke test，regression test，fuzz test，load test/performance test，security test。前兩個很少說了，很熟悉了，後面三個很容易被忽視，可是卻很是重要。有一句真理：任何一個軟件，永遠都存在bug，任何一種測試都沒法把全部bug都找出來！所以，咱們須要在測試階段儘量地將簡單明顯的bug通通找出來，這樣剩下的只是在特定狀況下才會特別發生的bug。smoke test和regression test是爲了找簡單明顯的bug，而fuzz，load，security等等測試是用來找出特定狀況下的bug。fuzz可以很好地驗證軟件的健壯成都，它經過隨機無序的任意輸入，測試系統的內部應對及輸出；load可以讓系統在某個壓力下測試系統的穩定性能，從而評估該系統/軟件能夠給多少人用，須要多少服務器，以及找出性能瓶頸，從而優化代碼；安全測試能夠測試系統的安全性，關於安全微軟還有一套完整的流程叫SDL，就不詳述了。咱們之前公司一直想作自動化測試，fuzz和load是能夠自動化的，可是功能性測試作自動化比較困難，VS自身有針對web服務的自動化測試項目模板，有興趣能夠了解下。但我的以爲還不算理想中那種自動化。反正有大批測試妹子，全自動化了，公司裏不就少了不少妹子，哈哈，扯遠了。。。

再說下發布，在分佈式的發佈體系下，比較頭疼的是，從QA到UAT，在到Staging和Production，各個環境可能須要不一樣的配置參數，尤爲是SOA的系統，在分佈式部署的時候，服務地址的配置一般很是頭疼，最簡單的方法是用配置文件的自動轉換功能，也有公司本身作配置管理工具的，也有把配置移到數據庫的。我的以爲，有條件的能夠本身開發套適合本身的配置工具，可是我做爲一個從簡主義者，我針對SOA系統，個人方法是這樣的：首先，在每一個環境的服務器集羣之中，搞一臺機器專門作內部的DNS服務器，咱們在dns服務器上爲每個須要分佈式部署的service定義一個內部域名，而後在配置文件中，都用這些預先定義好的內部域名，若是須要本地測試，能夠修改本身機器的host文件，map到127.0.0.1或者具體的局域網IP地址，包括數據庫地址也是能夠這麼作（這種方法對Azure SQL無效），而後發佈到任何一個環境都不須要改跟地址有關的配置；對於一些跟環境相關的其餘應用程序配置，本人建議存儲到數據庫或者作一個專門的配置服務。當在Staging上發佈並測試完成後，Production就不要再發布了，經過交換綁定的IP地址來實現切換，具體如何實現是IT的事情，這裏不說了。

四、終於一個階段開發完成，能夠順利進入測試階段了，這個時候，下個階段的新需求就又來了，而後又是重複的步驟，估時間，sprint，story，寫代碼，測試，發佈。

五、當產品上線後，確定會遇到很多特定狀況出現的bug，爲了發現bug，要有監控系統，這又是一個大話題，暫時略過，而後發現問題後，要可以重現，而後須要評估問題的嚴重程度，而後根據協商結果，決定是否須要立馬修復，仍是進入下個發佈週期修復，若是是須要立馬修復的就要作hotfix，開maintainence window，走一邊UAT-〉Staging-〉Production的過程，QA能夠不走，由於有可能下個階段的開發已經在QA上測試，若是下個階段的開發已經在UAT上了，那麼這麼急的hotfix也沒有意義了，若是下個階段已在UAT，prod又出現沒法運行的後果，那麼把production再切會以前的在staging上的版本吧。關於數據庫，staging和prod應該是須要工具來同步的。

先說那麼多，不少細節仍是須要不一樣的團隊不一樣的人員作一些調整。總結的不對之處，還望指正！