淺談一下“敏捷開發”

為什麼需要敏捷開發

　　在以前，軟體專案的開發都是以年來計算的，這代表什麼意思呢 ？需求設計了半年多，方案設計做了半年多，開發了三年多，測試了半年多，修改Bug用了半年多。總計花了很長很長的時間，然後上線後發現有很多需求已經不存在了，同時又出現了很多新的需求。

　　怎麼辦？繼續改。這一改又是半年多的時間過去了。使用者的需求還再改，怎麼辦？

　　這是困擾軟體開發專案的最大的問題，越大的專案，參與的人越多，風險越大。文件越規範，維護起來的難度就越高，導致專案中遇到的問題越來越多。

　　不僅僅在以前，就是在現在，也是經常會有團隊出現這種問題。不相信，可以對比團隊中看看是否遇到了以下這些問題：

• 需求總是在變動，反覆變動，無限拖延。
• 開發工程師做出來的專案，bug不但多，而且經常改不好。常常是改了一個Bug，出現另一個Bug，好不容易把一個Bug改好了，過了沒多久又重現了。原本好好的功能，反而會因為改Bug導致出現的問題更多。
• 做出來的東西完全不是產品經理想要的樣子，溝通完之後才發現開發工程師的理解和產品經理的理解是完全不一樣的。
• 專案延期不是最壞的結果，最壞的結果是還從不知道專案倒底會延期多少，根本沒辦法去衡量工作量，團隊的成員都在加班加點，然而完全看不出來問題出在什麼地方。
• 開發文件，產品文件，介面文件，測試報告和真實的程式碼從沒有完美契合過。產品經理設計出來的原型和UI設計出來的頁面和程式設計師開發出來的程式碼完全是一種不同的體系，三位一體的故事從沒有真正發生過。程式碼的實現和介面文件根本不一致，最後索性乾脆不看介面文件，完全口頭交流。出錯的時候各種撕逼扯皮，誰也分不清倒底誰錯了。
• Team的戰鬥力和凝聚力不強，經常是對著幹，對分配的任務總是各種報怨，出現問題之後第一反應是這個不關我的事，不是我的問題，是後端前端設計QAPM的問題。

　　如果遇到了這種情況，那就代表真的需要敏捷開發流程了。

敏捷開發包括了哪些內容

　　敏捷開發總的流程如下：

• ​需求規劃和分期​
• ​需求評審​
• ​需求講解​
• ​方案評審​
• ​每日晨會​
• ​效能測試​
• ​CodeReview​
• ​Demo​
• ​測試階段​
• ​線上Bug修改流程​

　　如果要解決這些問題，這是我目前看到的最佳實踐，每一個節點都非紙上談兵，而是經過無數個嘗試和失敗總結出來的

1.One Team

　　​產品和開發必須是一個Team，大家只是分工不同，角色不同，並不是兩個對立的團隊。​

　　絕大部分公司的產品和開發都是分開的，那麼產品和開發之間的糾紛一定無限多。

　　不要因為出了問題，說這是產品設計出來，這是開發團隊實現不了的。這是一個開發小組所有人的責任，這個後果是所有的人都需要承擔的。如果我們認真的區分這是什麼問題，那麼也只是為了避免下次出現同樣的情況，使用者只會知道是一個公司出了一款垃圾產品，沒有人關心到底是產品還是開發的鍋。

　　這是做敏捷開發的大前提。或者不僅僅是產品和開發，責任共擔，​One Team​這個理念是貫穿始終的。這並不是說，大鍋飯，而是說，面對不好的結果，所有Team的人都必須共同承擔。出現問題的原因僅僅是為了追溯和重現當時的場景，以避免後續會出現同樣的情況。

　　產品和開發必須是一個Team還體現在需求分期上。這一點在講到需求分期的流程的時候，會提高的。實際上，需求分期如果沒做好，敏捷開發只能流於形式。

　　需求分期怎麼做，這是​MVP（​Minimum Viable Product：最小化可行產品​）​的事情，簡單來說，每一期都要有一個提前的預測，這一期裡要做的所有的功能都只為了檢測自己的預測是否正確。並根據結果去不斷的調整開發規劃。

2.職責明確

　　​每個人要負責的事情必須清晰無誤，誰該做哪些事情，必須要提前講清楚。​

　　開發團隊的推薦角色應該是這樣的。

• PM 1個
• UI 1個
• web前端 1~2個
• 後端開發 2~4個
• 終端開發 1~2個
• QA 1個

　　這是一個相對平衡的模板，這樣的一個7~10人的小Team，是可以複製的。敏捷開發支援多個Team並行開發。理論上來講。這種方式，可以支援五到六個小Team同時啟動。

　　多Team併發寫作的時候，除了這些專案小組的角色，還有各個Team的Leader。我比較推薦小組分成如下幾種：

1. 產品Team 產品團隊
2. 使用者體驗 Team 傳統的UI團隊升級為UE，升級為整個系統甚至是公司的使用者體驗師。
3. 後端Team 苦逼的後端
4. 前端Team Android/IOS/JS 一個前端工程師應該三者通吃。可以在某一個客戶端上了解的更深入，但是普通的專案上手還是應該沒有問題的。
5. QATeam QA 需要做功能測試，迴歸測試，邊界測試，效能測試。

　　那麼來描述一下每個角色的不同職責。這些不同的角色牽涉到團隊並行開發，並不是簡單的隨便扒拉到一堆就好了的。

​　　PM​ ： PM的職責並不是畫原型，而是去分產品的分期，確定產品要做的功能和優先順序。對於產品來說，最大的職責並不是將原型畫出來，而是要證明自己要做的功能是合理的。如果你證明不了自己要做的功能是合理的，是值的嘗試的，就是產品經理的失職。

　　可以參考MVP，有無數的辦法可以提前驗證，如果不能夠提前驗證，那麼就證明這是有風險。做為PM，一定要有這種風險的意識，要知道自己身上擔負的責任，PM花了兩週時間設計的原型，8人的開發團隊要折騰近三週左右的時間。

　　原型和產品文件都是輔助的東西，我甚至不推薦產品經理去做原型設計，只拆分Story。原型設計交給傳統的UI更合適。然而在真實實施的過程中，因為很少有UI具備原型的設計能力，所以實施起來會有一些難度。這個不算特別重要，慢慢培養。

　　PM不需要為開發進度負任何的責任，這很重要，不要把PM當成專案管理來使用，如果你讓PM去做了專案管理，恭喜你，Game 近乎 Over，產品經理沒有時間再去思考如何做功能了。PM的職責就是把功能設計好，優先順序排好，給開發團隊講清楚需求，結合Story優先順序和功能實現的大概時間點去做排期。

　　開發工期交給開發團隊去做，Bug會和QA，開發團隊一起來定。記著要在開發團隊開發專案的時間裡，去做好下一個產品迭代的設計。

​　　小組Leader​：需求評審會的成員應該包括PM組的Leader，前端組的leader,後端組的leader,測試組的Leader，或者是其他公司的中層骨幹。這應該是一個公司所有應該為這個專案負責的人的評審會，在評審會上的結論，就應該被堅定的執行下去了。不參與評審會的人，不應該再對需求指手畫腳。

　　需求評審會的目標就是確定原封不動的需求，所以在這裡要格外的注意，PM拿出來的方案設計，一定是完整的，而且必須評細節。如果說，一個公司的中層骨幹經過需求評審會議，仍然需求亂成一比，那就沒什麼可說的了，繼續努力提升自己的水準，或者是補充真正的中層。而PM的目標就是

　　吸引需求評審會的意見，儘量讓自己的需求和設計通過評審。

　　各個小組的Leader還應該承擔的角色就是各個組的方案評審。這是中層骨幹必須要起到的作用。小組的Leader還應該負責專案中風險的調控，考慮是增加人手，安排加班，專案延期，還是調整功能。

　　與些同時，應該去稽核最後的效能報告，看看是否達到系統的期望值，遇到了疑難問題如何解決。

　　​開發組成員：​專案進入真正的開發階段後，開發組的成員就應該是主動去控制專案的進度，和風險，以及主動去測試專案中存在的問題，在這個階段，除了一些需求不明，或者是發生變動的情況出現，不應該去打擾產品經理。不要讓產品經理做開發團隊的保姆。

　　開發組的成員的目標就是做好專案的進度控制，有風險就及時反饋給Leader，確保自己理解的需求是明確無誤的，確保自己的測試是完整和嚴謹的，確認自己寫出來的程式碼是可以維護的。

　　一定要理解清楚，一旦PM通過Story講解，將需求交付給開發組成員，那麼開發組成員就應該主動而獨立的為這件事情負責。

　　當專案完工以後，開發組成員應該交叉去做CodeReview，並且出效能測試報告，以及組織Demo。

​　　測試組成員​：測試級成員的職責不是做功能性的測試，也不是做效能測試。而是應該做邊界測試和迴歸測試。功能性的測試主要應該由開發組成員完成，除了一些特別麻煩的，需要各種極端條件才能復現的，正常的操作過程中出現的問題，都應該是有開發組承擔。效能測試同樣是開發組人員自行完成，各小組Leader只需要知道一件事情，測試報告是否能夠通過。

　　所以測試組的主要做的就是準確的記錄，以及bug的統計。也不應該去天催促開發組的成員去改Bug。只需要去反饋給開發組的Leader就好了。整個CTO或者是技術總監應該以此為標準去衡量每個小組Leader的績效。

　　迴歸測試是需要做的，但是也不是完全必須要做。如果能夠積累足夠多的自動化測試用例，就去正常使用它，如果不能，就儘可能少的減少迴歸測試。這需要跟開發人員溝通的比較清楚，他們往往更清楚，什麼地方容易出問題。

　　接受線上的反饋並且記錄也應該是QA的職責，如果Team足夠細，可能會有運營或者是客服統一對外收集，然後交給QA，QA再負責錄入Bug系統中。

　　基本的敏捷開發流程中的角色的職責大致就是這樣的了。這不是一件容易的事情，其中的很多小細節，都照顧到了每個角色的職責和義務。理論上來說，如果有一張圖的話，可以更清楚的畫出來不同角色的功能。

　　這種職責的劃分，和傳統的職責會有一些不同，目前來看應該算最高效的，也是最能發揮出團隊的能力的方式。

3.主動承擔

　　​每個人必須學會主動去為自己的事情負責​

　　當有了第二條，很快就能發現團隊中，誰是能夠盡守職責，更主動的人。第3條很難做到，特別在很多公司，並不注重對於團隊凝聚力的培養，也不會注重和他們之間的交流，不知道他們想要什麼。

　　所以敏捷開發並不僅僅是一個開發流程，更是一種管理的方式，他牽涉到績效考核，公司福利，上下班制度等等你看不到的東西。

　　如果說團隊成員並不能做到為自己的事情負責，那麼需要的做就是，要麼就是去更換團隊，要麼就是想辦法去激勵團隊。

　　這件事情其實也不算難，第一，明確這種職責的分工是合理的，第二，Leader都需要了解自己的團隊的狀況。第三，不斷的去強化和培養這種做事的習慣。

　　團隊是需要打磨和改造的。這三點是敏捷開發實施的前提，而不是說，有了這三點，敏捷開發就一點能做好了。

　　在具體的實施上，還有無數的細節是需要去整理和落地的。

SCRUM工作流

　　在講述流程之前，先介紹一下Scrum中的幾個角色：

• 產品經理。分析使用者需求、提出產品方案，為客戶負責。
• Scrum Master。負責協調整個Scrum過程，還要負責Scrum的各類會議
• Scrum 團隊。包括研發、測試等。

　　Scrum的主要步驟

建立產品需求列表（Product backlog）

　　一個產品的需求可能來自客戶、團隊或者產品經理的想法，這些需求的描述必須符合：

　　作為__​，​我希望___,以完成____,這樣的好處是讓整個團隊更容易理解需求，達成共識，圖為一個例項：

　　產品經理需要將需求初步篩選，並準備進入下一個步驟---Sprint（開發衝刺階段）

建立開發需求列表和制定開發計劃

　　首先，你需要確定每次Sprint的週期，短的週期可以更頻繁的釋出產品版本，因此可以從客戶那裡更迅速地收到反饋，修正錯誤。當然，你也可以讓週期變得長一些，比如2周的時間。這樣可以讓開發人員更投入地工作。

　　之後，Scrum可以去篩選產品需求表列，和產品經理、團隊一起根據需求的重要性、開發量來制定開發優先順序。開發團隊一旦接受這些開發任務，就應該準時完成，不得修改交付標準。

執行Sprint（開發衝刺）

　　所謂Sprint，就是在一定時間內全身心投入開發。這個階段通常用看板來管理需求，每個卡片就是一個開發任務，工作完成後，可以將卡片移到下一個階段，用看板管理需求長這個樣子：

　　你也可以使用專門的軟體來管理看板，例如國外的Jira，國內的禪道。

　　其他的，還要有一個每日的Scrum會議，會議的目標是討論當前的任務的狀態，一個推薦的彙報形式是：

• 我昨天已經做了什麼
• 我接下來準備做什麼
• 現在遇到什麼阻礙和問題

　　此外，你還需要一個燃盡圖還幫助瞭解還有多少任務沒有完成，每次開完會更新一下就行了

測試和產品演示

　　因為每次的Sprint目標就是交付一個可以用的產品特性，所以測試工作非常重要。有不少方法可以減少測試周期，比如，你可以減少需求數量，或者讓開發參與測試。

　　每個Sprint結束後會進行一次產品演示，由開發團隊向所有人展示他們的開發成果。

專案反思會和下一個Sprint計劃

　　專案反思會的目的是討論交付的成果和下一步如何改進工作，哪裡做得好、哪裡不好都可以提出。確定了改進方向，就可以專注於下一次Sprint了。

結論

　　Scrum的最大特色是靈活和增量交付，要求團隊之間有開放的溝通和協作。首先是由產品經理收集和整理需求，然後和開發團隊確定開發列表，接著進入Sprint（開發衝刺狀態），後面就是日常開會、後期改善。