(ACP)敏捷項目管理

第1章 爲何須要敏捷程序員

第2章 敏捷和敏捷項目管理定義編程

第3章 敏捷項目管理價值和原則架構

1.咱們的最高目標是,經過儘早持續交付有價值的軟件來知足客戶的需求框架

2.歡迎對需求提出變動,即便在項目開發後期也不例外。敏捷過程要善於利用需求變動,幫助客戶得到競爭優點學習

3.要常常交付可用的軟件,週期從幾周幾個月不等,且越短越好測試

4.項目實施過程當中,業務人員開發人員必須始終通力合做編碼

5.要善於激勵項目人員,給予他們須要的環境和支持,並相信他們可以完成任務spa

6.團隊內部和各個團隊之間,最有效的溝通方法面對面的溝通設計

7.可用的軟件是衡量進度的首要衡量標準blog

8.敏捷過程提倡可持續的開發

9.對技術的精益求精以及對設計的不斷完善將提升敏捷性

10.簡潔,盡最大可能減小沒必要要的工做

11.最佳的架構,需求和設計將出自自組織團隊

12.團隊要按期檢討怎樣作才能更有效

第4章 生命週期選擇

第5章 敏捷實施-建立敏捷環境

僕人式領導

敏捷團隊

第6章 敏捷實施-在敏捷環境中交付

常見敏捷實踐:

1.回顧:讓團隊學習,改進,調整其過程

2.待辦事項列表編制

3.待辦事項列表的細化

4.每日站會:不超過15分鐘,

5.展現/評審:用戶故事,產品負責人,每兩週至少一次,

6.規劃基於迭代的敏捷

7.幫助團隊交付價值的執行實踐:持續集成,在不一樣層面測試,驗收測試驅動開發,測試驅動開發/行爲驅動開發,刺探

8.迭代和增量如何幫助交付工做產品

 

 

 

 

 

 

第7章 敏捷項目管理過程框架

第8章 關於項目敏捷性的組織考慮因素

第9章 敏捷各流派框架介紹

第10章 敏捷術語解析

-------------------------------------------------------第1章-----------------------------------------------------------------

1.Scrum中的迭代計劃會議應該不長於8小時

2.現值(PV)和淨現值(NPV),PV不考慮成本,NPV考慮成本

3.項目章程一樣適用於傳統項目和敏捷項目

4.干係人是任何對項目感興趣的人

5.力場分析法是尋找推進和阻礙變化的因素並給因素分配編號以瞭解兩邊力量和總和

6.史詩故事是一個大型故事,稱爲一種能力

7.測試驅動開發,軟件應該按照如何會被接受的前提而編寫

8.相對規模估計,是估算某件事相比其餘事情須要更多或更少工做量的一種實踐

9.近似估計,利用襯衫尺寸,咖啡杯尺寸或其它尺寸使團隊能和工做量聯繫起來

-------------------------------------------------------第2章-----------------------------------------------------------------

1.線框圖,團隊能夠不寫代碼二迅速建立它們

2.時間盒,只有在規定時間內經過驗收的功能包含在時間盒內

3.持續集成的意思是全部代碼變化要天天提交和測試

4.最小可售功能,一個能增長客戶價值的小單元

5.一個迭代等同於一個衝刺

6.掙值管理在迭代級別被獲取和用於溝通

7.極限編程項目中的角色:教練,客戶,程序員,測試員,跟蹤員

8.價值流程映射法,經過觀察一系列過程並在整個系統中對其跟蹤以便深刻理解和分析每一個過程產出的價值

9.累計流程圖,顯示的是任務的工做流,而不是過程的工做流

10.精益追求最大化未開展的工做

-------------------------------------------------------第3章-----------------------------------------------------------------

1.速度表示團隊在一個迭代週期能夠完成的故事點;循環時間表示一個功能點從開始到完成所花費的時間;燃燒率表示每次迭代的團隊成本;

2.日本的管理術語,持續改善(細微的變化),看板(信號)

3.測試驅動開發:測試,編碼,重構,交付

4.一次探測是在遇到前進方向的問題時用一個小的實驗來決定如何行動

5.可用的軟件是衡量進度的主要指標

6.敏捷任務是全員完成

7.衝刺評審或者回顧會議通常是半天(4小時)

8.持續改善在敏捷宣言中沒有

-------------------------------------------------------第4章-----------------------------------------------------------------

1.每日站會會議的主要目的是讓團隊協調工做和交流問題

2.圍繞被激勵起來的個體來構建項目

3.代表一個常見根源問題的一般被稱爲氣味

4.修剪產品樹是一種用於需求收集的創新遊戲

5.PMO接受敏捷在不一樣項目中的實施方式不一樣

-------------------------------------------------------第5章-----------------------------------------------------------------

1.敏捷宣言創立於2001年

2.極端人物有助於引出正常人物可能丟失的需求

3.要不斷交付可能的軟件,週期從幾周到幾個月不等

4.任務,不必定增長價值可是須要完成

5.滲透式溝通指團隊成員無心中聽到並接受的所處環境中溝通的信息

6.若是一個團隊成員的表現未達到預期,誰應該說出此事:團隊。

7.停車場圖:用來抓住可能重要的但應該之後再關注的偏離主題的信息

8.完成的定義:事先由團隊商定

9.用戶故事-》計劃撲克-》肯定故事點

10.寬帶德爾菲,專家再給出估算以前知道還有其餘估算者

---------------------------------------------------課後做業1---------------------------------------------------------------

1.看板中的精益生產概念是如何減小瓶頸對工做的影響?經過成爲一個及時的調度系統

2.完成一項任務,任務卡放在準備測試目錄下

3.MoSCoW技術:M:必須有;S:應該有;C:可能有;W:此次不會有。(用戶故事進行優先順序排列)

4.敏捷故事地圖 = 項目計劃

5.一個敏捷項目是如何估算的:自上而下

6.敏捷團隊應該避免在項目中同時使用兩種估算方法

7.開發一個用戶故事的理想時間是2-5天

8.一個用戶故事包含:角色+目標+商業價值。

9.基於價值的分析的一個技術是:MoSCoW或Kano

10.價值流程圖:價值增長和非價值增長

11.敏捷嘗試減小WIP

12.解聚將大的用戶故事分解爲小的更易於處理的小的故事。

13.發佈計劃,討論產品願景

14.計劃撲克,出現最高和最低的人時,向團隊成員解釋本身的觀點,達成共識。

15.敏捷團隊應當與客戶商討決定是否須要以及用戶故事完成的時間

16.用戶故事的3個C:卡片,對話,確認

17.敏捷開發的基石是:增量交付。

18.INVEST  I:獨立;N:可協商;V:有價值的;E:可估算的;S:小故事的;T:可測試的額;

19.產品負責人抱怨功能並無提供她想要的最佳體驗:由於終端體驗並不容易測到。

20.價值流程圖:WIDETOM (W-等待,I-庫存,D-缺陷,E-額外流程,T-運輸,O-過分生產,M-動態)

21.優先級的最佳定義:基於價值對產品特徵進行相對排序

22.干係人管理:對工做環境的管理和促進,使全部干係人可積極地參與到項目

23.在滾動計劃中,一次計劃接下來的幾回迭代、

24.財務主管一般會定義:時間和預算。

25.一般計劃撲克的參展點用戶故事是中碼或者均碼。

26.計劃撲克中的每個用戶故事分配的時間是2-3分鐘

27.教練和指導的定義是幫助我的或團隊提升績效

28.集中辦公與滲透溝通:對問題,想法和信息的流動

29.提升團隊激勵的一個方法:提供教練指導

30.用戶故事不是封閉的:沒有清晰的結束點,露營者可導航網頁

31.相對級別/優先級的定義:基於團隊對優先級定義排序的清單

---------------------------------------------------------------------------課後做業2------------------------------------------------------------

1.動態系統開發方法:DSDM

2.衝刺待辦事項:將在衝刺/迭代中開發的產品特徵

3.滲透溝通:水晶

4.ATDD,TDD:討論,提取,開發,示範

5.TDD:1.編寫測試;2.覈對和確認測試;3.編寫產品代碼,接着採用測試;4.重構產品代碼

6.在價值流程圖中,總前置期被認爲是浪費

7.精益軟件開發中的兩種集成類型:概念性的和感知的

8.哪一個敏捷框架總有一個產品發佈:scrum

9.反思提升研討會是水晶方法的基石

10.停車場圖表是個敏捷文檔,用來對用戶故事按主題進行分類和管理

相關文章
相關標籤/搜索