談一談你身邊的敏捷開發，老闆想從敏捷開發中得到什麼？敏捷後，老闆和團隊成員從敏捷開發中得到了什麼？
結論放在前面：敏捷開發的最終目的是磨合團隊更好的協作。並且，我認為有關於各類方法論的最終目的都是這個；對老闆來說，滿足需求比之前快、效率高； 對團隊來說，相互協作更好、隊員能力提高；
前段時間，我們發現開發過程有些混亂並且不容易管理，為了團隊更好的協作，我們在顧問的引導下，開始嘗試使用Scrum敏捷開發。（Scrum相對官方的資料，附在文章最後）
幾輪Sprint下來，有點個人體會，和大家share之。立場當然是是不褒不貶，純客觀描述啦，不過，每個團隊情況不一致，因此，這個「客觀」針對的是我們團隊。啊哈~
首先，Scrum的官方流程如下：
我們的Scrum流程如下：
接下來會詳細講解每個步驟中應當注意的點：
|| 開發前：
1、闡述調整需求：
①產品要在這之前需要考慮清楚每個需求的邏輯、頁面交互展示，不然在這一步就會造成很多討論，延長開會時長，影響效果。至於如何思考清楚內在邏輯，有多鍾方法，這又是一個topic；
②對於優先順序的確認，一定要明確，這是後面實現的先後基礎；
③如果程序猿們對某個需求邏輯提出質疑的話，最好不要太任由發散討論，能立刻調整的，那麼就調整；不能立刻確認調整的，先保留，然後在真正開發前要確認；
④如果產品汪在闡述需求的同時，開發人員們開始相互溝通如何實現的問題，那麼建議開發們先聽完所有內容，在後面的需求分解中再進行詳細討論，不然在需求源頭錯過就容易有需求上的認知偏差；
2、需求分解為任務：
①小團隊沒有項目經理的情況下，建議項目負責人（Scrum Master）是經驗比較豐富的技術人，這樣對項目進度比較容易有把控，同時對需求的分解以及後期的追蹤會有很大的幫助；
②要強化需求追蹤人（Owner）追蹤需求的意識，不要流於形式：有個這麼個角色，但是並沒有發揮作用這種情況。owner的存在可以分擔SM的責任的同時讓開發人員之間關聯性更強，因為一般某個需求會同時涉及到前端、後端、API、移動端，讓開發去推動開發；
③開發人員們要適當把需求拆的細一些，這樣在拆的過程中更容易吃透需求、理清邏輯，發現邏輯上的問題。針對需求，相關的人進行技術討論，有疑問的地方要及時和產品這邊溝通，問題越早發現越好。最後，要把每個任務對應的人以及需要的完成時間都記錄下來。
有關於時間預估問題，我暫時還不知道哪種方法比較好。在文末最後有個敏捷估算的方法，乃們可以參考看看。
④在拆分的過程中，SM最好能夠根據需求的難易程度，進行輔助溝通。這樣，能夠相對避免因為具體代碼人員因為經驗/能力不夠而導致的拆分、預估問題；
⑤產品汪要在討論過程中，時刻穿插在其中，盡量保證需求理解的正確性；
3、確認該期目標：
①完整過一遍每個需求的分解情況，看是否有遺漏或者誤差，有疑問即刻提；
②必須按照需求的優先順序來確認目標；
③要明確目標，確認哪些一定要做完（這裡有個argue/挖坑的地方，會在下文「開發中」-「3其他」-2中進行描述）；
|| 開發中：
1、有關中期會議：
①一定要在一期sprint的中間進行進度回顧和確認，如果進度偏差很大的話，要適當的調整目標，以免最終跟預期相差太大；
②中期的時候，可以check下人力分配，如果有相對空閑，那麼可以再安排一些任務。看不同情況，是安排產品線的新任務還是基礎建設任務或是代碼優化任務等等；
2、有關測試：
①在開發過程中，建議開發完一個功能就跟進一個功能的測試，以免最終測試任務都堆積起來；
②提測可以在項目結束的前2-3天開始，這樣可以保證有足夠的時間進行修正；
③如果功能和業務強關聯，可以讓業務人員在提測階段使用測試版本，一起發現問題；
④開發人員在開發新功能過程中，可能會遇到之前存在的bug或者突然發現了之前沒發現的bug，這時候應該要告訴測試人員跟進，而不是自己直接修掉。因為你以為的修掉並不一定真正沒問題，一定要進行回測，同時留下記錄，可能會給以後的追溯帶來幫助；
3、其他：
①團隊每天開站會，目的在於描述自己的進度情況，一定要明確！要明確！要明確！如果不明確表述，其實等於沒有開站會；
②在適應新開發流程的初期，SM最好能夠每天or每兩天確認下組員們的真實開發情況，包括進度and需求理解上；
③一開始嘗試Scrum敏捷開發時，容易預估（目標、時間）不準確，導致2周一個迭代版本比較困難，可能會經常延遲。面對這種情況，我目前是傾向砍掉部分需求，先滿足2周一個版本，讓團隊先形成這麼一個周期慣性，再去優化慣性內的效率問題（也就是之後再提高目標的要求)；
Scrum要求是：
1&>目標、質量驗收標準不能改變；
2&>完成目標的要求不能過低；（文末有相關資料）
關於如何解決這個問題，也還在摸索狀態 T_T，大家如果有好的建議和想法，求溝通呀~
|| 開發後：
1、組員們要一定總結下這期開發中存在哪些問題，如何解決或者減弱這些問題的影響，不要流於形式。畢竟對團隊來說，這是新的開發流程，不適應或者做的不好很正常，不要怕說不要的地方，大家在錯誤中磨合、改善、成長才是最重要的；
2、結合上一點，每期也要對上期提出來的問題進行回顧，看在這期中是否有改善這個問題。只記錄不回顧，等於什麼都沒幹；
以上，是目前的一些體會和總結，希望在不斷實踐中，能夠得到新的解決方法和體會...
-----------我是Scrum資料的分割線-----------
什麼是Scrum？
Scrum,敏捷開發,敏捷實踐集
Scrum團隊的三個角色？
Scrum,敏捷開發,敏捷實踐集
Scrum的三個工件？
Scrum,敏捷開發,敏捷實踐集
Scrum的五個活動？
Scrum,敏捷開發,敏捷實踐集
敏捷估算？
Scrum,敏捷開發,敏捷實踐集
sprint？
Scrum,敏捷開發,敏捷實踐集
每日站會？
Scrum,敏捷開發,敏捷實踐集
完成的「定義」？
Scrum,敏捷開發,敏捷實踐集
我帶領開發團隊已經5年了，使用scrum敏捷開發已經兩年多了
總結一下敏捷之前和敏捷之後的不同敏捷之前
一個項目跟一個並不是緊密相連的，兩個項目之間經常會有空擋，這些空擋做大項目不夠，做小項目不能保證完全填滿，因此人力資源利用率不佳。而且經常有項目做到一半插任務的事情，開發人員對此苦不堪言。從CTO的角度來講，每周的周會都會很生氣，因為經常有項目delay，甚至於delay兩倍時間的情況都會出現。在此背景下公司開始敏捷了敏捷之後對於項目成員來說，最大的感覺是項目插任務的情況大大改善了。對於管理者而言，人力資源投入在開發上的利用率沒有上升太多，但是管理便利性和靈活性大大改善。但是對於CTO來說，還是很苦惱，因為敏捷之後都走產品開發，項目太少，每周彙報的時候都不知道人力資源用到哪裡去了，只知道某某產品第N階段開發花了多少資源，不知道這些資源都怎麼花的，因為一個數百乃至上千人的開發部，總不可能在開周會的時候把產品一個個拉出來演示吧 笑~~~~~~~~~~~~~我只用過敏捷Scrum，以前有過幾個人的小項目，除了我和一個測試，其他全是程序員，在這個過程中，我發現老闆用敏捷是為了快速交付增值的版本讓大老闆看到他的效率。對團隊成員來說，我覺得非常有用的Sprint Retrospective會議，每次這個會議中團隊成員都能去總結自己不足的地方，分析應採取的措施，想出有助於提升團隊的流程優化方法。慢慢的也發現，這種體系的團隊，大家自然而然的把主程序當做了Product owner，但是我的老闆也說過程序員都有一個通病就是習慣於從程序的角度考慮優先順序，而不是用戶的角度，這也導致了幾次版本發布延期，或是功能做出了後根本沒法用。老闆也默認了這個PO，作為Scrum Master的我就十分痛苦。。。。所以我的收穫就是，千萬不要讓程序員當PO，無論是PO還是Scrum Master，最好一定是全職的，而不是兼任的，尤其不要讓程序員兼任。
來自轉載 知乎作者@羅聰翼
敏捷實踐之路
敏捷實踐之路|BlenderGET
一、幾年前，產品團隊實踐SCRUM的感悟：
1. 團隊項目流程方法清晰明確。較之之前的工作流程，SCRUM框架清晰，簡潔，能夠比較大的程度上減少流程制度給研發團隊帶來的遲滯。
2. 團隊目標感增強。每一個sprint迭代，通過計劃會議，都會使團隊對sprint時間盒內要完成的工作目標異常清晰。
3. 團隊溝通意識加強。SCRUM要求團隊是高度自主，自組織管理的。大家在這個組織原則下可以進行更大可能的積極溝通，尤其是研發和測試人員，積極的溝通交流極大地提高了工作效率。
4. 團隊成就感增強。每一次sprint評審會議，團隊成員都會自豪的展示自己的工作成果，從而提升了成員的自信心和工作熱情。
5. 產品質量加強，實現了快速增量交付。周期一致，有節奏感的sprint迭代，嚴格透明的評審，使團隊中的每一個人都能夠時刻關注工作質量，從而加強了產品質量。
二、近來，產品團隊實踐用戶故事的感悟：
1.便於團隊成員內部快捷地達成真正的一致，節省了溝通成本
2.便於迭代的精準計劃、價值導向的適應性調整，增強了團隊成員的目標感
3.便於快速穩定交付，提升了團隊的效率產能
4.便於用戶提供業務場景層級的價值反饋，提升了用戶驗證的質量
5.促進團隊從關注任務到關注價值的思維轉變, 增強了團隊整體對產品業務的理解，提升了團隊的凝聚力
以上兩個總結均來源於我的敏捷教練實戰案例，具體可以參看我的知乎專欄《精益敏捷與項目管理踐行路》。
推薦閱讀：
※如何評價網路熱文《 Scrum 行還是不行 》？
※scrum工具大家有什麼推薦？
※如何有效的在一個研發團隊中推行Scrum？