關於華爲敏捷項目管理

  IPD – 集成產品開發，華爲花重金從IBM購買的一套產品集成開發流程，業界有一本書，PACE講的就是這一套IPD流程，而IPD並不去講你的開發要怎麼做，IPD做的就是“投資決策、市場驅動”，更多的是決定做不做這個事情，做這個事情對於投資人員是不是受控的，所以在IPD裏面會有DCP點（決策評審點），每個點上都會去考慮該不該做、值不值得去做，在引入這個東西以前，華爲實際上是技術驅動的，並不是市場驅動的，就是說以前華爲聽說有個新技術，然後就開始做，做了很多這樣的東西，但是後來都賣不出去，所以後來就引入了IPD，以市場驅動。在引入IPD後，是解決了做什麼的問題，但是怎麼做，還是按照自己的想法去做，後來就引入了CMM，引入CMM後對華爲確實起了非常大的作用，其產品開發的質量確實是比起前提高了，所以在前幾年，通過IPD+CMM使得華爲走向了一個非常成熟的過程。在這個基礎之上，關於質量管理、項目管理華爲提出一些自己的體系，比如從項目的開始到項目的結束，有項目review、度量分析、根因分析、缺陷預防等一系列活動，在項目管理方面有風險管理、問題跟蹤管理等活動，同時還會有質量審計以及相關的推動等事情，通過這些項目管理和質量保證使得IPD和CMM很正常的運作下去，但是現在行業已經發生了一些變化，比如需求變化快等方面華爲也碰到了一些問題，以前產品質量是可控的，大多數產品的發佈週期也是穩定的，比如對客戶承諾什麼時間提交產品基本上是有保證的，另外項目在管理層的進展也是非常清晰化的，你在向某某領導彙報的時候只用告訴他比方項目到了SRS階段了，基本上這個項目的老大就知道這個項目還有多少事情需要去做，比如告訴他到單元測試階段了，他就知道快搞定了，這樣確實使得這個進展能夠口頭化。其實，流程存在的價值，就是能夠給我們的管理層提供進展的可視化，所以從目前來看，對於客戶、員工、管理層這三個利益相關人來講確實達到了這樣一個目的。 

但是現在行業中，需求變化太快，不管我們怎麼努力去做，發現還是不能滿足客戶的需要，不管需求搞得多麼細，到交付產品給客戶的事情，總是有這樣那樣的問題，這個時候就不得不去修改我們的軟件，這是華爲面臨的一個挑戰，如何解決這個問題？ 

軟件開發中有三個要素：人、過程、技術和工具。對於一個軟件項目成功來說，這三個要素都不可省，而在以前大家強調IPD和CMM，更多的是強調大家規範的把它運作起來，對於人、技術和工具基本上不提了，忽略了，所以後來就反饋出一個問題，就是很多項目，看起來那個過程做的那個漂亮，那個報告寫得那個完美，但是交出去的產品那個爛，其實這三個因素是缺一不可的，你必須得均勻的發展，還有一個是人的方面，因爲人是具備創造能力的，所以從華爲的教訓給我啓發，過度的關注過程而忽視人、忽視技術和工具，我們就得要思考和反省了。 

針對這些問題，華爲也就提出了敏捷。華爲在99年之前基本上都是土生土長游擊隊的做法，到了2001年的時候就引入了IPD和CMM，到2006年的時候，就發現了瀑布模型的問題，如交付週期特別長，就是每做一個客戶的需求，然後一分析，這樣一走半年就過去了，所以就引入了RUP，最初的想法就是加速我們項目的交付週期，能夠快速的給客戶響應，但是敏捷實際上已經進入了一個低谷期，所以當時就引入了迭代，實施了一年之後也發現，RUP裏面的東西實際上也是挺多的，所以後來就接觸了XP、SCRUM這些方法，這樣就從07年開始向敏捷這個方向在走。 

有一個圖在業界流傳比較廣泛，也叫洋蔥圖，共分三圈，也就是從三個不同層面描述了敏捷開發方面的一些最佳實踐。XP爲什麼叫極限編程？如果你覺得這個軟件開發的實踐是一個好的實踐，那麼你就把它發揮到極致。比如，結對編程，一個在編，一個人在看，實際上看的人不會白看，其實起到了一個review的作用，既然review這個作用有效，那麼爲什麼不把這個作用發揮到極致，所以就採用了結對編程將review這個作用發揮到極致。在敏捷中有一個8個字的原則：溝通、反饋、交流、勇氣。它認爲項目團隊中的成員這個溝通是比較重要的，既然你非常重要，那麼我也要把你發揮到極致，所以兩個人一起在幹活的時候就會不停的有交流與溝通，所以，結對編程是一個典型的把review、溝通交流發揮到極致的實踐。另外，TDD也可以認爲是那剛好夠用的事情發揮到極致。我們以前傳統的軟件開發的做法是，先做好這個軟件，然後去測，看看是不是實現了這樣一個功能，但是我們總會發現這裏面有很多代碼其實是從來就沒有用過的，只是在下代碼的時候順手就把它寫了，在分析那些產品的時候發現有的產品這樣的沒用到的代碼高達50%，而TDD的思想是，我既然要實現什麼功能，然後我就先寫對應的用例來驗證它，然後在開發的時候就開始寫代碼，使得這個用例剛好通過，這樣就使得我們寫出來的代碼是剛好滿足這個系統的功能的代碼，這樣，前面出現的50%就可以不用做了，這就是把剛好夠用發揮到極致。其他的就不一一講了。XP在2001年到2003年之間非常的紅火，過了之後又相對的沉寂了一點，現在又冒出來一個新的敏捷的方法論，就是SCRUM。XP是過分的強調將軟件開發裏面的實踐發揮到極致，而這些實踐都是同編程實踐相關，但是在管理方面就比較弱，所以，在用了幾年之後，大家發揮XP不是起到那麼大的作用，所以就開始沉寂下來。這個時候就出現一個流派，就是SCRUM。SCRUM其實就是一個非常非常輕量的項目管理框架，基本上沒有什麼編碼實踐方面的東西，你說看到的都是管理上的活動，這個管理上的活動很多人就會有一種似曾相識的感覺，記得前不久，同華爲的一個項目團隊在聊，就談到這個項目的backlog，一講，項目團隊的人就說其實他就是那樣子做的，他以前也沒與聽說過什麼SCRUM，就是把這些需求一條一條的列出來，鎳鎘優先級，估個工作量，一看，就是這個東西。SCRUM的核心其實比較簡單，2分鐘就能講出來，就是3個3。一、3個角色。Product Owner，負責決定產品要做什麼，做成什麼樣子；SCRUM Master，保證項目能夠遵循SCRUM的方式運作下來；項目團隊成員，包含開發、測試、質量等等所有的人。二、3種會議。迭代的計劃會議、中間的站立式會議、迭代的評估會議，屬於三個管理的活動。三、3個交付件。待開發的任務列表、待修復的缺陷任務列表、項目的進度圖。SCRUM就是通過這3個3將項目非常簡潔的管理起來，有一個思考就是關於PMP裏面講到的9大領域多少活動不一定對這種敏捷項目適用。那麼大家可能提出一個疑問，就是項目的進度是不是就不可視了。其實，敏捷項目的進度可視很簡單，就是通過一個白板（進度牆、任務看板），將每個人的進度情況這麼一貼，這就是最簡單最直接的管理方式，一看，所有人都知道，就算你去開發一些什麼複雜的一些IT支撐系統，可能都起不到這個白板的作用。在華爲關於敏捷的一些項目管理工具，用Scrumworks、Bingo這些管理工具也能夠把項目的進度管理起來，但是你要做的就是必須得把電腦打開，要把瀏覽器打開，這樣才能看到你的進度是什麼樣子的，而在辦公區直接樹一個白板就能夠很簡單、很方便的知道我的這個進度情況。所以，在華爲，對於敏捷項目，管理的框架上是採用的SCRUM，指導如何編碼實現上就採用了一些XP的實踐，當然XP的實踐不會全部去選，會根據項目的實際情況去選一些實踐，如果你把所有實踐都選的話，實際上的效果是非常差的。那麼如何來選擇就得根據項目的實際情況去評價。華爲在實踐的過程中也引入了精益、消除浪費的思想。比如，在平時的工作中存在停工等活的浪費。什麼是停工等活的浪費呢？比如我們開發在做開發的時候，我們的測試就會輕鬆一點，那麼測試在做測試的時候我們的開發就會輕鬆一點，大家覺得這樣也挺好的，但是你從整個組織角度去分析，實際上是停工等活的，開發時測試在等着，測試時開發在等着，如果你從精益的角度考慮的話，爲何不通過迭代的方式把開發和測試等待的時候整合在一起來工作，使得效益得到提升。有很多項目團隊自己去做了，確實效果比較明顯。其實在2006年實踐RUP的時候就感覺到這樣的好處了是非常明顯的。引入敏捷之後，自然而然的就會想到同公司已有流程之間的關係，原來是IPD+CMM，所以就有同事問到是不是我這個就不用了。分析可以知道，IPD是決定做不做，決定之後如何去做就可以採用敏捷開發，所以對於敏捷產品的流程就是IPD+敏捷的方式，所以有很多以前採用瀑布型的團隊逐步的被敏捷代替了，還有些團隊正在代替中，還有些團隊就覺得原來那套玩得很流暢就繼續採用原來的方式。所以目前在華爲，項目團隊是可以自己來選擇採用哪種方式進行，現在可以發現，那些願意選擇敏捷方式走的往往就是原來那些頑固不化的爛項目，因爲以前在推流程的時候，那幫人整天在那裏叫，有問題，我不幹，我不願意做，實際上，後來做深入分析發現，他的那種模式並不適合按照瀑布型去做，但現在成了積極分子，所以每個項目的模式是不一樣的。 

在做敏捷的時候也存在一些容易做的事情和不容易做的事情。比如說SCRUM的項目管理是比較容易去實踐的，就是3個3，對於那些想敏捷的，我建議可以先做這個，還有也會做一些結對編程、持續集成的實踐。比較難的，有這麼幾點。華爲從99年開始都是按照開發、測試等團隊去運作的，團隊與團隊之間就會形成部門的牆（華爲有一個外籍員工給起了一個名字叫Chinese Wall），對每個部門來說，希望把這個牆樹高一點，這樣能獲取更多的資源非常順利的開展工作，所以牆就會越樹越高，很多部門甚至還有checklist，你只要給我什麼東西，我就按照checklist打勾，打勾不通過的就要幹啥幹啥，這樣通過約束管理層，罰款的制度就來了，而這個問題就很難搞，涉及到很多很多的人員，涉及到部門角色定位的問題，這是華爲覺得最難的一點。第二難的問題就是TDD，在很多項目都試過，但是試過之後，很多項目都無疾而終，或者訴苦說這個我實在搞不下去，分析後發現，是涉及人做事情方法的改變，這個挺難的，以前寫代碼都是邊想編寫，就能寫出來，現在你就得先想好、驗證好等等，然後再想辦法填進去，就發現這個很難，這是一個開發習慣的改變，這也是很難的一件事情。第三個，就是Customer Tester，就是要客戶參與驗證，可能對於互聯網企業可以部署一個系統，用戶參與測試就可以做起來了，但是對於華爲而言，客戶是電信企業，而電信是買方，買了之後再供他們的客戶去用，這個裏面客戶就存在好幾層，所以要客戶真的參與進來還是比較難的。第四點，也是很難的，我們有一個團隊，要到各個團隊去宣傳爲什麼做敏捷，這涉及到觀念的轉變，所以這也是非常難的事情。（一夜的引入，長時間的改變。）比如你說你這個團隊敏捷了，明天就開始站立式會議，但是你最後會發現，要真正敏捷實際上是一個漫長的過程。 

在華爲實施敏捷的過程中，也有一些經驗性的東西。第一個是QA從警察的角色轉變到一個教練的角色。在以前，團隊實施CMM的時候，QA更多的是一個警察的角色，他整天拿着一個checklist、報告什麼的到處去團隊裏面看，你是否ok，不ok就要怎麼怎麼樣，整天就幹這個活，但是引入敏捷之後，QA就覺得有點失落，都敏捷了，我都不知道該怎麼下手了，然後，在華爲，就把QA轉變了一下，將QA更多的充當教練的角色，充當SCRUM Master的角色，他去指導項目團隊該如何去開這個站立式會議，該怎麼去做迭代的計劃等等指導性的工作，這樣QA也覺得挺好，這樣他能參與到在不同的團隊中去，這樣他見得也多，所以在敏捷的實踐裏面是需要這麼一些人來幹這麼一些事情。第二個就是要營造一個一體化的團隊，也就是將所有有牆的部門通通打掉，直接按照項目型運作，把大家拉到一起，不要考慮你原來是什麼部門，先把項目做出來再說，這就是在XP的外圈中的Whole Team實踐，因爲大家就真正是一條船上的。在很對項目中，總是存在這樣的一些人，項目成功不成功對他們是無關緊要的，但是有些人項目不成功對他們是非常重要的，而真正的敏捷項目就要這些人來掛帥，並且這些人是站在一條戰線上的，所以就叫拉到一體化的團隊裏面來，大家都對交付負責。第三個就是辦公環境最好也能夠隨着改變。以前大家都是那種小格間的方式，但是這種方式是非常不利於做交流和做項目的。第四個就是現身說法。前面講到有很多這樣的人會到團隊中去說敏捷怎麼怎麼好，但是如果你讓一些對項目成功不成功都不相關的人去講是沒用的，因爲大家一聽，首先就會質疑50%，所以華爲當初經常搞的活動就是讓項目經理他們在講，將他們當時是怎麼開展敏捷的，這樣別人一聽才能理解到原來你是這麼這麼做的。