為什麼敏捷開發難於成功?

2022-06-23 20:48:59 字數 3484 閱讀 8200

前言: 這不是一篇介紹敏捷開發的入門文章, 而是我學習、實施敏捷的一些感想, 如果你沒有實踐過敏捷軟體開發, 不妨到文末看看書籍推薦。

我大概是在2003年接觸敏捷軟體開發這個概念,之前無論是在學校的小打小鬧專案,還是工作後的專案都是典型的瀑布式開發模式, 設計上自頂向下逐層分解, 設計、實現、測試、上線有條不紊。

除了大學時做的某個人專案, 客戶在不停的提需求之外, 基本上沒遇到多少需求劇烈變更的情況(可能和做的專案有關,不是定製化軟體開發),所以覺得瀑布也挺好啊, 大學裡《軟體工程》這麼課講的瀑布開發還是很有用的嘛。

但是看到敏捷宣言以後,內心還是被狠狠的震撼了一下: 原來軟體開發還可以這麼做!

這個宣言是這麼說的:

注意下面的小字:儘管右項有其價值,我們更重視左項的價值。

這17位軟體開發的領軍人物所做出的吶喊絕對重新整理了我的軟體開發三觀: 

我們的終極目標是按時高質量的交付可以工作的軟體, 不是編寫那些非常容易過時的文件,也不是遵循嚴格的評審流程。  

客戶要深度的參與到開發中來,我們會經常的給他們做演示,獲取他們的及時反饋, 而不是到最後一刻才得知,我們做的並不是客戶想要的。

我們歡迎需求變化(即使在專案的後期!) ,為了達到這個目標, 我們會採用迭代化的開發方式,經常的交付可以工作的軟體。

瞭解理念之後, 很快我就接觸到敏捷開發的一個重要流派: 

xp(極限程式設計), 提出者是kent beck, 這哥們搞的更絕:如果一個程式設計實踐很好, 我們就把它做到極致!

測試不是很好嗎? 那我們就測試先行, 用測試來驅動**的生成, 這就是tdd。

**評審不是很好嗎? 那我們就一邊程式設計,一邊評審, 兩個人同時在一個電腦上程式設計,這就是結對程式設計。

我被xp給迷住了, 開始自學junit,   測試驅動開發, 重構**這些程式設計層面的實踐。

毫無疑問,這些實踐確實能提升**的質量,但是一直沒有機會在一個團隊中大規模的鋪開使用。

到了2008年, 公司突然間要做敏捷轉型,要實施scrum, 於是又開始了新一輪學習,我這個xp粉絲剛開始還有點小牴觸, 後來發現scrum僅僅是一個框架而已, 我以前學的一些敏捷實踐仍然可以運用到其中去。

有了新東西,大家忙活的熱火朝天,設立product owner, scrum master。

學習把需求改成使用者故事,拆分task,  建立燃盡圖。

開sprint計劃會議, 每日站會,sprint評審會,反思會等等符合scrum的東西。

當然自動化測試,  自動化build這些工程層面的東西也少不了。

熱乎勁兒過了以後,我不由的困惑起來:這真的

是敏捷嗎?

我們並沒有因為採用scrum而變得更好更快的交付軟體,仍然是按照原來的節奏每年釋出幾個release。

我非常期待的特性團隊,即一個團隊中既有需求人員, 又有開發人員,還有測試人員,文件人員等並沒有建立起來。負責需求的業務分析師和開發團隊若即若離,測試團隊還是按照自己的步點來幹活, 無法深度的參與到完成一個使用者故事的活動中來。

每個sprint結束以後很難產生一個可供客戶演示、甚至釋出到產品環境的軟體。

開發團隊的本質仍然是老一套,還是依賴專案經理、或者team leader 去驅動各個developer去幹活, 看不到自組織(self-directive)的力量。

對使用者故事進行工作量評估的時候,大家還是關注資深開發和架構師的意見,做不到全員參與。

那個每日站會完全變成了一個彙報會,向專案經理彙報。

sprint 說的是橄欖球比賽中的衝刺, 大家團結一致,為了完成該sprint的目標瘋狂向前衝。 實際開發中卻很難體會到。

總而言之,我們似乎只是改了形式, 而沒有改變精神。

2009年和2010年, 我也有幸走出去實施了幾次敏捷諮詢服務,包括工行廣州開發中心,華為杭州研究所,鼎橋等等。 我發現不僅是我們, 大家都有類似的問題, 實施了敏捷形式而缺乏靈魂。

聽起來很美好的敏捷軟體開發很難落地,生根發芽,開花結果, 這些情況引起我的反思: 難道理想中的敏捷開發根本就不存在?  為什麼敏捷開發這麼難於實施?

經過一段時間的思考,我覺得實施敏捷最重要的有以下幾點, 如果做不到這幾點,敏捷是很難真正成功的:

1.  組織結構一定得變革

如果還是維持那種需求/產品團隊, 開發團隊,測試團隊的方式,各個團隊各自為政,老死不相往來的方式,敏捷肯定要失敗。

由多種技能人員組成的特性團隊是非常重要的,對小公司來說, 建立特性團隊相對容易, 但對大公司來說,這簡直就是一場革命,肯定要觸動不少人的利益,有既得利益者的阻撓, 這是非常難的。

所以很多大公司也瞭解敏捷的好處, 在小範圍內做了試點,然後說敏捷不錯, 但現階段還不適合我們, 最後不了了之。

2. 人的技能和意識一定得提高

先說技能,敏捷開發對團隊成員的要求是提高了,而不是降低了。

開發人員要能寫**、寫測試、做重構、做build, 還得具備處理遺留**的能力。 

寫出的**質量一定得高,擴充套件性強, 這樣才能“擁抱”客戶的變化,這比以前隨便寫**,完成功能的要求不知道要高了多少。 

敏捷之前的團隊有人專門做設計, 有人專門做開發, 敏捷之後這個界限模糊了, 大部分人設計和開發都得做, 對那些習慣做最基本開發的程式設計師是重大挑戰。 

同樣,開發角色和測試角色的界限也開始模糊,開發人員要能做些測試工作, 測試人員也要能協助做點開發工作。這樣才能夠在打仗的時候互相掩護, 奮勇衝鋒。 一個人出了狀況很快就有人能補上去。

特性團隊中的成員,最好是像軍隊中的特種兵那樣強悍。

其次是意識,正如我前邊所提到的,現在的很多團隊成員主動性並不強,都是在被動的等待任務的分配, 也不敢大膽的提出自己的觀點和見解, 這和敏捷開發的要求是相悖的。

有些公司在大量使用外包人員參與開發, 這些人在工作中就會出現上面的情況,  並不是貶低外包, 我也見過非常優秀的外包人員,  但是大部分人的主動性都不夠,  敏捷開發是搞不起來的。

我記得華為有個很強悍的小團隊,就幾個人, 總是能把事情做的漂漂亮亮, 我相信無論用什麼樣的開發方法對他們來說都不是問題。 歸根結底,還是人的問題。

《硝煙中的scrum和xp》:短小精悍,迅速瞭解敏捷軟體開發。

敏捷軟體開發:原則、模式、實踐》: 除了物件導向的設計之外,裡邊那個打保齡球的例子是個非常好的tdd案例。

重構 : 改善既有**的設計》: 敏捷程式設計實踐中最基本技能。

解析極限程式設計:擁抱變化》:xp的大師kent beck的經典。

使用者故事與敏捷開發》 : 描述使用者故事的經典圖書。

敏捷估計與規劃》: 主講如何規劃一個敏捷專案

持續整合》:有點老,但是瞭解下敏捷開發的基石還是不錯的。

(完)