ipd – 整合產品開發，華為花重金從ibm購買的一套產品整合開發流程，業界有一本書，pace講的就是這一套ipd流程，而ipd並不去講你的開發要怎麼做，ipd做的就是「投資決策、市場驅動」，更多的是決定做不做這個事情，做這個事情對於投資人員是不是受控的，所以在ipd裡面會有dcp點（決策評審點），每個點上都會去考慮該不該做、值不值得去做，在引入這個東西以前，華為實際上是技術驅動的，並不是市場驅動的，就是說以前華為聽說有個新技術，然後就開始做，做了很多這樣的東西，但是後來都賣不出去，所以後來就引入了ipd，以市場驅動。在引入ipd後，是解決了做什麼的問題，但是怎麼做，還是按照自己的想法去做，後來就引入了cmm，引入cmm後對華為確實起了非常大的作用，其產品開發的質量確實是比起前提高了，所以在前幾年，通過ipd+cmm使得華為走向了乙個非常成熟的過程。在這個基礎之上，關於質量管理、專案管理華為提出一些自己的體系，比如從專案的開始到專案的結束，有專案review、度量分析、根因分析、缺陷預防等一系列活動，在專案管理方面有風險管理、問題跟蹤管理等活動，同時還會有質量審計以及相關的推動等事情，通過這些專案管理和質量保證使得ipd和cmm很正常的運作下去，但是現在行業已經發生了一些變化，比如需求變化快等方面華為也碰到了一些問題，以前產品質量是可控的，大多數產品的發布週期也是穩定的，比如對客戶承諾什麼時間提交產品基本上是***的，另外專案在管理層的進展也是非常清晰化的，你在向某某領導匯報的時候只用告訴他比方專案到了srs階段了，基本上這個專案的老大就知道這個專案還有多少事情需要去做，比如告訴他到單元測試階段了，他就知道快搞定了，這樣確實使得這個進展能夠口頭化。其實，流程存在的價值，就是能夠給我們的管理層提供進展的視覺化，所以從目前來看，對於客戶、員工、管理層這三個利益相關人來講確實達到了這樣乙個目的。
但是現在行業中，需求變化太快，不管我們怎麼努力去做，發現還是不能滿足客戶的需要，不管需求搞得多麼細，到交付產品給客戶的事情，總是有這樣那樣的問題，這個時候就不得不去修改我們的軟體，這是華為面臨的乙個挑戰，如何解決這個問題？
針對這些問題，華為也就提出了敏捷。華為在99年之前基本上都是土生土長游擊隊的做法，到了2023年的時候就引入了ipd和cmm，到2023年的時候，就發現了瀑布模型的問題，如交付週期特別長，就是每做乙個客戶的需求，然後一分析，這樣一走半年就過去了，所以就引入了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的方式運作下來；專案團隊成員，包含開發、測試、質量等等所有的人。
二、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更多的充當教練的角色，充當的角色，他去指導專案團隊該如何去開這個站立式會議，該怎麼去做迭代的計畫等等指導性的工作，這樣qa也覺得挺好，這樣他能參與到在不同的團隊中去，這樣他見得也多，所以在敏捷的實踐裡面是需要這麼一些人來幹這麼一些事情。第二個就是要營造乙個一體化的團隊，也就是將所有有牆的部門通通打掉，直接按照專案型運作，把大家拉到一起，不要考慮你原來是什麼部門，先把專案做出來再說，這就是在xp的外圈中的whole team實踐，因為大家就真正是一條船上的。在很對專案中，總是存在這樣的一些人，專案成功不成功對他們是無關緊要的，但是有些人專案不成功對他們是非常重要的，而真正的敏捷專案就要這些人來掛帥，並且這些人是站在一條戰線上的，所以就叫拉到一體化的團隊裡面來，大家都對交付負責。第三個就是辦公環境最好也能夠隨著改變。以前大家都是那種小格間的方式，但是這種方式是非常不利於做交流和做專案的。第四個就是現身說法。前面講到有很多這樣的人會到團隊中去說敏捷怎麼怎麼好，但是如果你讓一些對專案成功不成功都不相關的人去講是沒用的，因為大家一聽，首先就會質疑50%，所以華為當初經常搞的活動就是讓專案經理他們在講，將他們當時是怎麼開展敏捷的，這樣別人一聽才能理解到原來你是這麼這麼做的。
敏捷專案管理
敏捷專案管理 apm 由jim highsmith所著的一書敏捷專案管理，試圖擴大敏捷技術為乙個整體。敏捷專案管理 引入敏捷專案管理步驟同pmi所採用的專案管理步驟結合 調整傳統鐵三角強調價值和質量，建立敏捷三角。傳統鐵三角 範圍 成本 進度 敏捷三角 價值 質量 制約因素 成本 進度 範圍 敏捷鐵...
敏捷專案管理
敏捷開發遵循軟體客觀規律，不斷的進行迭代增量開發，最終交付復合客戶價值的產品。敏捷宣言 敏捷開發原則 敏捷包括三個層次 精益七大浪費 技術債務 變化無法一次性 一開始製作大而全的計畫易造成浪費 應根據迭代積累的經驗和需求變化的情況對計畫不斷調整和細化 多層次反饋 敏捷軟體開發是以短週期迭代為核心，包...
05 敏捷專案管理 敏捷專案管理模式筆記
00.在敏捷圈內，流程被指責為靜止的 常規的和難以改變的。就流程本身而言，不應該是負面的，它必須同企業目標聯絡起來。如果目標是重複性的製造，那麼常規性流程是完全合理的 而如果目標是可靠的創新，則流程架構必須是有組織的 靈活的和容易適應的。支援構想 探索 自律的團隊 支援自我組織 自律的團隊 根據專案...