現在大多數團隊都在談敏捷開發，似乎覺得敏捷是軟件開發的銀彈。只需要實踐下一些敏捷開發的模式就能如何如何，其實我覺得不論是敏捷開發還是傳統的瀑布流開發都是有他們的市場的，取決於團隊人員構成，取決你的產品的屬性，所在市場的競爭環境。最終希望達到的目的都是一個：以最快的方式、最高的質量，實現所需的需求。
我最近所在的兩個團隊都是移動研發團隊，一個是在相對大型的外企內部面向企業級軟件，一個是創業型團隊面向消費級應用。第一個團隊我們是從傳統的瀑布流開發模式向Scrum轉變而來的，第二個團隊我主導整個研發團隊，結合了Scrum以及Kanban的，采用的是混合型的開發模式。
Scrum實踐
Scrum的基本概念我就不贅述了，希望快速了解的人可以一步到此。
我談下我們是如何操作的：
1. team角色的分配：產品，研發，Program Manager。產品提供業務的需求描述，MockUI。研發包括Scrum Master, Developer, QA，負責軟件的研發測試。Program Manager負責整個項目的進度控制以及對外team的溝通協調等等。
2. 使用的工具：VersionOne用於整個Scrum開發的項目管理，后期我們換成了Jira Agile，主要是因為我們也用Jira來做bug Track，分散在不同系統管理也是挺復雜的。代碼管理Github，文檔管理Confluence，測試用例TestLink。
3. 流程：
我們以一個月作為一個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系統中填入所有數據：
| Epic | Backlog | Task | Effort | Developer |
| EP1 | feature1 | taskA | 1 | MemberA |
| taskB | 3 | MemberB | ||
| feature2 | taskC | 8 | MemberA | |
| EP | feature3 | taskD | 5 | MemberB |
| feature4 | taskE | 3 | MemberA |
Development Sprint
Daily Scrum Meeting: 很多團隊都是使用這個，每天的scrum站立會議，通常是每個成員介紹自己昨天的工作，今天的計划以及碰到了什么問題。這個會議一定要強調效率，15分鍾內解決，所以超過10人的團隊建議拆分分別開這個會議。Scrum Master在這個會議需要起到一個計時的工作，保證控制會議的節奏，如果碰到復雜問題一定要會后再討論，不要陷入無休止的討論中。
每人都要及時記錄自己做的任務的情況，做了多少，還剩多少。這樣可以產生一個非常有用的圖表，Burndown Chart。這個圖表可以很容易看到項目進展的情況。
在整個Dev Sprint里面，測試團隊是和開發團隊緊密合作的，測試應該是在整個開發周期最開始就介入，一起討論需求，一起評估，同時寫測試用例，不斷進行新功能的測試以及迭代測試。理想狀態下3個星期的開發周期內，開發和測試一直是同步的，3周內開發完成，新功能測試也基本能完成。
Release Sprint
這個階段是為了穩定產品質量，為發布做准備。我們采用標准的Git flow來管理代碼庫。
在Release sprint開始的時候，我們會從develop分支checkout出Release分支。在Release分支只接受bug fix的commit，在develop分支依舊可以提交新功能，不過這時提交的新功能是要到下個發布周期才會發布的。
發布的標准：
1. 沒有高優先級的問題
2. 沒有regression的問題，就是以前版本是好的，新版本導致
發布時，將release分支的代碼同時merge到develop和master分支，並在master分支上打上標簽。
每個release結束后還需要retrospective meeting, 大家可以總結，並進行不斷的改進。
Scrum是個相對完善的項目開發模式，各種工具也非常完善。我覺得需要注意幾點：
1. 固定的發布周期：這樣可以培養良好的開發迭代的周期性，同時也容易可以評估每個周期的效率。
2. 產品團隊和研發團隊的時間是不一樣的，一般產品團隊工作要提前1~2個星期，保證研發團隊不會因為需求的不明確而影響效率。
3. 避免需求的變更，無論何種開發模式，需求的變更總是不可避免，所以最好是將周期縮短，可以讓產品團隊可以忍受延遲些時間來實現這些變更的需求。
4. 要預留一定的buffer，畢竟程序員也是人，也會有不能出活的時候，也需要學習分享知識，所以不要把時間完全填滿，留給大家時間調劑。