但是現(xiàn)在行業(yè)中，需求變化太快，不管我們怎么努力去做，發(fā)現(xiàn)還是不能滿足客戶的需要，不管需求搞得多么細，到交付產(chǎn)品給客戶的事情，總是有這樣那樣的問題，這個時候就不得不去修改我們的軟件，這是華為面臨的一個挑戰(zhàn)，如何解決這個問題？
軟件開發(fā)中有三個要素：人、過程、技術(shù)和工具。對于一個軟件項目成功來說，這三個要素都不可省，而在以前大家強調(diào)IPD和CMM，更多的是強調(diào)大家規(guī)范的把它運作起來，對于人、技術(shù)和工具基本上不提了，忽略了，所以后來就反饋出一個問題，就是很多項目，看起來那個過程做的那個漂亮，那個報告寫得那個完美，但是交出去的產(chǎn)品那個爛，其實這三個因素是缺一不可的，你必須得均勻的發(fā)展，還有一個是人的方面，因為人是具備創(chuàng)造能力的，所以從華為的教訓(xùn)給我啟發(fā)，過度的關(guān)注過程而忽視人、忽視技術(shù)和工具，我們就得要思考和反省了。
針對這些問題，華為也就提出了敏捷。華為在99年之前基本上都是土生土長游擊隊的做法，到了2001年的時候就引入了IPD和CMM，到2006年的時候，就發(fā)現(xiàn)了瀑布模型的問題，如交付周期特別長，就是每做一個客戶的需求，然后一分析，這樣一走半年就過去了，所以就引入了RUP，最初的想法就是加速我們項目的交付周期，能夠快速的給客戶響應(yīng)，但是敏捷實際上已經(jīng)進入了一個低谷期，所以當(dāng)時就引入了迭代，實施了一年之后也發(fā)現(xiàn)，RUP里面的東西實際上也是挺多的，所以后來就接觸了XP、SCRUM這些方法，這樣就從07年開始向敏捷這個方向在走。
有一個圖在業(yè)界流傳比較廣泛，也叫洋蔥圖，共分三圈，也就是從三個不同層面描述了敏捷開發(fā)方面的一些最佳實踐。XP為什么叫極限編程？如果你覺得這個軟件開發(fā)的實踐是一個好的實踐，那么你就把它發(fā)揮到極致。比如，結(jié)對編程，一個在編，一個人在看，實際上看的人不會白看，其實起到了一個review的作用，既然review這個作用有效，那么為什么不把這個作用發(fā)揮到極致，所以就采用了結(jié)對編程將review這個作用發(fā)揮到極致。在敏捷中有一個8個字的原則：溝通、反饋、交流、勇氣。它認為項目團隊中的成員這個溝通是比較重要的，既然你非常重要，那么我也要把你發(fā)揮到極致，所以兩個人一起在干活的時候就會不停的有交流與溝通，所以，結(jié)對編程是一個典型的把review、溝通交流發(fā)揮到極致的實踐。另外，TDD也可以認為是那剛好夠用的事情發(fā)揮到極致。我們以前傳統(tǒng)的軟件開發(fā)的做法是，先做好這個軟件，然后去測，看看是不是實現(xiàn)了這樣一個功能，但是我們總會發(fā)現(xiàn)這里面有很多代碼其實是從來就沒有用過的，只是在下代碼的時候順手就把它寫了，在分析那些產(chǎn)品的時候發(fā)現(xiàn)有的產(chǎn)品這樣的沒用到的代碼高達50%，而TDD的思想是，我既然要實現(xiàn)什么功能，然后我就先寫對應(yīng)的用例來驗證它，然后在開發(fā)的時候就開始寫代碼，使得這個用例剛好通過，這樣就使得我們寫出來的代碼是剛好滿足這個系統(tǒng)的功能的代碼，這樣，前面出現(xiàn)的50%就可以不用做了，這就是把剛好夠用發(fā)揮到極致。其他的就不一一講了。XP在2001年到2003年之間非常的紅火，過了之后又相對的沉寂了一點，現(xiàn)在又冒出來一個新的敏捷的方法論，就是SCRUM。XP是過分的強調(diào)將軟件開發(fā)里面的實踐發(fā)揮到極致，而這些實踐都是同編程實踐相關(guān)，但是在管理方面就比較弱，所以，在用了幾年之后，大家發(fā)揮XP不是起到那么大的作用，所以就開始沉寂下來。這個時候就出現(xiàn)一個流派，就是SCRUM。SCRUM其實就是一個非常非常輕量的項目管理框架，基本上沒有什么編碼實踐方面的東西，你說看到的都是管理上的活動，這個管理上的活動很多人就會有一種似曾相識的感覺，記得前不久，同華為的一個項目團隊在聊，就談到這個項目的backlog，一講，項目團隊的人就說其實他就是那樣子做的，他以前也沒與聽說過什么SCRUM，就是把這些需求一條一條的列出來，鎳鎘優(yōu)先級，估個工作量，一看，就是這個東西。SCRUM的核心其實比較簡單，2分鐘就能講出來，就是3個3。一、3個角色。Product Owner，負責(zé)決定產(chǎn)品要做什么，做成什么樣子；SCRUM Master，保證項目能夠遵循SCRUM的方式運作下來；項目團隊成員，包含開發(fā)、測試、質(zhì)量等等所有的人。二、3種會議。迭代的計劃會議、中間的站立式會議、迭代的評估會議，屬于三個管理的活動。三、3個交付件。待開發(fā)的任務(wù)列表、待修復(fù)的缺陷任務(wù)列表、項目的進度圖。SCRUM就是通過這3個3將項目非常簡潔的管理起來，有一個思考就是關(guān)于PMP里面講到的9大領(lǐng)域多少活動不一定對這種敏捷項目適用。那么大家可能提出一個疑問，就是項目的進度是不是就不可視了。其實，敏捷項目的進度可視很簡單，就是通過一個白板（進度墻、任務(wù)看板），將每個人的進度情況這么一貼，這就是最簡單最直接的管理方式，一看，所有人都知道，就算你去開發(fā)一些什么復(fù)雜的一些IT支撐系統(tǒng)，可能都起不到這個白板的作用。在華為關(guān)于敏捷的一些項目管理工具，用Scrumworks、Bingo這些管理工具也能夠把項目的進度管理起來，但是你要做的就是必須得把電腦打開，要把瀏覽器打開，這樣才能看到你的進度是什么樣子的，而在辦公區(qū)直接樹一個白板就能夠很簡單、很方便的知道我的這個進度情況。所以，在華為，對于敏捷項目，管理的框架上是采用的SCRUM，指導(dǎo)如何編碼實現(xiàn)上就采用了一些XP的實踐，當(dāng)然XP的實踐不會全部去選，會根據(jù)項目的實際情況去選一些實踐，如果你把所有實踐都選的話，實際上的效果是非常差的。那么如何來選擇就得根據(jù)項目的實際情況去評價。華為在實踐的過程中也引入了精益、消除浪費的思想。比如，在平時的工作中存在停工等活的浪費。什么是停工等活的浪費呢？比如我們開發(fā)在做開發(fā)的時候，我們的測試就會輕松一點，那么測試在做測試的時候我們的開發(fā)就會輕松一點，大家覺得這樣也挺好的，但是你從整個組織角度去分析，實際上是停工等活的，開發(fā)時測試在等著，測試時開發(fā)在等著，如果你從精益的角度考慮的話，為何不通過迭代的方式把開發(fā)和測試等待的時候整合在一起來工作，使得效益得到提升。有很多項目團隊自己去做了，確實效果比較明顯。其實在2006年實踐RUP的時候就感覺到這樣的好處了是非常明顯的。引入敏捷之后，自然而然的就會想到同公司已有流程之間的關(guān)系，原來是IPD+CMM，所以就有同事問到是不是我這個就不用了。分析可以知道，IPD是決定做不做，決定之后如何去做就可以采用敏捷開發(fā)，所以對于敏捷產(chǎn)品的流程就是IPD+敏捷的方式，所以有很多以前采用瀑布型的團隊逐步的被敏捷代替了，還有些團隊正在代替中，還有些團隊就覺得原來那套玩得很流暢就繼續(xù)采用原來的方式。所以目前在華為，項目團隊是可以自己來選擇采用哪種方式進行，現(xiàn)在可以發(fā)現(xiàn)，那些愿意選擇敏捷方式走的往往就是原來那些頑固不化的爛項目，因為以前在推流程的時候，那幫人整天在那里叫，有問題，我不干，我不愿意做，實際上，后來做深入分析發(fā)現(xiàn)，他的那種模式并不適合按照瀑布型去做，但現(xiàn)在成了積極分子，所以每個項目的模式是不一樣的。
在做敏捷的時候也存在一些容易做的事情和不容易做的事情。比如說SCRUM的項目管理是比較容易去實踐的，就是3個3，對于那些想敏捷的，我建議可以先做這個，還有也會做一些結(jié)對編程、持續(xù)集成的實踐。比較難的，有這么幾點。華為從99年開始都是按照開發(fā)、測試等團隊去運作的，團隊與團隊之間就會形成部門的墻（華為有一個外籍員工給起了一個名字叫Chinese Wall），對每個部門來說，希望把這個墻樹高一點，這樣能獲取更多的資源非常順利的開展工作，所以墻就會越樹越高，很多部門甚至還有checklist，你只要給我什么東西，我就按照checklist打勾，打勾不通過的就要干啥干啥，這樣通過約束管理層，罰款的制度就來了，而這個問題就很難搞，涉及到很多很多的人員，涉及到部門角色定位的問題，這是華為覺得最難的一點。第二難的問題就是TDD，在很多項目都試過，但是試過之后，很多項目都無疾而終，或者訴苦說這個我實在搞不下去，分析后發(fā)現(xiàn)，是涉及人做事情方法的改變，這個挺難的，以前寫代碼都是邊想編寫，就能寫出來，現(xiàn)在你就得先想好、驗證好等等，然后再想辦法填進去，就發(fā)現(xiàn)這個很難，這是一個開發(fā)習(xí)慣的改變，這也是很難的一件事情。第三個，就是Customer Tester，就是要客戶參與驗證，可能對于互聯(lián)網(wǎng)企業(yè)可以部署一個系統(tǒng)，用戶參與測試就可以做起來了，但是對于華為而言，客戶是電信企業(yè)，而電信是買方，買了之后再供他們的客戶去用，這個里面客戶就存在好幾層，所以要客戶真的參與進來還是比較難的。第四點，也是很難的，我們有一個團隊，要到各個團隊去宣傳為什么做敏捷，這涉及到觀念的轉(zhuǎn)變，所以這也是非常難的事情。（一夜的引入，長時間的改變。）比如你說你這個團隊敏捷了，明天就開始站立式會議，但是你最后會發(fā)現(xiàn)，要真正敏捷實際上是一個漫長的過程。
在華為實施敏捷的過程中，也有一些經(jīng)驗性的東西。第一個是QA從警察的角色轉(zhuǎn)變到一個教練的角色。在以前，團隊實施CMM的時候，QA更多的是一個警察的角色，他整天拿著一個checklist、報告什么的到處去團隊里面看，你是否ok，不ok就要怎么怎么樣，整天就干這個活，但是引入敏捷之后，QA就覺得有點失落，都敏捷了，我都不知道該怎么下手了，然后，在華為，就把QA轉(zhuǎn)變了一下，將QA更多的充當(dāng)教練的角色，充當(dāng)SCRUM Master的角色，他去指導(dǎo)項目團隊該如何去開這個站立式會議，該怎么去做迭代的計劃等等指導(dǎo)性的工作，這樣QA也覺得挺好，這樣他能參與到在不同的團隊中去，這樣他見得也多，所以在敏捷的實踐里面是需要這么一些人來干這么一些事情。第二個就是要營造一個一體化的團隊，也就是將所有有墻的部門通通打掉，直接按照項目型運作，把大家拉到一起，不要考慮你原來是什么部門，先把項目做出來再說，這就是在XP的外圈中的Whole Team實踐，因為大家就真正是一條船上的。在很對項目中，總是存在這樣的一些人，項目成功不成功對他們是無關(guān)緊要的，但是有些人項目不成功對他們是非常重要的，而真正的敏捷項目就要這些人來掛帥，并且這些人是站在一條戰(zhàn)線上的，所以就叫拉到一體化的團隊里面來，大家都對交付負責(zé)。第三個就是辦公環(huán)境最好也能夠隨著改變。以前大家都是那種小格間的方式，但是這種方式是非常不利于做交流和做項目的。第四個就是現(xiàn)身說法。前面講到有很多這樣的人會到團隊中去說敏捷怎么怎么好，但是如果你讓一些對項目成功不成功都不相關(guān)的人去講是沒用的，因為大家一聽，首先就會質(zhì)疑50%，所以華為當(dāng)初經(jīng)常搞的活動就是讓項目經(jīng)理他們在講，將他們當(dāng)時是怎么開展敏捷的，這樣別人一聽才能理解到原來你是這么這么做的。
