Scrum敏捷开发
什么是Scrum敏捷開發
Scrum是敏捷開發的一種，是一種以人為本，迭代式增量軟件開發的過程，以英式橄欖球爭球隊形（Scrum）為名，因此可以想象，整個團隊是高效而富有激情的。以人為本，即Scrum開發特別強調溝通，要求團隊所有人員都坐著一起工作，通過高效的溝通解決問題。
為什么要敏捷開發
傳統的軟件公司大都是使用瀑布開發模式，流程是以下這樣的：
瀑布開發模式
瀑布開發模式一般都需要很久的開發時間才能交付，筆者目前所在公司，以前開發產品都是利用瀑布開發模型，往往需要至少三個月到半年的開發周期，而過程往往都是這樣的：產品經理完成一款產品的所有需求—UE設計出原型和視覺— 開發完成開發— 測試完成— 產品經理和UE驗收的時候永遠是一副不可思議的驚訝表情，覺得交付的產品和自己當初的設計相差甚遠，這個時候就會出現很糾結的事情，改？還是不改？改，牽扯到軟件結構，項目周期，交付時間等一系列問題；不改，產品最終效果無法交付。因此最終的結果都會是稍微改一點，即產品結果接近而不同于原本需求，所要增加的人力和時間成本又不會太高。另外還有一種情況，就是開發過程中遇到不可抗拒的需求變更，這個時候對開發的架構、交付日期都有非常大的影響，經常出現一個變更導致前3個月甚至更久的工作返工白做，而這個時候浪費的成本是非常大的。久而久之，會發現每次的產品開發都是這樣一種令人疲憊的模式。
上述這種情況，我相信有很多團隊都會遇到，而且很普遍。當然這里有最大的問題是，產品經理和UE交付了需求和設計之后，則和開發團隊的溝通變得很少，開發和測試團隊遇到問題，也很少和產品經理溝通。這里原因很復雜，可能和人有關，可能和公司文化或者公司流程有關。當然，這不能說是瀑布開發模型的錯，只能說瀑布開發模型比較容易出現這種問題，原因很簡單，開發周期越久，不可控的因素和風險就越大，最終的結果就越容易偏離最初想法。
而敏捷開發的流程是這樣的：
迭代瀑布
可以看出和瀑布開發模型的區別了嗎？就是將一個完整的瀑布開發過程切成很多個短的，迭代式的瀑布開發過程，即迭代瀑布。那么這么做，就一定能解決上述遇到的問題嗎？本文將在最后給出答案。
Scrum的模式和流程
標準的Scrum開發模式
以下是標準的Scrum開發模式：所有的需求都到達PO/PM這里，整理出Product backlog，每次的迭代開發（Sprint）都是PO/PM從Product backlog里挑出需要開發的部分需求，然后團隊一起開planning meeting，確定出sprint backlog及交付日期。接下來利用2到4周的時間進行開發和測試，其中每天都要開站會（Scrum meeting），團隊內部成員在這個會議上了解整個迭代的進展情況，最終交付后，團隊一起開sprint review和retrospective會議，而這整個過程都有一個很關鍵的角色Scrum Master來把控和組織。
?
標準Scrum開發模式
這樣描述可能還不太理解，下面則進行詳細的分類描述。
開發周期
Scrum開發一般建議為2-4周為一個周期，以兩周為例，整個時間線大概如下，可以看到第一個迭代的結束和第二個迭代的開始是有重合部分的。
?
Scrum開發周期
三三四原則
Scrum開發有一個“三三四”原則，即三個角色、三個產出物、四個會議：
-
三個角色：PO、Scrum Master、Dev Team
- PO：Product Owner，一般都是產品經理，負責需求分析和整理、分解驗收story、維護Product backlog等（關于backlog和story會在下面有詳細的描述）。
- Scrum Master：扮演推動者的角色，他要負責主持會議、協助團隊內部成員解決困難、解決外部對團隊內部的過分干擾、和外界的主要溝通工作等。Master可以由專門的人來擔當，也可以由團隊內部的成員來擔當，很多團隊都是由PO來同時兼任Master，筆者建議由團隊內部成員輪流擔當，這樣能夠培養團隊成員的責任感，增強團隊的凝聚力，并讓大家更加容易理解敏捷開發的精髓。
- Dev Team：整個開發和測試團隊，包括UI設計師等所有相關人員。
-
三個產出物：Product Backlog、Sprint Backlog、Potential Shippable Product Increment
- Product Backlog：產品需求池
- Sprint Backlog：此次需要開發的需求集合
- Potential Shippable Product Increment：可交付的結果
-
四個會議：Sprint Planning、Daily Scrum Planning、Sprint Review、Sprint Retrospective
-
Sprint Planning：需求評審會和迭代啟動會，這個會議上，需要得出以下結論：
- 全員明確清晰的迭代目標
- 澄清所有的需求及技術實現風險
- 評估需要的工作量，以及需要投入的人員
- 確定出所有最終需要發布的功能集合及工作量，需要將Story拆解成Task，以小時為單位。
-
Daily Scrum Planning：每日站會，顧名思義，就是站著開會，大家圍成一個圈或者半圈，這樣做有兩個目的，一個是高效，另一個是可以方便團隊所有人都可以看見對方。站會的目的有以下3個：
- 監督個人的承諾：確認個人是否完成昨日的目標
- 培養團隊文化
- 了解項目進展：團隊中每個人都應該了解其他人在做的事情，以及當前團隊的進展和風險。最實際的好處就是這樣可以清楚的知道別人做的事情是否對自己有影響，或者自己是否可以提供幫助等。
站會的時間，建議不超過15分鐘，只描述狀態和任務，不討論技術細節，另外，每個人圍繞以下3個話題來簡單描述自己的進展：
- 昨天完成了什么？
- 目前有什么困難，需要幫助的？
- 今天準備做什么？
站會的時候，Scrum Master一定要注意以下問題：制止不必要的討論、禁止小會、控制發言時間、不要跑題等，另外，站會的時候，Master需要修改燃盡圖（后面會有對燃盡圖的詳細描述）。
-
Sprint Review：迭代評審會，此次會議的主要內容是相關利益者及團隊成員展現本次迭代的功能增量，需要注意的是不展示未完成的功能，也不需要PPT，演示結束后記錄好相關反饋。很多采用敏捷開的團隊都不開Review會議，其實Review會議是有一定的好處和目的的：
- 可以讓團隊的成果得到認可，提升團隊的自我價值感
- 其他人可以了解團隊在做的事情
- 可以吸引一些利益相關者的注意，并得到一些反饋
- 演示能夠對團隊成員造成的一定的壓力，迫使團隊認真完成工作
-
Sprint Retrospective：迭代回顧會，會議主要是回顧此次迭代的整體情況，一定要全員參加，一起回顧此次迭代做的好的地方，以及需要改進的地方，并對這些需要改進的點，提出改進措施。
-
Product Backlog & User Story
-
User Story：即用戶故事，是一個解決用戶某個問題的，對用戶有價值的，某個功能的，一目了然的描述。這里有一個理念需要注意，即多個小故事勝過一個龐大的故事，因此User Story的描述非常重要，好的用戶故事具備INVEST原則：
- Independent：可以獨立開發
- Negotiable：可以協商
- Valuable：有價值
- Estimable：大小可評估
- Sized appropriately：合適粒度
- Testable：可測試驗證的
User Story的描述一定要站著用戶角度，而且一定要注意顆粒度，一般以這種格式”作為一個<角色>，想要<活動>，達到<目的>”來描述。另外，根據經驗，筆者建議描述的時候可以不用這種句式，但是思考的時候一定要這樣思考，因為所有事情，過分的追求形式就會失去他本身的價值，但是從這個角度去思考每一個需求和功能點，對產品經理分析需求確實有非常大的幫助。接下來舉幾個User Story的例子：
“圖片編輯功能“：不是一個好的User Story，首先顆粒度太大，其實大小不可評估，因此需要對這個需求做拆分，拆分成小的User Story；
”作為一個喜歡自拍，又希望自己可以拍出來比較白的用戶，可以通過圖片編輯的美白功能，使自己看起來白一點“：該Story是一個比較好的User Story，當然，思考這樣思考，記錄的時候，完全可以簡單描述為”圖片編輯增加美白功能“。
User Story的分解是一個技術活，對產品經理是有一定的要求的，當然，一切從用戶角度出發，多思考用戶場景，那么這個問題也就也就沒有那么難了。
-
Product Backlog：User Story的集合，即產品需求池，這里面包含所有和該產品相關的需求，根據筆者經驗，這些需求最好包含以下狀態：need to check、pending、reject、planning、developing、released、wait to dev，這些狀態基本包含了一個需求的所有可能的狀態，對產品經理管理需求有非常大的幫助。
看板 & 燃盡圖
看板一般是一個物理白板，目的是做迭代進展可視化跟蹤和協作溝通。看板上需要將每個人的任務，以對應的狀態（To Do/Not checked out、Doing/Checked out、Done）展示出來，一般使用便簽紙。
同時要在白板上畫出燃盡圖，燃盡圖指示的是當前剩余的工作量，是一個跟蹤項目進展非常好的指示器。燃盡圖上一般有2條曲線，如下圖的燃盡圖，灰色的直線表示的是最優剩余工作量曲線，藍色的表示實際的剩余工作量曲線，正常情況下，藍色的線應該在灰色的線上下浮動，并在最后一天合到同一個點上。燃盡圖可以在每天站會的時候由PO更新狀態。
看板&燃盡圖
關于看板和燃盡圖，有以下一些需要注意的點：
- 每個功能通過測試，且PO認可，才算結束；
- 白板上也要講測試、UE等的任務放上去；
- bug修復的任務可以估算出工作量，作為單獨的任務放在看板上；
- 延期的任務，應該注明延期天數；
- 只有完成的任務才在燃盡圖中刪減工作量，所以，如果增加了工作量，燃盡圖的曲線可能會向上。
一定要注意的問題
上述基本將Scrum敏捷開發的核心內容和工作流程描述完全，那么在實際操作過程中，難免會遇到各種問題，下面筆者將根據經驗，提出實操過程中需要注意的事項：
- 關于團隊，Scrum敏捷開發原則上是需要團隊所有人坐在一起的，但是實際情況中，難免遇到異地問題，異地問題確實會對Scrum的實施過程造成一定的困難，并且也會將效果大打折扣。百度為了解決這個問題，研發了專門用于解決異地敏捷開發的顯示器和看板工具，團隊每天面對顯示器進行開會和狀態溝通。當然，大部分團隊是沒有這種條件的，但是現在有很多在線Scrum開發工具來跟蹤狀態代替看板，比如Leangoo、禪道等，站會大家無法面對面，最簡單的辦法只能是采用電話會議。不過筆者建議，在需求啟動會、回顧會和評審會的時候，團隊部分成員最好出差，確保團隊所有成員可以面對面來開會，否則只要無法面對面，就會有大量的潛在風險，導致Scrum開發變成形式主義。但是，只要團隊沒有坐在一起，Scrum開發就會大打折扣，所以異地團隊在實行Scrum開發的時候需要做好這個心理準備。
- 站會的時候，一般可以由PO來移動任務卡片，這里建議由團隊成員分別移動自己的卡片，這樣做的好處是，可以培養成員的責任感，并在發生delay的時候，造成一定的壓力。
- Scrum開發的團隊成員一般建議在7人左右，不要超過10人，如果團隊成員太多，建議分成小的Scrum團隊，然后每個Scrum團隊的PO再聚到一起溝通狀態。如果每個Scrum團隊的成員過多，很容易造成效率的低下和溝通問題。
- Scrum強調的是團隊，因此是整個團隊成功或者失敗，而不是某個人，需要和團隊的成員強化這個觀念，來培養團隊的責任感。
- 需求評審會一定要確保所有人對需求完全了解，并達成一致的認可。不要覺得在開發過程遇到需求不理解再進行溝通，這樣會給此次迭代帶來非常大的風險。
- 很多情況下，站會往往會變成”匯報會“，即團隊成員向PO匯報工作，并且成員并不聽別人在講什么。因此，首先從PO這里，需要注意不要給團隊一種壓迫式的聽取匯報的感覺，并且，刻意地將站會培養成溝通會。
- Task的分解一定要注意工作量，工作量越大就會潛在越多不可控的風險，因此原則上，每個task不能超過8小時。
- 測試人員在Scrum開發中，很容易被遺漏掉，而導致測試過程中出現風險，比如不清楚需求，測試case沒有按期編寫完成導致測試delay等。因此從一開始需求評審的時候，就要注意除了開發人員，測試人員也要對需求完全理解。
- SW和VAL人員的溝通不積極，經常需要Scrum master或者其他人推一把，這個是很多傳統的IT公司的通病，尤其是進行瀑布開發時有非常嚴格的開發流程的公司，這種問題更加嚴重。工程師往往習慣了在系統上提交bug，查看bug，通過在系統上添加comment溝通的形式，而Scrum開發，強調的就是通過面對面溝通來提高效率。因此當團地成員出現溝通問題時，Scrum Master一定要提出來進行告誡。
- 產品的質量大于需求，這點是很多產品經理往往忽略的，和Scrum開發無關，而是做產品的基本要求。因為很多團隊在開發的時候，產品經理為了快速將需求投入市場，而忽略的產品本身的質量，結果導致用戶對產品較低的評價甚至產品死亡。Google數據稱，Play Store上60%的差評是因為產品質量。
- 以上提到的所有問題，或者這里沒有提到的，Scrum開發中可能遇到的各種問題，最直接的解決辦法就是”提高工程師的意識''，當然，這是最簡單，也是最困難的解決辦法，需要時間以及Scrum master的培養。
敏捷帶來的價值
- 快速響應變化，及時響應用戶反饋，調整優先級：Scrum開發可以完全適應現在互聯網開發里的”小步快跑“，以輕量級的Story作為需求進行迭代式開發，保證最重要的總是優先做。
- 可以持續向用戶交付有價值的軟件產品，以及短的軟件交付周期：這是現在的互聯網開發的基本要求，就是不停的通過每次迭代和升級，進行產品的優化和提升。
- 項目團隊的透明性：團隊所有成員都可以完全了解當前的項目進展和問題。
- 低的軟件成本：Scrum開發可以讓產品快速試錯，即使錯了，浪費的也最多是一個迭代的資源，而不會像瀑布開發，有可能浪費的是好幾個月的資源。
- 高的投資回報率：以較低的成本，和高效的模式進行產品的迭代，回報率當然會較高。
總結
首先，回顧下文章一開始的問題，文章開始提到瀑布開發模型容易遇到的2個問題；
第一，開發結束時，交付產品無法達到預期：Scrum開發將開發周期縮短到了2到4周，并且每天通過站會的形式進行狀態的溝通和跟蹤，團隊成員通過溝通來解決問題，這些工作方式理論上可以完全避免這種問題的出現。
第二，不可抗拒的需求變更，導致大量的資源浪費：根據上述敏捷帶來的價值，我們可以看到，小步快跑+快速試錯，即使浪費，最多也只是浪費2-4周的資源。
當然，Scrum開發只是幫助團隊減少上述問題的出現概率，而非完全解決，這里的核心不是瀑布開發模式或者Scrum開發模式，而是團隊責任感和意識的問題，沒有責任感的團隊，無論如何使用Scrum開發模式，也只會到徒有其表，甚至可能造成反作用，團隊成員為了敏捷而敏捷，沒有交付出好的產品，反而在這些形式上浪費大量的時間。所以，敏捷開發不是萬能鑰匙，有些領導一聽說敏捷開發，就要團隊去實行，結果往往造成更大的問題，因此，團隊出現任何問題，都首先要從根本出發，尋找問題原因，再進行對癥解決，Scrum開發模式只是辦法之一。
另外，Scrum開發里所有的工具和方法都只是協助，不要過分的依賴形式很重要，敏捷只是一種方法和理念，或者說是一種態度?，F在很多互聯網公司，雖然沒有在嘴上每天吵著敏捷開發，沒有看板，也沒有站會，或者將Scrum開發的流程“本土化”，但是他們依然敏捷，依然可以高效的開發和產品迭代，原因很簡單，使用了敏捷工具和流程并不是真正的敏捷，“敏捷意識”最重要。
作者：Monica_Wang
鏈接：https://www.jianshu.com/p/89e59933caad
來源：簡書
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。
總結
- 上一篇： Oracle数据库知识小结
- 下一篇： zoj 3762（求三角形的最大高）