針對這些問題，華為也就提出了敏捷。華為在99年之前基本上都是土生土長游擊隊的做法，到了2001年的時候就引入了IPD和CMM，到2006年的時候，就發(fā)現(xiàn)了瀑布模型的問題，如交付周期特別長，就是每做一個客戶的需求，然后一分析，這樣一走半年就過去了，所以就引入了RUP，最初的想法就是加速我們項目的交付周期，能夠快速的給客戶響應，但是敏捷實際上已經(jīng)進入了一個低谷期，所以當時就引入了迭代，實施了一年之后也發(fā)現(xiàn)，RUP里面的東西實際上也是挺多的，所以后來就接觸了XP、SCRUM這些方法，這樣就從07年開始向敏捷這個方向在走。
有一個圖在業(yè)界流傳比較廣泛，也叫洋蔥圖，共分三圈，也就是從三個不同層面描述了敏捷開發(fā)方面的一些最佳實踐。XP為什么叫極限編程？如果你覺得這個軟件開發(fā)的實踐是一個好的實踐，那么你就把它發(fā)揮到極致。比如，結對編程，一個在編，一個人在看，實際上看的人不會白看，其實起到了一個review的作用，既然review這個作用有效，那么為什么不把這個作用發(fā)揮到極致，所以就采用了結對編程將review這個作用發(fā)揮到極致。在敏捷中有一個8個字的原則：溝通、反饋、交流、勇氣。它認為項目團隊中的成員這個溝通是比較重要的，既然你非常重要，那么我也要把你發(fā)揮到極致，所以兩個人一起在干活的時候就會不停的有交流與溝通，所以，結對編程是一個典型的把review、溝通交流發(fā)揮到極致的實踐。另外，TDD也可以認為是那剛好夠用的事情發(fā)揮到極致。我們以前傳統(tǒng)的軟件開發(fā)的做法是，先做好這個軟件，然后去測，看看是不是實現(xiàn)了這樣一個功能，但是我們總會發(fā)現(xiàn)這里面有很多代碼其實是從來就沒有用過的，只是在下代碼的時候順手就把它寫了，在分析那些產(chǎn)品的時候發(fā)現(xiàn)有的產(chǎn)品這樣的沒用到的代碼高達50%，而TDD的思想是，我既然要實現(xiàn)什么功能，然后我就先寫對應的用例來驗證它，然后在開發(fā)的時候就開始寫代碼，使得這個用例剛好通過，這樣就使得我們寫出來的代碼是剛好滿足這個系統(tǒng)的功能的代碼，這樣，前面出現(xiàn)的50%就可以不用做了，這就是把剛好夠用發(fā)揮到極致。其他的就不一一講了。XP在2001年到2003年之間非常的紅火，過了之后又相對的沉寂了一點，現(xiàn)在又冒出來一個新的敏捷的方法論，就是SCRUM。XP是過分的強調(diào)將軟件開發(fā)里面的實踐發(fā)揮到極致，而這些實踐都是同編程實踐相關，但是在管理方面就比較弱，所以，在用了幾年之后，大家發(fā)揮XP不是起到那么大的作用，所以就開始沉寂下來。這個時候就出現(xiàn)一個流派，就是SCRUM。SCRUM其實就是一個非常非常輕量的項目管理框架，基本上沒有什么編碼實踐方面的東西，你說看到的都是管理上的活動，這個管理上的活動很多人就會有一種似曾相識的感覺，記得前不久，同華為的一個項目團隊在聊，就談到這個項目的backlog，一講，項目團隊的人就說其實他就是那樣子做的，他以前也沒與聽說過什么SCRUM，就是把這些需求一條一條的列出來，鎳鎘優(yōu)先級，估個工作量，一看，就是這個東西。SCRUM的核心其實比較簡單，2分鐘就能講出來，就是3個3。
此文章共有4頁 上一頁 1 2 3 4 下一頁
文章來源：互聯(lián)網(wǎng)
|
Leadge.com首頁 > 知識庫 
