日拱一卒，大廠都在推崇的敏捷開發究竟是人還是工具至上？

摘要：

都2021年了，你敏捷了嗎？

隨著網際網路科技的飛速發展，敏捷開發正越來越多地滲透進各行各業，受到不少企業的追捧。其中，在軟體開發行業，敏捷開發已經成為非常重要的模式。市場普遍認為，快速迭代、小步快跑、治癒延期的敏捷開發，可以說是革命性的顛覆，相比之下，傳統的瀑布流研發模式，因為效率較低、試錯成本高、難以按時精準交付等原因，主要侷限在需求較確定的一些傳統行業。而需求千變萬化的網際網路科技行業，成為敏捷開發生長的沃土。

事實上，敏捷開發並非近年來的新興物種。早在21世紀之初敏捷宣言就已經問世，迄今已20年，國內敏捷開發的發展也已經十幾年。近幾年，敏捷開發之所以持續升溫，與網際網路科技的新一輪發展浪潮密不可分。

伴隨著敏捷開發的盛行，相關的專案管理工具也趁勢興起，比如Worktile、PingCode、TAPD、禪道、華為軟開雲等。

但是在敏捷開發實踐中，工具的實際效果如何？是否真的推動了敏捷開發，即更敏捷了還是更不敏捷了？如果反而事倍功半，是工具的問題還是人的問題？對於不同行業、不同規模企業的不同團隊，以及團隊中的不同成員而言，敏捷開發對於工具的需求以及工具所能產生的價值又有哪些差異呢？

帶著這些困惑，我們從大廠和中小企業這兩大不同維度出發，帶你揭開在踐行敏捷開發的過程中，人與工具之間的奇妙關係。

警惕“偽敏捷”和“中華田園敏捷”

根據敏捷宣言，敏捷的核心價值觀如下——

個體和互動勝過流程和工具

工作的軟體勝過詳盡的文件

客戶合作勝過合同談判

響應變化勝過遵循計劃

這是敏捷的核心思想。但是敏捷實踐中，如何因地制宜、靈活運用敏捷理念並藉助合適的工具高效推動產品研發，卻難倒了一大片企業，很多團隊對於敏捷的理解和應用都處於摸索階段。

關於敏捷開發的爭議也一直存在。比如敏捷開發究竟是真敏捷還是假敏捷？敏捷開發是否只適合小團隊不適合大廠？敏捷開發甚至被指在國內市場存在生搬硬套、流於形式、水土不服等問題，背上了“中華田園敏捷”的鍋。

如何避免掉入“偽敏捷”的陷阱，實現真正的敏捷，無論對於谷歌、華為、騰訊這樣的巨頭，還是中小企業，都是巨大的考驗。

谷歌、華為、騰訊等巨頭敏捷的秘密

• 適合谷歌的敏捷秘笈

敏捷宣言的誕生，有一個非常重要的背景，即矽谷以授權和信任為中心的文化氛圍。這意味著，想要踐行敏捷宣言，團隊之間的相互信賴至關重要。而敏捷宣言的核心價值也將個體和互動放在了首要位置。

作為矽谷網際網路科技巨頭的代表，谷歌在軟體開發中如何做到敏捷，是眾人熱議的焦點。谷歌前技術總監Jeske曾專門分享了其關於敏捷的思考。

Jeske認為適合谷歌的改進版敏捷原則主要包括以下幾方面：

首要任務是提高客戶和程式設計師的生產力和對資訊的理解。

應該建立小型的適應谷歌的結構化設計文件，用於解釋專案。

關鍵設計元素應該在上述文件中有簡明的解釋，並能夠方便地檢索。

不要追求完美無暇，但是要靈活。

在確保產品質量的前提下，儘可能快地交付。

透過以上幾點，我們可以看到，谷歌並非如一些質疑所言對敏捷開發嗤之以鼻，而是在敏捷宣言的基礎上，探索更適合自身的方法。這與敏捷宣言並不矛盾，由此可以看出，敏捷宣言並不是教條主義，而是提供了一個指導方向，具體如何落地還需要各企業根據自身情況量體裁衣。

• 華為敏捷轉型踩過的坑

就國內市場而言，華為是投身敏捷開發的先鋒。華為從2007年起即正式開啟敏捷轉型，為此進行了堅持不懈的努力，如今已經有一定成效。在這個過程中，華為也經歷過迷茫，比如早期對華為是否適合敏捷的爭論，以及敏捷轉型路上，有些團隊做得不到位、過於注重敏捷不敏捷而忽視了敏捷的本質，產生了一些只會紙上談兵、對別人評頭論足的“哲學家”、“思想家”等，而沒有聚焦實際問題的解決。作為國內科技巨頭，華為在從0到1落地大規模敏捷開發方面的經驗非常值得借鑑。

目前結合華為自身經驗，華為雲也已經推出自研的涵蓋敏捷開發專案管理的一站式軟體開發平臺——DevCloud。為敏捷開發團隊提供簡單高效的團隊協作服務，包含多專案管理、敏捷迭代、看板協作、需求管理、缺陷跟蹤、文件管理、Wiki線上協作、儀表盤自定製報表等功能，適用於敏捷交付專案管理和外包協作等場景。

• 微信小步快跑，用了什麼法寶

今年初，微信十週年之際，張小龍曾在公開演講中表示，影片號組建了一兩百人的團隊，三個演算法團隊，小規模能夠比很多大團隊跑得更快一些。影片號這個速度才是微信正常該有的速度。

從使用者角度而言，去年以來，微信圍繞影片號的一系列頻繁迭代，也讓我們直觀感受到了張小龍所言的快。

微信的快速迭代背後，騰訊自研的敏捷專案管理工具TAPD可謂功不可沒。早在2012年微信使用者突破1億之後，微信就開始使用TAPD平臺，因為隨著使用者規模的爆發式增長和團隊的壯大，跨部門溝通合作越來越多，Excel和郵件已經無法滿足研發需求，敏捷開發所具有的需求池Backlog、User Story、缺陷管理等功能則正好契合了微信團隊的需要。

藉助合適的敏捷專案管理工具，微信的快速高質量迭代成為可能。

在探索敏捷開發的長河中，谷歌、華為、騰訊等大廠可謂各有各的打法，並各有千秋，其中，華為和騰訊自研的敏捷專案管理工具如今已成為市場中的佼佼者，得以攫取更大的市場蛋糕。而沒有大廠光環的眾多中小企業，在擁抱敏捷開發的路上，又有著怎樣的故事呢？

中小企業如何玩轉敏捷開發？

為了挖掘中小企業在敏捷開發中面臨的痛點與收穫的價值，我們和身處不同行業、不同企業、不同團隊的產品經理、專案經理等業內人士進行了對話，發現了一些值得思考的現象。

• 重點不在工具，而在於目標和溝通

正如敏捷宣言所提倡的，個體和互動勝過流程和工具，因此，儘管敏捷開發工具層出不窮，並吸引了華為、騰訊等巨頭入局，但是流程和工具並不是敏捷開發的重點。相比工具，個體和互動才更為重要。

工欲善其事必先利其器，對於中小企業而言，藉助合適的專案管理工具無疑可以提升敏捷開發的效率，但是並不意味著需要形成嚴重依賴。想要做好敏捷開發，工具只是一方面，明確的目標和高效的溝通則是更重要的事情，切不可盲目迷信工具，為了敏捷而敏捷，最終讓敏捷開發流於形式，本末倒置。

高遠是上海一家中小型企業的高階產品經理，他所在的團隊目前部分業務仍在使用傳統開發模式，一些急需驗證的業務則採用了敏捷開發。敏捷快速簡單、週期短，能夠將需要的功能快速上線進行驗證，是他們採用敏捷開發的主要原因。

在高遠看來，與傳統開發模式相比，敏捷模式不需要大量的其他文件去沉澱，而是首先需要相關人員透過大量的溝通快速達成共識，在基於共有目標的情況下快速實現。

高遠目前在敏捷模式中的主要角色是產品，負責需求和目標制定。之前還擔任過整個敏捷模式的管理溝通者，協調溝通在開發環節中的一切問題和各種資源，以便讓產品按照計劃上線。

很多時候，客戶對於產品的需求在最開始並不明確。喬布斯曾經指出，使用者根本不知道自己要什麼，福特汽車的創始人亨利·福特也曾發表過類似觀點：如果最初問使用者想要什麼，他們會說想要一匹更快的馬，而不是汽車。

透過敏捷開發快速迭代，逐步摸清使用者的明確需求，顯得尤為重要。站在產品角度，高遠表示，敏捷開發最需要注意的一個關鍵點就是，每個版本迭代都要做到最小mvp閉環，不夾雜太多額外功能，從而更接近原始需求本身，以便於技術人員快速開發。

提前性也是敏捷開發的一大優勢，從產品到最終上線的每一個環節、每一個負責人都可以做到提前處理，節省了很多時間。值得注意的是，為了防止做沒意義的事情造成延期，在敏捷開發中一定要嚴格限定每一個環節的完結限制，即明確做到哪一步就算完結。

高遠所在團隊主要使用的敏捷專案管理工具是禪道，偶爾也會用到Teambition。在高遠看來，不同工具的側重點會有所不同，不過敏捷開發的重點不在於工具的使用，而在於明確的目標和高效的溝通。

一線城市某中小型IT諮詢服務公司的專案經理李航則指出，敏捷開發過程中，工具還是很有必要的。如果不用專門的敏捷專案管理工具，可能就需要用Excel去做管理，同步化就會受到影響。

工具五花八門，在精不在多

事實上，目前軟體開發行業，面向敏捷開發場景的專案管理軟體非常多。除了騰訊的TAPD，華為的軟開雲，Worktile旗下的PingCode等新一代研發管理工具也主打這一垂直細分場景。這為中小企業提供了更多的選擇。

李航所在的團隊規模在50人以內，主要採取敏捷開發模式，對專案管理的核心需求就是研發管理，比如前後端的開發人員、產品設計人員等的任務分配。透過專案管理，可以清晰知道每個人手頭的任務，並及時跟進任務進展情況。

目前，李航團隊使用的專案管理工具主要是TAPD，也用過PingCode、豬齒魚等其他工具。據瞭解，其團隊最開始接觸的是一站式專案管理平臺豬齒魚，功能比較複雜和齊全，可以滿足團隊的任何需求，但是缺點就是比較臃腫，導致使用不是很便捷。比如如果不看說明手冊，很難搞清楚怎麼去配置，需要花費很長時間去研究功能，學習成本比較高。

後來也嘗試過其他工具，一個比較大的缺點是不能拖拉拽，如果想修改任務所處的節點狀態，需要被迫點開每一個任務再去調整狀態情況，造成使用效率較低。遺憾的是，市面上很多專案管理工具都不能很好地實現這個功能。

李航短暫體驗過PingCode一段時間，後來朋友推薦了TAPD。綜合對比之後，TAPD與其團隊的需求更契合，基本的功能都可以滿足。比如任務分配，可以把每一個需求拆分給不同的人，拆成不同的任務，進行管理。同時整個頁面比較簡潔，學習成本比較低，容易上手。最重要的是，可以實現拖拉拽，極大提升了使用效率。

從決策角度而言，李航所在團隊選擇哪款專案管理工具一般是由專案負責人來進行決定。事實上，李航所在公司也自研了專案管理軟體，在內部推廣，不過實際使用的時候發現不是很好用，流程配置比較繁瑣，也不支援拖拉拽，因此選擇了市面上的其他產品。

這也暴露出中小團隊在自研專案管理類產品方面還有待進一步提升和完善，與騰訊、華為等大廠相比還有一定的差距。而選擇市面上現成的工具，則需要付出一定的試錯成本。每一次切換工具的時候，不僅需要整個團隊達成共識，還要讓大家重新熟悉怎麼使用。

此外，作為專案經理，李航發現在推進敏捷開發的過程中，想要讓團隊實際的開發進度在工具端保持實時同步，在執行層面是比較困難的。因為整個執行層大家的工作都比較繁瑣，完成相應任務後未必會實時去調整，導致專案經理的工作量增加，有時需要與團隊溝通後，自己再去做調整。

工具只是輔助，不要拘泥形式

某中小型技術研發企業的產品經理王燕，也犀利指出了敏捷專案管理工具和人之間的複雜關係。

王燕此前所在的團隊有敏捷的雙週迭代，當時主要使用TAPD、Teambition、華為軟開雲等專案管理軟體。就使用體驗而言，軟開雲比較龐大，更適合比較大型的專案模組，相比而言，TAPD、Teambition更適合一些。

王燕認為，工具更多隻是一種輔助，比如需求池的記錄跟進，需求和bug的統計等。有很多需求，包括有效的和無效的，需要進行評審是否有效，並排出需求的優先順序，再進行開發交付。透過專案管理工具可以大大提升敏捷開發效率。

但是一些比較小的需求，比如前端互動，有一個控制元件或者是頁面浮動效果，可能口頭簡單溝通一下，工程師就很快明白了，這種情況下就不需要依賴工具了。因此，不必拘泥於形式化，要根據具體情況靈活變通。

透過以上幾個案例，我們可以發現，就中小企業的敏捷開發而言，團隊之間協作互動的重要性遠遠大於工具的價值，這恰恰是敏捷宣言核心價值觀的現實體現。而無論是敏捷開發，還是敏捷專案管理工具，之所以受到市場的熱捧，提質增效是最核心的考量。在競爭日益激烈的今天，品質和效率就是中小企業的生命線，不僅影響專案的成敗，甚至事關企業的生死存亡。如果能夠藉助對的工具，日拱一卒，快速迭代，錦上添花，自然事半功倍。同時也要警惕對工具的過分依賴，充分發揮人的作用，靈活應對變化。

可以肯定的是，經過20年的積澱，敏捷開發正釋放出更強大的生命力，Worktile、PingCode、TAPD、禪道、華為軟開雲等敏捷專案管理SaaS也將迎來更大的發展機遇。而從歷史發展的車輪來看，工具永遠都在與時俱進，這背後是生產力的不斷變革。從提升生產力的角度而言，在追尋敏捷的漫漫長路上，大廠和中小企業本質上可謂殊途同歸。

www.36dianping.com