Scrum&Kanban在移動開發團隊的實踐 （一）
現在大多數團隊都在談敏捷開發，似乎覺得敏捷是軟體開發的銀彈。只需要實踐下一些敏捷開發的模式就能如何如何，其實我覺得不論是敏捷開發還是傳統的瀑布流開發都是有他們的市場的，取決於團隊人員構成，取決你的產品的屬性，所在市場的競爭環境。最終希望達到的目的都是一個：以最快的方式、最高的質量，實現所需的需求。
我最近所在的兩個團隊都是移動研發團隊，一個是在相對大型的外企內部面向企業級軟體，一個是創業型團隊面向消費級應用。第一個團隊我們是從傳統的瀑布流開發模式向Scrum轉變而來的，第二個團隊我主導整個研發團隊，結合了Scrum以及Kanban的，採用的是混合型的開發模式。
Scrum實踐
Scrum的基本概念我就不贅述了，希望快速瞭解的人可以一步到此。
我談下我們是如何操作的：
-
team角色的分配：產品，研發，Program Manager。產品提供業務的需求描述，MockUI。研發包括Scrum Master, Developer, QA，負責軟體的研發測試。Program Manager負責整個專案的進度控制以及對外team的溝通協調等等。
-
使用的工具：VersionOne用於整個Scrum開發的專案管理，後期我們換成了Jira Agile，主要是因為我們也用Jira來做bug Track，分散在不同系統管理也是挺複雜的。程式碼管理Github，文件管理Confluence，測試用例TestLink。
-
流程：
我們以一個月作為一個release週期，每個月的15號到下個月15號，釋出一般在下個月15號的那個週五。一個月分為3個dev sprint, 1個release sprint。
Release Planning階段
Release kickoff meeting: 週期開始階段，產品team負責解釋未來一個release要做的功能。通常產品team是維護Epic，並且將Epic分解成backlog（具體需求），並排好backlog優先順序。
Engineer backlog discuss meeting: 拿到backlog，研發團隊就需要對backlog進行分析，理解需求，並能分解成Task (任務)，並對每個task的工作量進行估計。這時會有兩種方式進行工作量的估計，傳統的人天，或者用Poker Points。
人天的方式比較容易操作，大家熟悉也比較好理解，但這種方式是沒有辦法去衡量一個團隊的生產力變化情況。對於一個固定人數的團隊，在固定時間內可以產出的人天數是固定的。
Poker Point的做法是選定一個task作為基準，比如1分，然後評估其他任務的時候始終以這個基準作為參考給出相應的分數。這個時候其實需要注意避免一言堂，所以很多時候是通過出撲克牌的方式來達成整個團隊的一致的，可以通過多輪的出牌，一定要整個團隊都對這個分數表示同意為止。使用Point的評估方法相對難操作，但好處也是顯而易見的，通過每個release point的數量可以非常明晰的瞭解團隊生產力的變化。
這個階段通常需要在1~2天完成，一個好的planning對於整個release的成功與否至關重要！好的開始以為著成功了一半！
Plan結束後我們會在VersionOne/Jira Agile系統中填入所有資料：
Development Sprint
Daily Scrum Meeting: 很多團隊都是使用這個，每天的scrum站立會議，通常是每個成員介紹自己昨天的工作，今天的計劃以及碰到了什麼問題。這個會議一定要強調效率，15分鐘內解決，所以超過10人的團隊建議拆分分別開這個會議。Scrum Master在這個會議需要起到一個計時的工作，保證控制會議的節奏，如果碰到複雜問題一定要會後再討論，不要陷入無休止的討論中。
每人都要及時記錄自己做的任務的情況，做了多少，還剩多少。這樣可以產生一個非常有用的圖表，Burndown Chart。這個圖表可以很容易看到專案進展的情況。
Release Sprint
這個階段是為了穩定產品質量，為釋出做準備。我們採用標準的Git flow來管理程式碼庫。
在Release sprint開始的時候，我們會從develop分支checkout出Release分支。在Release分支只接受bug fix的commit，在develop分支依舊可以提交新功能，不過這時提交的新功能是要到下個釋出週期才會釋出的。
釋出的標準：
-
沒有高優先順序的問題
-
沒有regression的問題，就是以前版本是好的，新版本導致
釋出時，將release分支的程式碼同時merge到develop和master分支，並在master分支上打上標籤。
每個release結束後還需要retrospective meeting, 大家可以總結，並進行不斷的改進。
Scrum是個相對完善的專案開發模式，各種工具也非常完善。我覺得需要注意幾點：
-
固定的釋出週期：這樣可以培養良好的開發迭代的週期性，同時也容易可以評估每個週期的效率。
-
產品團隊和研發團隊的時間是不一樣的，一般產品團隊工作要提前1~2個星期，保證研發團隊不會因為需求的不明確而影響效率。
-
避免需求的變更，無論何種開發模式，需求的變更總是不可避免，所以最好是將週期縮短，可以讓產品團隊可以忍受延遲些時間來實現這些變更的需求。
-
要預留一定的buffer，畢竟程式設計師也是人，也會有不能出活的時候，也需要學習分享知識，所以不要把時間完全填滿，留給大家時間調劑。