關於華為敏捷專案管理
ipd – 整合產品開發，華為花重金從ibm購買的一套產品整合開發流程，業界有一本書，pace講的就是這一套ipd流程，而ipd並不去講你的開發要怎麼做，ipd做的就是「投資決策、市場驅動」，更多的是決定做不做這個事情，做這個事情對於投資人員是不是受控的，所以在ipd裡面會有dcp點（決策評審點），每個點上都會去考慮該不該做、值不值得去做，在引入這個東西以前，華為實際上是技術驅動的，並不是市場驅動的，就是說以前華為聽說有個新技術，然後就開始做，做了很多這樣的東西，但是後來都賣不出去，所以後來就引入了ipd，以市場驅動。在引入ipd後，是解決了做什麼的問題，但是怎麼做，還是按照自己的想法去做，後來就引入了cmm，引入cmm後對華為確實起了非常大的作用，其產品開發的質量確實是比起前提高了，所以在前幾年，通過ipd+cmm 使得華為走向了乙個非常成熟的過程。在這個基礎之上，關於質量管理、專案管理華為提出一些自己的體系，比如從專案的開始到專案的結束，有專案 review、度量分析、根因分析、缺陷預防等一系列活動，在專案管理方面有風險管理、問題跟蹤管理等活動，同時還會有質量審計以及相關的推動等事情，通過這些專案管理和質量保證使得ipd和cmm很正常的運作下去，但是現在行業已經發生了一些變化，比如需求變化快等方面華為也碰到了一些問題，以前產品質量是可控的，大多數產品的發布週期也是穩定的，比如對客戶承諾什麼時間提交產品基本上是***的，另外專案在管理層的進展也是非常清晰化的，你在向某某領導匯報的時候只用告訴他比方專案到了srs階段了，基本上這個專案的老大就知道這個專案還有多少事情需要去做，比如告訴他到單元測試階段了，他就知道快搞定了，這樣確實使得這個進展能夠口頭化。
其實，流程存在的價值，就是能夠給我們的管理層提供進展的視覺化，所以從目前來看，對於客戶、員工、管理層這三個利益相關人來講確實達到了這樣乙個目的。
但是現在行業中，需求變化太快，不管我們怎麼努力去做，發現還是不能滿足客戶的需要，不管需求搞得多麼細，到交付產品給客戶的事情，總是有這樣那樣的問題，這個時候就不得不去修改我們的軟體，這是華為面臨的乙個挑戰，如何解決這個問題？
軟體開發中有三個要素：人、過程、技術和工具。對於乙個軟體專案成功來說，這三個要素都不可省，而在以前大家強調ipd和cmm，更多的是強調大家規範的把它運作起來，對於人、技術和工具基本上不提了，忽略了，所以後來就反饋出乙個問題，就是很多專案，看起來那個過程做的那個漂亮，那個報告寫得那個完美，但是交出去的產品那個爛，其實這三個因素是缺一不可的，你必須得均勻的發展，還有乙個是人的方面，因為人是具備創造能力的，所以從華為的教訓給我啟發，過度的關注過程而忽視人、忽視技術和工具，我們就得要思考和反省了。
針對這些問題，華為也就提出了敏捷。華為在99年之前基本上都是土生土長游擊隊的做法，到了2023年的時候就引入了ipd和cmm，到2006 年的時候，就發現了瀑布模型的問題，如交付週期特別長，就是每做乙個客戶的需求，然後一分析，這樣一走半年就過去了，所以就引入了rup，最初的想法就是加速我們專案的交付週期，能夠快速的給客戶響應，但是敏捷實際上已經進入了乙個低谷期，所以當時就引入了迭代，實施了一年之後也發現，rup裡面的東西實際上也是挺多的，所以後來就接觸了xp、scrum這些方法，這樣就從07年開始向敏捷這個方向在走。
有乙個圖在業界流傳比較廣泛，也叫洋蔥圖，共分三圈，也就是從三個不同層面描述了敏捷開發方面的一些最佳實踐。xp為什麼叫極限程式設計？如果你覺得這個軟體開發的實踐是乙個好的實踐，那麼你就把它發揮到極致。
比如，結對程式設計，乙個在編，乙個人在看，實際上看的人不會白看，其實起到了乙個review 的作用，既然review這個作用有效，那麼為什麼不把這個作用發揮到極致，所以就採用了結對程式設計將review這個作用發揮到極致。在敏捷中有乙個8個字的原則：溝通、反饋、交流、勇氣。
它認為專案團隊中的成員這個溝通是比較重要的，既然你非常重要，那麼我也要把你發揮到極致，所以兩個人一起在幹活的時候就會不停的有交流與溝通，所以，結對程式設計是乙個典型的把review、溝通交流發揮到極致的實踐。另外，tdd也可以認為是那剛好夠用的事情發揮到極致。我們以前傳統的軟體開發的做法是，先做好這個軟體，然後去測，看看是不是實現了這樣乙個功能，但是我們總會發現這裡面有很多**其實是從來就沒有用過的，只是在下**的時候順手就把它寫了，在分析那些產品的時候發現有的產品這樣的沒用到的**高達50%，而tdd的思想是，我既然要實現什麼功能，然後我就先寫對應的用例來驗證它，然後在開發的時候就開始寫**，使得這個用例剛好通過，這樣就使得我們寫出來的**是剛好滿足這個系統的功能的**，這樣， 前面出現的50%就可以不用做了，這就是把剛好夠用發揮到極致。
其他的就不一一講了。xp在2023年到2023年之間非常的紅火，過了之後又相對的沉寂了一點，現在又冒出來乙個新的敏捷的方**，就是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的實踐不會全部去選，會根據專案的實際情況去選一些實踐，如果你把所有實踐都選的話，實際上的效果是非常差的。那麼如何來選擇就得根據專案的實際情況去評價。華為在實踐的過程中也引入了精益、消除浪費的思想。
比如，在平時的工作中存在停工等活的浪費。什麼是停工等活的浪費呢？比如我們開發在做開發的時候，我們的測試就會輕鬆一點，那麼測試在做測試的時候我們的開發就會輕鬆一點，大家覺得這樣也挺好的，但是你從整個組織角度去分析，實際上是停工等活的，開發時測試在等著，測試時開發在等著，如果你從精益的角度考慮的話，為何不通過迭代的方式把開發和測試等待的時候整合在一起來工作，使得效益得到提公升。
有很多專案團隊自己去做了，確實效果比較明顯。其實在2023年實踐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%，所以華為當初經常搞的活動就是讓專案經理他們在講，將他們當時是怎麼開展敏捷的，這樣別人一聽才能理解到原來你是這麼這麼做的。
年輕的專案經理實際工程管理經驗
應該充分利用現場的協調會議制度，施工中甲方 專案經理應定期組織舉行協調會議，解決施工中的協調問題。對於較複雜的部位，在施工前應組織專門的協調會，使各專業隊進一步明確施工順序和責任。結合我這些年的管理經驗 專案管理除了要管好人 工人 管理人員 懂得如何激勵員工的士氣。還要學會培養員工的能力，利用好手下...
專案管理經驗
簡介 經過近四年多的學習及相關的生產實習，我對今年的工作充滿信心，在這裡我將對工程的理解程度以及對工程管理辦法進行自我闡述，首先作為乙個專案經理，確定自己的地位，專案經理是業主與乙方共同利益的體現者，對工程進行綜合的動態的管理，專案經理應有的職責就是對工程進行三控制 二管理 一協調。關鍵字 工程專案...
專案管理經驗總結
篇一 各種專案管理經驗總結大全 如何在乙個專案中從啟動 執行 完成這一過程中，在做好專案管理的基礎上，使團隊所有成員在做人做事方面有所提高？減少溝通成本是做好專案管理和團隊管理的重要前提條件，而且是貫穿整個流程之中。1 幫助新人快速理解原來團隊的氛圍，知識，降低後期的溝通成本。一方面要提前將內部約定...