《測試路上你問我答》我們為什麼一定要引入敏捷呢？

【背景】

昨天因為很多同學想知道什麼是敏捷，所以簡單說了說，今天有些同學就在問，為什麼一定要用敏捷，瀑布不能用嗎？我覺得在面對敏捷的時候，能對為什麼要用它而產生疑問的同學很不錯，至少他們不會盲目跟風，人云亦云。

【你問】

我們為什麼一定要引入敏捷呢？

【我答】

我先從親身經歷說起，我之前所在的公司，做的是企業級的網路會議系統，也就是一種SaaS（Software as a Service）服務。從面向的客戶群體來說，長期以來都沒有對新功能的交付速度有很高的要求，一直都是要求服務穩定為主。

但突然有一天，老大說，我們要準備轉敏捷了，隨後很短的時間內，敏捷培訓、項目轉型等等就蜂擁而至，當時的確有些讓我們措手不及，在相當長的一段時間裡，很多人其實都是有些不理解的，當然，也包括那時候的我在內。

不過在跳出當時所處的那個環境之後，再回頭去看，其實也明白了一些東西，現在寫出來，有著不同經驗的人，應該都能從中看到一些自己想了解的東西吧。

引入敏捷的初衷：

早些年，我們的產品的確佔有很大的份額優勢，大概占整個歐美在線會議市場的 60% 吧。後來幾年，原來一些專攻輕量級在線會議系統的公司中，開始出現幾家做的比較優秀的，也是因為很多中小型公司的在線會議需求逐漸湧現，其中具有代表性的應該就是 Ctrix，整個團隊也就四五十人，功能更新速度非常迅速，對於用戶反饋的響應時間也是非常的短，所以我們的在線會議市場的份額就被不斷地蠶食。

而我們當時的主版本從開始研發，到全球上線部署，從 Release...BTS...SP1.. SP7... SP12... GA... 最快也需要六個月到一年的時間，等我們若干個大功能上線了，別人新鮮熱辣的功能都早已上線半年多了。更別說現在這種移動互聯網時代的產品更新速度了，六個月到一年的時間，有時候，一款產品從生到死也不過這麼長吧。

雖說我們以產品的質量和服務的穩定為重中之重，不過看看別人家的質量，也沒有差到哪去，服務也挺穩定的，雖然沒達到四個9，也有三個9。而且別人家的團隊小而精，人力成本相對小很多，產出比就遠遠把我們甩開了好幾個街區。

所以，市場決定了我們必須不斷地改進現有功能和快速上線更新，這樣才能在保持現有市場份額的同時，繼續提高市場佔有率。而不是一味地吃著質量第一，穩定第一的老本，而選擇性地忽略掉以速度制勝這一關鍵性的因素。

引入敏捷的期望：

1、加快產品新功能的上線速度，能夠跟上 OS 和 Browser 越來越快的迭代速度，能夠快速及時地響應客戶的反饋，解決 Customer Ticket，從而增加產品的競爭力，提高市場佔有率；

2、大大減少了產品需求和最終實現之間的偏差率，降低後期返工所增加的成本和減少項目延期的風險。在此之前，就出現過耗費了幾百個人日做出來的新功能，PM 說跟他預期的出入太大，必須在下個大版本里推翻重來，甚至於會一而再再而三的重來；

3、提升團隊自組織、自管理的能力和技術水平，讓各個團隊始終都處於一種相對工作量飽和，並且積極向上的工作狀態；

4、加強 PM、EM、DEV、QA 和運維團隊、技術支持團隊的合作和溝通，提升從設計、開發、測試到上線的流程效率，縮短了新功能上線的周期；

5、通過敏捷提高各個團隊的人力資源使用效率，減少因為任務分配不均導致的資源閑置狀況；

6、提升用戶滿意度也是期望之一，隨著生活節奏的加速，用戶對於問題的提出到解決，所能等待的時間也在逐步縮短，但同時又不喜歡頻繁的無規律的收到升級通知，這對於版本發布的速度和節奏就有了更高的要求；

最後還想強調一點，敏捷研發模式的引入一定是基於現有流程存在問題的基礎上的，不能為了敏捷而敏捷，要就具體問題分析，如果只有引入敏捷才能解決，那再引入，否則，最佳辦法還是就事論事，就問題解決問題。

《測試路上你問我答》里的Q&A 45，如果是你要的，甚好！如果不是，你問，我答！

作者簡介：14 年測試 + 11 年項目管理 + 11 年團隊管理 = 一個測試老兵

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！