華為 騰訊的敏捷之路

2021-04-27 09:44:58 字數 1342 閱讀 8481

用qq漫畫形式推介敏捷

通過明星產品qqmail的實踐,觀察到團隊成員的心情在逐步向好,同時使用者量也有10倍以上的增長,這些效果堅定了他們繼續推行的信心。

實踐中也遇到一些困難。比如站立會議對於二三十人的較大團隊負擔較大,時間長了之後變得形式化和呆板。為此他們採取了輪流主持等方式加強參與感和增加刺激,但結果還不能令人滿意。有的團隊改用虛擬方式增進效率,也更適合分布式團隊。

結對程式設計的推行也不太成功。開始的時候效果很好,因為看到質量提高,團隊成員也願意去做,但逐漸由於專案壓力大而放棄。

其他困難還有每年上千畢業生要融入團隊,大型產品qq客戶端發布周期長達半年以上,諸多問題尚在探索之中。

第二位分享的是周代兵,華為軟體公司軟體工程部經理。華為的轉變經歷了很長的過程。首先是引入ipd(integrated product development)改變了游擊隊做法,成功將企業從自行摸索的技術導向轉變為市場導向。接著引入cmm(i),大大提高產品質量。ipd+cmm形成的專案管理、質量保證體系確保了企業的正常運作。

然而,在華為的傳統做法中,過於偏重對過程的控制,忽視了人與工具的因素。流程控制使得產品質量可控,進度***,管理層亦較容易了解進度。但軟體開發不同於生產線上的重複勞動,是創造性的工作。嚴守流程能完成任務,但其成效是未知的。片面追求運作規範,結果是完美的報告的背後,可能是質量完全不相稱的交付物。

華為還引入了rup,嘗試用迭代去解決瀑布方法交付周期長的問題,但發現rup雖然全面、完善,但並不能切合需要。於是scrum和xp進入了他們的視野。

複習了一遍scrum和xp

在實施中,他們利用精益思維去發現需要改進的地方,有選擇地採納一些xp實踐,並以scrum去補足xp在管理上的弱點。舉例來說,他們用結對去**複審和溝通的問題;用tdd去「做剛好夠用的事情」,避免在無用的產品功能上浪費資源(曾有產品高達50%的功能無用);用看板和scrumworks等軟體工具去維持專案進度的視覺化;整合原先按照開發、測試等階段劃分的團隊,消除「停工等活」的浪費。

在轉變的過程中,他們並非全盤放棄傳統做法,而是將ipd移到上層用在決定投資決策方面。然後用敏捷團隊逐漸代替cmm團隊。團隊被賦予對自身採用何種方式的選擇權,運作良好的專案可以繼續下去。同時他們觀察到以前所謂的「爛專案」會主動選擇變化,正說明這些專案不適合瀑布方法。

他們也認識到改變需要很長的時間,從關注過程到對人的關注牽涉到文化的轉變,而習慣根深蒂固,利益不同更是會產生以鄰為壑的做法。為此他們用「一體化團隊」去打破部門之間由於利益不同造成的 「部門牆」,將交付成功與所有人的利益關聯起來;幫助成員做角色的轉變,比如將過去充當警察角色的qa變成教練和scrum master的角色;重新設計辦公室布局以促進交流。

周代兵將華為的敏捷之路形容為「一夜的引入,長時間的改變」,他們還在「moving」之中。

分組討論

CORNERSTONE對話騰訊 華為敏捷專家

由cornerstone主辦的 深圳敏捷狂歡大會 圓滿落幕。此次活動集齊了敏捷領域的大咖與近百位敏捷研發愛好者到場,會上大家通過提問互動與敏捷大咖產生了精彩的思想碰撞,大家就敏捷開發如何落地及技術人員如何轉型晉公升這兩個話題做了深度 以下為敏捷專家薛軍和李林在敏捷狂歡大會上的演講分享 產品如何做減法...

騰訊敏捷框架TAPD

tencent agile product development 就是白板story wall,平時工作中很多團隊都會使用,這些團隊會把每天開發的一些產品特性採用story的方式每天都在白板裡面展示出來,整個團隊每天都會圍繞這個白板能夠清晰的看到整個產品或者整個專案的乙個過程,包括整個產品特性的過...

敏捷之路 初體驗

說起來第一次聽到敏捷開發這個詞是2004年與之一起的是xp程式設計,當時剛剛加入挨踢大軍還沒多長時間,和很多程式設計師一樣對於專案管理 專案文件持極端反感的態度。曾經老闆嘗試使用ibm的靜室軟體工程來實施erp軟體開發,帶來的結果是乙個專案組在公司辦公室討論乙個月了專案文件還沒有弄清楚,幾乎脫離了實...