建站
咨詢
售后
建站咨詢
新聞中心
我大概是在2003年接觸敏捷軟件開發(fā)這個概念，之前無論是在學校的小打小鬧項目，還是工作后的項目都是典型的瀑布式開發(fā)模式， 設計上自頂向下逐層分解， 設計、實現(xiàn)、測試、上線有條不紊。這不是一篇介紹敏捷開發(fā)的入門文章， 而是我學習、實施敏捷的一些感想， 如果你沒有實踐過敏捷軟件開發(fā)， 不妨到文末看看書籍推薦。
[[183089]]
我大概是在2003年接觸敏捷軟件開發(fā)這個概念，之前無論是在學校的小打小鬧項目，還是工作后的項目都是典型的瀑布式開發(fā)模式， 設計上自頂向下逐層分解， 設計、實現(xiàn)、測試、上線有條不紊。
除了大學時做的某個人項目， 客戶在不停的提需求之外， 基本上沒遇到多少需求劇烈變更的情況（可能和做的項目有關，不是定制化軟件開發(fā)），所以覺得瀑布也挺好啊， 大學里《軟件工程》這么課講的瀑布開發(fā)還是很有用的嘛。
但是看到敏捷宣言以后，內(nèi)心還是被狠狠的震撼了一下： 原來軟件開發(fā)還可以這么做！
這個宣言是這么說的：
注意下面的小字：盡管右項有其價值，我們更重視左項的價值。
這17位軟件開發(fā)的領軍人物所做出的吶喊絕對刷新了我的軟件開發(fā)三觀：
我們的***目標是按時高質(zhì)量的交付可以工作的軟件， 不是編寫那些非常容易過時的文檔，也不是遵循嚴格的評審流程。
客戶要深度的參與到開發(fā)中來，我們會經(jīng)常的給他們做演示，獲取他們的及時反饋， 而不是到***一刻才得知，我們做的并不是客戶想要的。
我們歡迎需求變化(即使在項目的后期！) ，為了達到這個目標， 我們會采用迭代化的開發(fā)方式，經(jīng)常的交付可以工作的軟件。
了解理念之后， 很快我就接觸到敏捷開發(fā)的一個重要流派：
XP(極限編程)， 提出者是Kent Beck, 這哥們搞的更絕：如果一個編程實踐很好， 我們就把它做到***！
測試不是很好嗎？ 那我們就測試先行， 用測試來驅(qū)動代碼的生成， 這就是TDD。
代碼評審不是很好嗎？ 那我們就一邊編程，一邊評審， 兩個人同時在一個電腦上編程，這就是結(jié)對編程。
......
我被XP給迷住了， 開始自學JUnit, 測試驅(qū)動開發(fā)， 重構(gòu)代碼這些編程層面的實踐。
毫無疑問，這些實踐確實能提升代碼的質(zhì)量，但是一直沒有機會在一個團隊中大規(guī)模的鋪開使用。
到了2008年， 公司突然間要做敏捷轉(zhuǎn)型，要實施Scrum, 于是又開始了新一輪學習，我這個XP粉絲剛開始還有點小抵觸， 后來發(fā)現(xiàn)Scrum僅僅是一個框架而已， 我以前學的一些敏捷實踐仍然可以運用到其中去。
有了新東西，大家忙活的熱火朝天，設立product owner, scrum master。
學習把需求改成用戶故事，拆分task, 創(chuàng)建燃盡圖。
開Sprint計劃會議， 每日站會，Sprint評審會，反思會等等符合Scrum的東西。
當然自動化測試， 自動化Build這些工程層面的東西也少不了。
熱乎勁兒過了以后，我不由的困惑起來：這真的
是敏捷嗎？
我們并沒有因為采用Scrum而變得更好更快的交付軟件，仍然是按照原來的節(jié)奏每年發(fā)布幾個release。
我非常期待的特性團隊，即一個團隊中既有需求人員， 又有開發(fā)人員，還有測試人員，文檔人員等并沒有建立起來。負責需求的業(yè)務分析師和開發(fā)團隊若即若離，測試團隊還是按照自己的步點來干活， 無法深度的參與到完成一個用戶故事的活動中來。
每個Sprint結(jié)束以后很難產(chǎn)生一個可供客戶演示、甚至發(fā)布到產(chǎn)品環(huán)境的軟件。
開發(fā)團隊的本質(zhì)仍然是老一套，還是依賴項目經(jīng)理、或者team leader 去驅(qū)動各個developer去干活， 看不到自組織（self-directive）的力量。
對用戶故事進行工作量評估的時候，大家還是關注資深開發(fā)和架構(gòu)師的意見，做不到全員參與。
那個每日站會完全變成了一個匯報會，向項目經(jīng)理匯報。
Sprint 說的是橄欖球比賽中的沖刺， 大家團結(jié)一致，為了完成該Sprint的目標瘋狂向前沖。 實際開發(fā)中卻很難體會到。
總而言之，我們似乎只是改了形式， 而沒有改變精神。
2009年和2010年， 我也有幸走出去實施了幾次敏捷咨詢服務，包括工行廣州開發(fā)中心，華為杭州研究所，鼎橋等等。 我發(fā)現(xiàn)不僅是我們， 大家都有類似的問題， 實施了敏捷形式而缺乏靈魂。
聽起來很美好的敏捷軟件開發(fā)很難落地，生根發(fā)芽，開花結(jié)果， 這些情況引起我的反思： 難道理想中的敏捷開發(fā)根本就不存在？ 為什么敏捷開發(fā)這么難于實施？
經(jīng)過一段時間的思考，我覺得實施敏捷最重要的有以下幾點， 如果做不到這幾點，敏捷是很難真正成功的：
1. 組織結(jié)構(gòu)一定得變革
如果還是維持那種需求/產(chǎn)品團隊， 開發(fā)團隊，測試團隊的方式，各個團隊各自為政，老死不相往來的方式，敏捷肯定要失敗。
由多種技能人員組成的特性團隊是非常重要的，對小公司來說， 建立特性團隊相對容易， 但對大公司來說，這簡直就是一場革命，肯定要觸動不少人的利益，有既得利益者的阻撓， 這是非常難的。
所以很多大公司也了解敏捷的好處， 在小范圍內(nèi)做了試點，然后說敏捷不錯， 但現(xiàn)階段還不適合我們， ***不了了之。
2. 人的技能和意識一定得提高
先說技能，敏捷開發(fā)對團隊成員的要求是提高了，而不是降低了。
開發(fā)人員要能寫代碼、寫測試、做重構(gòu)、做Build， 還得具備處理遺留代碼的能力。
寫出的代碼質(zhì)量一定得高，擴展性強， 這樣才能“擁抱”客戶的變化，這比以前隨便寫代碼，完成功能的要求不知道要高了多少。
敏捷之前的團隊有人專門做設計， 有人專門做開發(fā)， 敏捷之后這個界限模糊了， 大部分人設計和開發(fā)都得做， 對那些習慣做最基本開發(fā)的程序員是重大挑戰(zhàn)。
同樣，開發(fā)角色和測試角色的界限也開始模糊，開發(fā)人員要能做些測試工作， 測試人員也要能協(xié)助做點開發(fā)工作。這樣才能夠在打仗的時候互相掩護， 奮勇沖鋒。 一個人出了狀況很快就有人能補上去。
特性團隊中的成員，***是像軍隊中的特種兵那樣強悍。
其次是意識，正如我前邊所提到的，現(xiàn)在的很多團隊成員主動性并不強，都是在被動的等待任務的分配， 也不敢大膽的提出自己的觀點和見解， 這和敏捷開發(fā)的要求是相悖的。
有些公司在大量使用外包人員參與開發(fā)， 這些人在工作中就會出現(xiàn)上面的情況， 并不是貶低外包， 我也見過非常優(yōu)秀的外包人員， 但是大部分人的主動性都不夠， 敏捷開發(fā)是搞不起來的。
我記得華為有個很強悍的小團隊，就幾個人， 總是能把事情做的漂漂亮亮， 我相信無論用什么樣的開發(fā)方法對他們來說都不是問題。 歸根結(jié)底，還是人的問題。
對于想了解敏捷開發(fā)的同學，推薦幾本書：
《硝煙中的Scrum和XP》：短小精悍，迅速了解敏捷軟件開發(fā)。
《敏捷軟件開發(fā)：原則、模式、實踐》： 除了面向?qū)ο蟮脑O計之外，里邊那個打保齡球的例子是個非常好的TDD案例。
《重構(gòu) : 改善既有代碼的設計》： 敏捷編程實踐中最基本技能。
《解析極限編程：擁抱變化》：XP的大師Kent beck的經(jīng)典。
《用戶故事與敏捷開發(fā)》 ： 描述用戶故事的經(jīng)典圖書。
《敏捷估計與規(guī)劃》： 主講如何規(guī)劃一個敏捷項目
《持續(xù)集成》：有點老，但是了解下敏捷開發(fā)的基石還是不錯的。
本文標題：為什么敏捷開發(fā)難于成功？
文章起源：http://www.dlmjj.cn/article/dphdscd.html
