記得剛畢業的時候自己很單純，滿腦子「技術（而且只有核心技術）在身，走遍天下的思想」；因而當時花了大量的精力研究CPU架構，作業系統核心，編程技術等等。自己當初的技術屌絲狀態今天仍然歷歷在目！
當然，隨著工作經歷的增多，我對於軟體行業的看法也在潛移默化的變化著。今天小編就以一位資深的軟體從業人員的視角，來給大家介紹一下軟體研發項目的管理模式之敏捷（Scrum/Agile）開發。
我入行軟體領域的時候還是瀑布模式的天下。從市場部給出市場趨勢結果，產品部門給出產品設計文檔，研發團隊進行技術評估，反饋，溝通，確定產品最終設計；最後，導入研發團隊進行任務細化，切分，安排開發任務以及對應的優先級等等。這一套過程走下來沒有幾個月是完不成的！因為這裡面包含的不僅僅是單個部門的工作，各個部門對問題的理解差異以及心理期望各不相同，這些需要有大量的溝通，協調來統一產品方向。
粗略估算，單這些任務基本上就會花上幾個月的時間才能完成。而這些僅僅是一個項目的開始，因為這個階段僅僅是給出了產品的目標結果，對於實際的開發過程以及產品質量保證環節都還沒有開始。
研發團隊拿到經過技術評估後產品需求，需要根據開發工作的特點進行細化，拆分，分配到開發人員手中；而開發人員也需要進行一些基本的軟體設計：給出接口文檔，架構文檔等；也需要與測試團隊溝通好測試的各種case，避免後續測試存在理解上的偏差。最後才是coding，release，測試。
說了這麼多讀者是不是覺得有點跑題了？非也！我們是要先看到傳統的瀑布模式對於目前軟體行業的局限，才能能夠深刻理解美國人發明「敏捷」的根源。那麼軟體研發有什麼特點呢？尤其是網際網路相關的軟體研發呢？一句話：「研發速度跟不上需求變化！」這一點相信大家都可以很容易理解。軟體行業尤其是網際網路行業，機遇無處不在，市場也無處不在，就看誰能夠快速抓住用戶需求的痛點並迅速搶佔市場份額，俗稱「圈羊」。如果慢了半拍就相當於將機會拱手送人。因此，快速決策，快速研發，快速投入市場進行營銷就是企業尤其創新型網際網路企業的命門！
試想，網際網路企業繼續使用「瀑布法」開發軟體，那麼從需求變更提出，到最終上線運營，營銷，這個周期一般至少要1年左右（產品需求定案3個月，5個月研發，4個月修復bug）！而且周期越長，風險越不可控制！輸的可能就越慘！對於做deliver業務的企業也會失去客戶的新人，畢竟客戶花錢還是很緊著看成果的。
不得不說，歐美人的洞察力跟分析能力，創新能力還是很強的。針對於這些問題， 他們提出了顛覆「瀑布模式」的全新項目管理模式：「敏捷模式」（Agile）。
什麼是敏捷（Agile）？我接觸這個概念最初在德企，我現在也非常感激當初的manager能夠將這個先進的東西介紹給我們的研發團隊。為了便於圈外人士理解，我需要介紹一點有趣的事情。
橄欖球在國內不是很流行，但是在美國以及英國卻是十分受歡迎的一種體育運動（大家別覺得我跑題了，容我慢慢道來）這個體育運動的規則相對自由，可以推人，抱人，絆人等等，反正我們常見體育運動裡面嚴重犯規的行為很多在橄欖球裡面都是可以接受的，尤其是美式橄欖球，也叫硬式橄欖球（因為全身穿戴堅硬的盔甲，頭戴安全帽而知名，目的就是保護球員），得分的方式是計算球朝向對方球門前進的yard，或者射門進球。
由於項目規則十分自由，導致球員的衝撞，對抗異常激烈；如果一個球員拿著球，站在原地不動，基本就會被球員壓成麵餅了！如果拿著球跑動，那麼後面將有千軍萬馬追著你，跟你搶球！目的就一個：想盡辦法搶奪對方的球，避免對方抱著球向自己的球門前進哪怕一個yard！
誰拿到球，那麼誰就是整個團隊的核心，所有的成員必須時刻幫助這位球員抱著球前進，並時刻準備著接球，成為下一波進攻（每次一波進攻的陣營被成為Scrum）的團隊核心！也就是說整個團隊是沒有一個類似固定的前鋒，後衛的概念的，每個隊員隨時都有可能成為整個比賽的焦點。
談到這裡我們應該了解道，其實「敏捷/Agile」的目標是實現像橄欖球運動那樣，高效，快速，小步伐的接近目標。而後面我們要提到的Scrum就是「敏捷/Agile」理論的一種實現方法（也有許多其他的實現方式，在此不做討論）。
準確的說，敏捷（Agile）是一種理論並非一種工程實現的方法，而後面的Scrum才是Agile的一種實現方法。敏捷（Agile）的核心理念是：將複雜的項目周期（主要是針對於瀑布模型的周期過長問題）進行切分，使之成為既不是太長也不太短的項目小周期（太長了就退縮回瀑布模型了；太短了會影響各個團隊的工作效率），稱為「迭代」周期（橄欖球中球保持在一個隊員手中，傳遞到下一個隊員之前的時間），每個迭代周期的邊界時間點（球傳到下一個人手中的時候），允許需求變更（其餘的時間點不允許需求變更）調整研發團隊的開發任務目標，同時開發過程中不強調過程，流程，文檔等傳統觀念的細節（規則比較自由），而是強調可用軟體的輸出（球的向前傳輸以及進球）；即一切工作的重心都要以可用軟體的交付為最高目標，其餘的事情都是可以降低優先級。
一句話總結：敏捷的核心是圍繞交付客戶滿意的軟體為目標的，所有的活動都要圍繞著這個主題進行。
下面我們來看看Scrum的運作方式。首先不是所有的團隊以及項目都使用Scrum管理，Scrum不是「萬能藥」，它是有局限性的，這一點要有清晰的認識。我們在此只是針對軟體開發項目來進行介紹。
首先，Scrum認為團隊是整個項目的核心資產。對於傳統的團隊（團隊人數過多，比如超過10人以上的大團隊；團隊人員素質不均的）不適合使用Scrum來管理，需要做相應的培訓，改造，轉型才可以成功。
Scrum要求團隊內的成員都是精幹的多面手。即每位成員無論是在技術的紮實度，廣度以及自我管理（時間管理，態度以及責任心）方面都是非常優秀的！因為Scrum在運作過程中每位成員隨時都有可能成為整個team的核心，即資源的調度者。我們應該可以想像一位憋足的資源管理者可以產生的後果吧？所以Scrum要求的團隊是精英團隊！
其次，Scrum適合項目周期緊，項目交付任務有明確目標的項目。比如，一個項目評估下來可能持續幾年甚至幾十年，那麼Scrum不適合；抑或是科研單位那種沒有明確目標的探索性質的項目也不適合使用Scrum管理。用我的話來說「Scrum是一個鋒利的短刀，適合快速的披荊斬棘項目；對於愚公移山這種項目，不合適！」
Scrum中相關的角色：
1. 團隊（負責把產品做出來，承擔研發責任；其實所有的一切都是為了讓團隊更加高效的輸出而存在的）
2. Scrum Master（整個團隊的老保姆，大到會議的主持，需求的變更，Scrum流程的實踐管理；小到團隊的開發環境不舒適，成員的情緒問題，開發測試設備等雜七雜八的都由這位負責）
3. Product Owner（產品需求提出方，以Backlog的形式給出，並定義開發任務的優先級，與研發團隊一起評估複雜度，對整個產品的業務成功與否承擔責任即ROI）
4. 其他相關人員（QA，UIUX等）
Scrum中的一些術語：
1. Sprint（衝刺）就是團隊的一個開發周期，就是常說的「迭代」
2. Product Backlog，PO梳理出的具有一定業務價值的工作任務，通常比較大，整個項目會被切分成許多Backlog並形成研發團隊的原始工作任務池。它有一個非常重要的屬性：優先級，這直接決定了哪些任務先做，哪些後做。
3. User Story（故事，我一直認為這個主流翻譯非常low，但我也找不到比這個好的翻譯了）與Backlog相比較，是團隊從技術的角度對Backlog的一種細化與分解並確認需求細節可投入開發的產物。User Story詳細定義了開發人員能夠執行的需求細節，以及質量的標準，複雜度等信息。
4. Task 是比User Story粒度更小的任務，不是所有的User Story都要分解成Task，按照實際需求來處理。
5. Sprint Daily Standup Meeting 每日的工作會議，不是為了匯報任務，而是要清除昨天的開發過程中遇到的問題以及今天要做的任務中存在的問題。
6. Sprint Planning Meeting Sprint開始前的計劃會議，決定下一個Sprint需要做的Backlog並進行分解形成User Story以及Task，形成可執行的任務
7. Sprint Retrospective Meeting每個Sprint結束後的會議用於總結上一個Sprint做的好的與不好的地方並給出改進調整措施。
8. Story Points由於開發工作分類不同（前端跟後端開發，Java與C++複雜度各不相同），造成同一個User Story的複雜度評估無法標準化（傳統的做法是 人/日）這種評估方法不夠客觀。為了抽象出不同勞動的複雜度，方便評估任務複雜度，做好風險控制，使用point作為無差別的單位做任務複雜度評估。通常可以將 1point=1.5 人/日計算即可
9. Kanban就是一個可以寫字的白板，用於在展會中管理當前Sprint的Backlog，User Story，Task的狀態，進度等。大致如下圖所示。
10. Burning Down Chart 燃燒曲線，用於管理任務的進度，工作的剩餘量的一張圖
11. Scrum軟體，用於方便管理人員管理Backlog，User Story，Task等工具
Scrum的運作框架如下：
Scrum/Agile並不要求所有採用這種模式的團隊嚴格遵守每一個原則，只要能夠高效，高品質的輸出可用的產品即可。現在比較流行的XP，Test Driven等開發模式也都可以與Scrum結合，達到更好的團隊管理效果。
本文為鏞人隨筆原創作品，侵權必究。註：文中圖片為網絡獲取，如有侵犯版權請及時溝通。