騰訊敏捷之道，實施敏捷開發,看我就夠了

簡單的來講，敏捷的意思就是反應迅速，為什麼要反應迅速？看看騰訊、阿里就知道了，市場變化越來越快，客戶要求越來越高，為了滿足使用者的需求， 人家一個星期發一個版本，我們仨月才能憋出一個來 ， 那還不被打的滿地找牙？

 

問題是如何才能反應迅速？  我們先來看一個場景：

 

一、殘酷的現實

軟體開發有一大難題就是 客戶腦子中的需求難於描述出來， 我們通常的應對方法是這樣：

先花上幾個月整理需求， 天天和客戶座談， 畫出幾百頁的流程圖， 寫出上千頁的文件， 最後把客戶都快搞暈了。

 

專案經理：這是您要的軟體需求嗎？

客戶：（看到這麼多的文件） ： 嗯， 應該是。

專案經理：那就請您在需求確認書上簽字吧

客戶：（心裡犯嘀咕， 但是一想，反正是我先給你個首期款，怕啥？ ） ： 籤就籤！

專案經理：（非常高興的宣佈）需求分析階段結束了， 專案成功進入下一個階段： 概要設計！

 

然後是詳細設計， 開發， 測試，  我們強悍的技術團隊開始發動， 一切都嚴格按照計劃進行， 一切看起來都很完美， 看來專案馬上成功結束了！

 

但是客戶的驗收測試給了我們當頭一棒： 這個介面怎麼少了一個選項 ？    那個介面怎麼不能跳轉 ， 那個功能需要給領導一個後門， 還有， 我的業務規則怎麼不能改？  什麼？ 在程式碼中寫死了？  唉，你們做的系統啊， 根本就不能用 ！

 

每個人都很鬱悶， 幾個月的辛苦開發看來要付諸東流了。

從這個場景中能看出的是，   我們從客戶那裡得到的需求描述和需求文件， 其實離客戶真正想要的軟體還差的很遠。 

 

在瀑布式的開發模式下，驗收測試發現的問題，要想改正代價是非常高昂的。

 

二、改進

 

一個想法自然而然就浮現出來：  為了避免到最後習慣性崩盤，能不能讓客戶經常性的做驗收測試？ 

讓他們經常性的去使用一個可以工作的軟體， 從而告訴我們那些地方還有欠缺 ？ 那些地方做錯了？  這樣我們可以迅速的修改， 這樣我們就會輕鬆多了 ！

 

我們可以把軟體開發劃分成一個個小的開發週期， 例如每個週期就兩三週時間， 在這兩週之內我們完成一個或幾個功能， 然後就讓使用者去試用， 有問題立刻反饋，在下一個開發週期馬上改掉。 這樣就可以逐步逼近客戶的最終目標。

 

這還帶來了一個額外的好處， 不用花費巨長的時間來分析，整理冗長的需求文件了。

聽起來很美是不是？  但是仔細想想這裡邊的問題很多。那麼該如何實施敏捷開發呢？我們可以借用 敏捷開發工具，來幫助我們高效規劃任務,靈活調整計劃,高質交付產品,快速迭代,響應需求。

 

1.  拋棄了冗長的需求文件， 但還是得描述需求啊

 

 

為需求生命週期搭建流程，可以自定義更改按收集、評審、排期、設計、開發、釋出設立多個階段，在不同階段把任務分發給產品、設計或者開發人員，讓需求完成無縫銜接。

 

2.  怎麼決定每個小開發週期（我們稱之為迭代）要開發的東西？

使用者故事得有估算， 得有大小， 太大了一個迭代開發不完 ， 還得拆分一下。

我們需要對需求按照優先順序進行排序， 按照優先順序從高到低的原則來開發。

 

 

透過增量迭代⽅法進⾏敏捷式開發，根據不同版本制定⽬標與評審計劃，同步統計⾄天/周 /⽉檢視、燃盡圖以及完成度。迭代進度 清晰可追溯，助⼒企業敏捷迭代，⼩步快跑。

 

3. 不要架構設計了嗎？

一上來就按優先順序選擇需求， 直接進入迭代開發， 把架構師撂在一邊，合適嗎？

架構工作肯定還是需要的，在正式的迭代週期開始之前需要架構設計， 但是和設計出面面俱到的架構設計不同， 我們更需要演進式的架構， 隨著迭代的推進而進化。

 

4. 那詳細設計怎麼辦？

在每個迭代開始的時候，團隊在一起把這些使用者故事給拆分成一個個小的任務， 這個拆分的過程就相當於詳細設計了。  對於一些特別複雜的，例如演算法， 當然可以寫文件，幫助大家理解。

 

 

在 裡，可以同時並行管理多個專案。每個專案清晰明確可見責任⼈、任務狀態、優先順序、類別、時間等多維度資訊，幫助企業快速⾼效的對項⽬進⾏全週期管理。

 

5. 由於是迭代式開發， 這個迭代週期修改上一個迭代週期的程式碼在所難免， 怎麼保證不破壞原有的功能？ 總不能每次都手工重測一遍吧？

對於敏捷開發來說，開發人員需要儘可能做到提早整合，頻繁整合，一般每新增進一些新的程式碼時，最好都做一次整合，不要臨到軟體釋出或者交付的當天才開始整合，也不要很久才整合一次，如此可儘早發現程式碼中的問題，保持軟體的狀態一直是可用的。

 

 

 

⽀持將持續整合等結果部署到對應的測試環境，所有部署版本在測試 環境中可隨時訪問，⽀持灰度釋出到⽣產環境中。

 

6.  這麼短的開發週期， 測試人員怎麼測試啊？

 

開發和測試需要同步進行， 當開發在澄清需求的時候， 測試需要參與， 當開發在編碼的時候，測試人員在編寫測試用例，等到一個使用者故事開發完，馬上就可以投入測試。

 

執行測試計劃，也是非常有亮點的哦！

 

亮點一：用例的執行情況一目瞭然,隨著執行的進度即時更新測試結果

 

亮點二：執行用例不透過，有BUG，可以直接關聯缺陷，新增缺陷指派責任人，完全不用退出頁面，再去缺陷列表新增

 

亮點三：執行用例過程中，執行後，自動切換到下一條用例，減去很多點點的操作。

 

亮點四：測試用例批次執行的功能肯定少不了，你需要的它都有哦。

 

亮點五：用例執行頁面執行操作簡單明瞭，還可以記錄下了執行過程中發現的缺陷，執行人員的操作記錄，一目瞭然。

 

 

7. 看來開發、測試之間需要緊密的協作， 它們之間怎麼溝通？

肯定是面對面的溝通， 有問題就跑到對方的座位那裡去問，大家的座位最好在一起， 扭頭就可以討論，儘可能減少效率不高的電話、QQ/微信等工具的使用。

 

討論功能也可供團隊成員互相交流,共享資訊,解決自己在工作中遇到的各種問題。

 

 

開發團隊也可每天開一個15分鐘左右的站會，展示自己的進展和計劃，讓進度保持透明，及時暴露問題，解決問題。

 

8. 客戶什麼時候可以做驗收測試？

隨時歡迎， 但是我們更傾向於迭代結束以後， 這時候功能會穩定下來， 我們會給客戶做一個演示， 告訴他這個迭代完成的工作， 邀請他也測試一下軟體， 給我們反饋。

 

當然客戶可能會發現問題， 甚至提出新的需求， 我們表示歡迎， 我們要和客戶合作，而不是對抗。

除了給客戶演示之外，我們自己還會反思一下，看看有那些地方做的好，要繼續保持；  那些地方做的不好， 要持續改進。

 

當我們完成了專案目標或可交付成果的時候，就可以對專案進行歸檔了，當然歸檔之前可以對專案行進中的一些問題進行復盤，給團隊和個人提供一個反省和提高的機會。

 

 

 

總結：

 

作為新一代智慧專案管理平臺，專注於產品研發專案管理，致力於幫助企業全方位解決團隊協作與研發痛點，內嵌精益/敏捷/DevOps方法論，讓企業能快速響應市場變化和客戶需求，同時還具備成熟的立體化智慧資料分析系統，可自動生成報表，幫助企業科學量化團隊表現，實時把控專案進展。 適用於各行各業，產品體驗連結（ ）。