第一篇：Scrum Agile敏捷項目管理歸納總結

D:iknowdocsharedatacur_work80505777.docx 《Scrum/Agile敏捷項目管理》歸納總結

前言

此文檔是由我閱讀《Scrum敏捷項目管理》Ken Schwaber著，清華大學出版社。歸納總結Agile項目管理的核心內容。

核心精髓

? 20/80法則

20%交付功能代表80%的最終商業價值。

? 敏捷團隊組成

Scrum Master，產品負責人，團隊。

? Sprint計劃會議

此會議限時8個小時。分兩部分，各4小時。第一部分挑選Backlog，第二部分準備Sprint Backlog 與會者包括ScrumMaster、產品負責人和團隊?？裳埰渌藛T補充業務或技術領域的信息和建議，在信息提供完畢后離開。雞類人員不可擔任觀察者。

產品負責人應在會議前準備好產品Backlog.如果缺少產品負責人或產品Backlog的情況下，ScrumMaster需要代理些職。第一部分會議

會議第一部分（前4個小時）團隊的目標是挑選將承諾轉化為潛在可交付產品功能增量的產品Backlog條目。團隊將在Sprint結束時的評審會議上，向產品負責人和利益相關者展示該功能。團隊可提建議，但由產品負責人制定Sprint產品Backlog。

團隊負責從產品負責人制定的Backlog中挑選出期望在當前Sprint內完成工作。第一部分會議結束后立即召開第二部分Sprint計劃會。限時4小時。第二部分會議

產品負責人必須出席，回答團隊對產品Backlog可能的疑問。

團隊必須獨立決定如何將選定的產品Backlog轉化為潛在可交付的產品功能增量，該過程中團隊不接受外界指導。

第二部會議將制定出”Sprint Backlog”。是一張包括任務、任務預估及開發功能的工作分配清單。任務清單不一定完整，但必須反映團隊全體成員的共同承諾，以順利完成Sprint第一部分，在過程中團隊可以為Sprint Backlog增加其他任務。

/ 2

D:iknowdocsharedatacur_work80505777.docx ? 每日Scrum簡會

不論團隊人數多少，每日Scrum簡會限時15分鐘。

在每個工作日的同一時間，同一地點召開每日Scrum簡會。它是全天工作中的第一件事。

團隊全體成員必須出席。如某位成員無法出席，則應參加電話會議或請其他成員代為報告工作情況。團隊成員必須準時。不論出席情況如何，Scrum必須在指定時間開始會議。SrcumMaster請他（她）左邊第一位成員開始匯報情況。團隊每位成員僅回答3個問題。

1，自上次Scrum簡會后的1天里你為該項目做了什么？

2，從現在到下次Scrum簡會后的1天里你準備為項目做什么？

3，什么妨礙你盡可能高效的工作。

會議圍繞上述3個問題展開，成員不得離題講其它事宜、設計、討論問題或閑談。ScrumMaster確保成員輪流且干脆利落地匯報工作。

每日Scrum簡會不得有人同時發言。發言人匯報工作情況，其它與會者是聽眾，不可在一旁私下談話。與某位成員匯報的情況涉及其他成員興趣或需要他們協助時，可在每日Scrum簡會后立即召集有關人員開會。

雞類人員不得講話、評論等。并站在團隊外圍，以免干擾會議。若雞類人員出席人員過多，ScrumMaster有權限制出席人數。確保會議有序、集中。雞類人員不得在會后請團隊成員深入解或向團隊提供建議和指示。

不能遵守上述規定的豬類或雞類人員將被禁止雞類參加會議或把豬類開除出團隊。

/ 2

第二篇：關于華為敏捷項目管理

華為公司項目管理

關于華為敏捷項目管理

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的方式運作下來；項目團隊成員，包含開發、測試、質量等等所有的人。

二、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更多的充當教練的角色，充當的角色，他去指導項目團隊該如何去開這個站立式會議，該怎么去做迭代的計劃等等指導性的工作，這樣QA也覺得挺好，這樣他能參與到在不同的團隊中去，這樣他見得也多，所以在敏捷的實踐里面是需要這么一些人來干這么一些事情。第二個就是要營造一個一體化的團隊，也就是將所有有墻的部門通通打掉，直接按照項目型運作，把大家拉到一起，不要考慮你原來是什么部門，先把項目做出來再說，這就是在XP的外圈中的Whole Team實踐，因為大家就真正是一條船上的。在很對項目中，總是存在這樣的一些人，項目成功不成功對他們是無關緊要的，但是有些人項目不成功對他們是非常重要的，而真正的敏捷項目就要這些人來掛帥，并且這些人是站在一條戰線上的，所以就叫拉到一體化的團隊里面來，大家都對交付負責。第三個就是辦公環境最好也能夠隨著改變。以前大家都是那種小格間的方式，但是這種方式是非常不利于做交流和做項目的。第四個就是現身說法。前面講到有很多這樣的人會到團隊中去說敏捷怎么怎么好，但是如果你讓一些對項目成功不成功都不相關的人去講是沒用的，因為大家一聽，首先就會質疑50%，所以華為當初經常搞的活動就是讓項目經理他們在講，將他們當時是怎么開展敏捷的，這樣別人一聽才能理解到原來你是這么這么做的。

第三篇：淺談敏捷項目管理和PMP

淺談敏捷項目管理和PMP

敏捷項目管理方法一般適用于中小型研發項目，追求項目管理態度，方式上的“敏捷”，推崇“以構架為中心、用例驅動、迭代開發”，從而達到快速交付的目的。PMBOK的理念是項目應該具備完備的可持續改進的項目計劃，并時時強調項目管理計劃的更新持續于項目整個生命期。項目管理者聯盟

敏捷項目管理聲稱要擺脫繁冗的流程制度文檔，但是對于關鍵的項目文檔，比如需求規格說明書等，也是要求必須具備的。所以，敏捷項目管理在項目流程制度上的管理可以看作是對一套完善的項目管理流程制度的裁剪，只不過這個裁剪的尺度較大，從而也對敏捷項目團隊成員的適應性，自主性提出了較高的要求。項目管理者聯盟

具體的敏捷方法(以SCRUM為例)在每個迭代周期中都存在立會制度，燃盡圖、看板監控，計劃發布等，這些和PMBOK中對項目生命期的五個過程組啟動，規劃，執行，監控和收尾的定義沒有沖突矛盾。實際上，敏捷項目管理的這些措施可以看作是PMBOK項目生命期五個過程組執行的微縮版，區別在于，敏捷項目管理的迭代周期時間很短，在其執行過程中，裁剪了許多規范正式的項目管理流程制度。項目管理者聯盟

敏捷項目管理方法在IT研發領域取得了一定的成效，但是這種項目管理方法對項目團隊的整體素質提出了較高的要求。同時，對項目管理者的團隊建設水平也提出了較高的要求。敏捷項目管理追求的“敏捷”，雖然貌似在項目管理流程制度等項目管理建設金字塔的底層“硬件”部分要求不高，但是對項目管理軟技巧這些例如團隊建設，溝通協調，領導力，激勵等項目管理建設金字塔的高層“軟件”部分，提出了更高的要求。項目管理者聯盟

個人認為，一個項目管理者如果具備卓越的項目管理能力，那么他首先應該精通項目管理建設金字塔的底層建設，只有系統掌握了項目管理體系理論，結合工作經驗，項目管理者才能逐漸凝練出自己對于軟技巧的總結，從而進行更符合實際情況的應用，才能做到有的放矢。沒有系統知識體系的積累奠基，所謂的軟技巧就如無本之木，無源之水。因此，作為敏捷項目的項目管理者，學習掌握專業的項目管理知識體系也是十分必要的。

第四篇：(講座1)智慧的敏捷項目團隊管理

報告題目：智慧的敏捷項目團隊管理 報告人：DJ Ning

IBM Rational 中國區技術總監

講座時間：2011年1月22日晚上（周六）5：30-8:45 講座地點：交大徐匯校區工程館212教室

一、大會主要內容

1月22日大會上，DJ Ning主要講述了什么是敏捷方法、敏捷方法的提出、敏捷建模、敏捷開發的生命周期等內容。敏捷方法（XP、SCRUM、Feature－Driven Development、Crystal、DSDM、Agile Unified Process、Adaptive）是一個靈活的開發方法，用于在一個動態的環境中向干系人快速交付價值，努力在軟件開發過程當中減少變化帶來的成本。個人和交互代替原有的流程和工具，可運行的軟件代替原有的復雜文檔，與客戶的協作代替基于合同按部就班的操作，快速響應變更代替原有的遵循計劃。例如，XP使用快速迭代計劃和開發循環盡早地產生最有價值的特性。另外，XP中的持續的、系統化的測試確保高質量，盡早發現缺陷和相應的解決方案。

二、聽后感

現在，在IT預算被大幅度地削減的情況下，我們的IT管理人員的壓力仍然在不斷增大。同時，業務環境正以非常高的速度持續改變，這使IT艱苦奮斗，以便能夠跟上這種變化速度。這些變化導致了以“快速發布和靈活而又高質量的維護為承諾”的敏捷軟件開發方法論產生了很大的興趣。

軟件的項目管理目前面臨諸多挑戰，軟件項目開發的進度難于預測，需求在不斷變化，而且速度快，變化的范圍同時也難于控制，團隊協作不夠，配置和變更管理不當等都造成我們曾經有些項目無法完成。

我認為，加強管理才是敏捷方法被成功采納并應用的關鍵，然而傳統項目管理方法學和工具卻與這些新的敏捷方法缺少關聯。而這種低關聯性就是深層次問題的癥狀。這些深層次問題表現在：對于處理變化、控制、命令、組織、人員以及解決方案等方面的基本假設方面的不同。

結合日常的工作，采用敏捷開發可以更早地持續地交付有價值的軟件，可以滿足我們的需求，即使到了開發的后期，也能夠適應變更；頻繁交付可工作的軟件，而可工作的軟件是度量進度的主要標準；我們的業務人員和開發人員必須每天協同工作；圍繞著激勵起來的個人來構建項目；面對面的交談是最有效和效率最高的溝通方法；提倡可持續的開發速度；持續的優化技術和設計；簡單是工作效率最大化的藝術；最好的架構、需求和設計，出自自組織團隊；定期總結回顧，思考我們的團隊如何更加高效，并作出相應調整。

一個好的團隊是項目是否成功實施的基礎。高效的團隊所具備的基本要素應該有：承諾使用統一方法，互相依賴、互相負責；少數成員要注重實效，容易分享和溝通，打造共同的團隊價值觀；技能互補，解決問題和決策，并且注重人際關系技巧；承諾為共同的目標而奮斗。

在敏捷項目中，我們的客戶需求在整個生命周期中是不斷變化的；我們單位在過去傳統項目中，客戶需求在一開始是被完整定義的和靜態的，明確了高層次的需求，并進行優先級劃分，往往時間是影響緊急業務需求交付的關鍵約束，資源又是固定的，并被有效管理以在指定成本內交付。項目交付周期從傳統的瀑布模型轉變為迭代式的敏捷項目生命周期，即將長的、復雜的項目周期變為短的、簡單的迭代周期；明確項目的完成時間往往又不是一個時間點，而是一種可能性的分布。這樣使用里程碑交付件作為一種有效的評測軟件；提出合適的項目計劃；盡早反饋和經常反饋；迭代地、增量地交付可工作的交付件。

第五篇：項目管理總結

1.項目是為提供某項獨特的產品，服務或成果所做的臨時性努力。

2.項目的特點：臨時性、獨特性、漸進明細

3.項目管理的核心：任務分解；傳統管理的核心：持續改進

4.項目管理的十大知識體系：質量、范圍、時間、成本、進度、溝通、風險、人力資源、采購、項目干系人

傳統管理：計劃、組織、領導、控制

5.項目管理四要素：范圍、成本、進度、質量

6.項目存在優先級，pmo項目管理辦公室負責安排優先級

7.項目管理的核心思想是平衡

8.項目五大過程組：項目啟動，計劃過程，監控過程、執行過程、收尾過程

不同項目階段不同，但五大過程組相同，每個階段都有五大過程組，階段中不可能有監控，監控貫穿整個項目

9.項目管理共有44個階段

10.項目經理要求平衡質量（最重要），范圍、時間和成本，確定清晰能實現的目標，使技術規范、計劃和方法適用于不同的需求與期望

11.產品的生命階段是產品從產生到消亡的全生命階段，包括概念、計劃、開發、驗證、發布、運維標準六階段（構思+研制+使用維護）

12.項目的生命周期是從產生到消亡的全生命過程，由多個項目階段的組合形成，包括CDIT四個階段（項目立、項目啟動、項目發展成熟、項目完成）

13.狀況分析、原因分析、決策分析、風險分析

14.極其復雜的的研究階段稱為系統，即相互作用和相互依賴的若干個組成部分結合成的具有特定功能的游記整體，從屬更大的系統（子系統）（系統—子系統—模塊—單元）

15.系統思維是把觀察、處理的對象看做一個系統，不僅要看到系統的組成要素，更要看到這些要素間的相互關系，從整體的角度把人、物、能量、信息加以處理協調。

16.所有復雜的系統背后是簡單的原理，系統越復雜，原理越簡單。若有沖突則是存在錯誤的假設，是人為錯誤

17.項目范圍強調過程，產品范圍強調結果

18.WBS（工作任務分解）是面向可交付成果的層次化分解，有機組織定義整個項目，將項目分為較小的，易管理的工作，每分解一層表示更詳細的定義。

19.WBS底層必須是有明確責任人的工作包，先基于階段，再基于成果，使用組織管理，滿足80小時原則，大型項目可先分為子項目，再進行階段和產出分解

20.總和最大的為關鍵路徑，從開始到結束差為0，可能存在多條，對關鍵路徑進行工期壓縮要考慮次關鍵路徑的產生，未考慮資源約束。

21.關鍵路徑是有充分資源的情況下，關鍵鏈則是有關鍵資源的情況下

22.關鍵鏈法（1）項目緩沖 非關鍵路徑至少擠掉50%，在最后留緩沖。

（2）接駁緩沖 放置在關鍵鏈末端的稱為項目緩沖，其他的緩沖為接駁緩沖放置在非關鍵鏈和關鍵鏈的結合點，防止關鍵鏈受非關鍵鏈延誤影響。

（3）關鍵路徑 經過需要關鍵資源的所有任務（關鍵鏈）的最長路徑

23關鍵鏈不管理總浮動時間，管理剩余的緩沖持續時間和剩余任務鏈持續時間之間的匹配關系，可以按可能的最晚開始時間和最晚的完成時間來安排活動

24.關鍵鏈法解決三大問題

（1）項目中所有環節的延遲會積累，提前不一定（延遲稱為墨菲襲擊）

（2）每個子環節都有巨大的緩沖，且會被浪費

（3）項目管理一定會延遲是因為不良多功？？

25.toc約束理論，業績都受制于它的制約因素、局部改善不意味著整體改善、系統能力受瓶頸制約、進度計劃因考慮資源瓶頸、因考慮改善瓶頸效率

26.我不知道

未知區 隱藏區 我知道 盲區 你知道 杰亨利窗框 開放區

你不知道

27.表揚針對行為、動機、期待，批評針對行為、后果、期待，要對未來提問

28.風險管理分為風險預測、風險預案（確定責任人）、補救性方案（確定啟動機制）

29.項目經理在采購中的作用：必須參與到合同的創立過程中，確立控制地位，參與談判，識別各種風險，通過合同來減少項目的風險，幫助合同適合項目，使采購符合項目進度，維護與賣房的關系。

30.項目經理的提升之路是使其能力與其面臨的挑戰相匹配。