第一部分 理解敏捷
第1章 項目管理現(xiàn)代化
1.理解為何項目管理需要變革
在敏捷項目管理方式之前的瀑布式項目管理因為在項目的需求沐悦、設計侥蒙、開發(fā)、集成印机、測試矢腻、部署階段，只有前一個階段完成后射赛，才能進入下一階段多柑，導致在項目初期做了看起來需要的功能，隨著技術的發(fā)展楣责，出現(xiàn)了范圍膨脹（軟件投產(chǎn)后實際被使用到的特性比例很低）竣灌，造成了大量資源的浪費聂沙。
2.了解敏捷項目管理
（1）敏捷項目管理遵循敏捷宣言和敏捷原則
（2）敏捷項目的運作方式：將整個項目按照迭代的方式（按優(yōu)先級分解成更小的片段后）執(zhí)行每個階段。
第2章 敏捷宣言與原則
1.定義敏捷宣言與敏捷12原則
（1）敏捷宣言
What：一份對核心開發(fā)價值的刻意精簡的表述初嘹，聚焦于人及汉、溝通、產(chǎn)品屯烦、靈活性坷随。
敏捷軟件開發(fā)宣言
我們一直在實踐中探尋更好的軟件開發(fā)方法，身體力行的同時也幫助他人驻龟。由此我們建立了如下價值觀：
個體和互動?高于 流程和工具
工作的軟件?高于 詳盡的文檔
客戶合作?高于 合同談判
響應變化?高于 遵循計劃
也就是說温眉，盡管右項有其價值，我們更重視左項的價值迅脐。
How：
a.個體和互動高于流程和工具：即以人為本，強調(diào)每位成員和整個團隊的價值豪嗽，精簡流程并使之直接支持產(chǎn)品創(chuàng)造谴蔑，令人們更專注于參與、溝通龟梦、創(chuàng)新隐锭、解決問題；
b.工作的軟件高于詳盡的文檔：首先计贰，根據(jù)完工定義钦睡，只有生產(chǎn)出來能夠投入使用了的產(chǎn)品或模塊才能作為完成標準；另一方面躁倒，應專注于支持產(chǎn)品開發(fā)所必需的文檔荞怒，這些文檔要精簡、易維護秧秉、及時發(fā)現(xiàn)潛在問題褐桌。其中在編寫文檔時，可以用“5Why”方法（至少問五次為什么需要該文檔）進行自查象迎。
c.客戶合作高于合同談判：不像傳統(tǒng)方法中在開始時就與客戶談判全部合同細節(jié)荧嵌，而是在項目進行時讓客戶向伙伴一樣參與進來，時時跟進砾淌、變更啦撮。
d.響應變化高于遵循計劃：不盲從于長期計劃，而是在每個階段關注變更汪厨，快速響應客戶赃春、產(chǎn)品用戶和市場，這種方式也降低了變更的成本和風險 劫乱。
（2）敏捷12原則
2.附加白金原則
抵制形式化
團隊思考與行動
可視化而非書寫
（1）抵制形式化
Why：即使是最敏捷的項目團隊也可能遇到如聘鳞，等到安排好的會議才討論本來可以很快解決的簡單問題薄辅，等過度形式化的情況。
How：經(jīng)常質(zhì)疑形式化和沒必要的華麗展示抠璃；
減少組織層級站楚，盡可能去掉項目團隊的頭銜；
避免美工方面的投資搏嗡；
確定并引導那些可能對負責工作成本的展示有要求的干系人窿春。
（2）團隊思考與行動
What：拋開個體的立場和績效指標，整個團隊有主人翁意識并對目標和承諾的時間負責采盒。
Why：讓團隊整體更富有成效旧乞。
How：結對開發(fā)并經(jīng)常交換伙伴，開發(fā)+開發(fā)or開發(fā)+策劃等磅氨；
用“產(chǎn)品開發(fā)者”頭銜代替不同頭銜尺栖；
只在項目團隊層級匯報項目，反對創(chuàng)建細分團隊的特別管理報告烦租；
以項目績效指標替代個體績效指標延赌。
（3）可視化而非書寫
Why：親手體驗效果>圖形化演示（圖表、草圖叉橱、建模等等）>文字表述挫以，我們和客戶都能更好地結合內(nèi)容和概念。
How：在工作環(huán)境中保證繪圖工具隨手可得窃祝；
使用模型而非文字來溝通概念掐松；
使用圖表、圖形和儀表板匯報項目狀態(tài)粪小。大磺、
3.理解敏捷改變了什么
（1）對項目管理流程的態(tài)度
傳統(tǒng)——方法論者開發(fā)出一套用于所有條件下的通用流程；
敏捷——過多的流程是問題而非解決方案探膊，沒種場合都會有起正確的流程和數(shù)量量没。
（2）對知識員工的態(tài)度
傳統(tǒng)——開發(fā)團隊成員時可任意支配的資源；
敏捷——同樣產(chǎn)品突想、不同成員將創(chuàng)造不一樣的結果殴蹄，那些用技能、天資和創(chuàng)新的個體將使得每個項目有所不同猾担；
（3）業(yè)務團隊和IT團隊的關系
傳統(tǒng)——業(yè)務和IT相分離袭灯；
敏捷——組成同一個項目團隊，擁有同等參與度和目標绑嘹；
（4）對待變更的態(tài)度
傳統(tǒng)——視變更為一種需要避免或最小化的問題稽荧；
敏捷——變更能確保大部分好的想法得到實現(xiàn)。
4.敏捷石蕊測試
（1）我們此刻的所作所為是否能夠?qū)ΡM早的和持續(xù)的交付有價值的軟件提供支持工腋？
（2）我們的流程是否歡迎變更并能夠從變更中獲得好處姨丈？
（3）我們的流程是否能夠引導并支持可工作軟件的交付畅卓？
（4）開發(fā)人員和產(chǎn)品負責人是否每日在一起工作？客戶和業(yè)務干系人是否與項目團隊緊密工作蟋恬？
（5）為促進工作開展翁潘，我們的環(huán)境是否給予開發(fā)團隊所需的支持？
（6）我們面對面的溝通是否比電話和電子郵件溝通更多歼争？
（7）我們是否通過所開發(fā)的可工作軟件數(shù)量來度量進展拜马？
（8）我們是否能夠長期維持這樣的前進步伐？
（9）我們是否支持考慮未來變更的卓越技術和良好設計沐绒？
（10）我們是否最小化了不必要工作量——換言之俩莽，為實現(xiàn)項目目標只做盡可能少的必要的工作？
（11）這個開發(fā)團隊是否是自組織與自管理乔遮？他們是否有邁向成功的自由扮超？
（12）我們是否進行定期的反思并相應的調(diào)整我們的行為？
