關(guān)注公眾號【互聯(lián)互通社區(qū)】,回復【敏捷軟件項目管理與開發(fā)】獲取全部內(nèi)容
《Scrum實戰(zhàn)——敏捷軟件項目管理與開發(fā)》為軟件項目團隊提供了如何成功實施敏捷軟件框架Scrum的實用指南。本書敘事清晰準確,是*本由實踐者編寫的針對現(xiàn)實狀況的實用指南。書中描述了如何使項目團隊價值*化,彌補了許多Scrum和項目管理書籍缺少的部分,包括如何使用財務術(shù)語與高層管理人員交流、如何使用客觀的評估技術(shù)、軟件架構(gòu)如何適應Scrum等。附錄提供了案例研究,描述了如何利用本書提到的技術(shù)和建議來成功地構(gòu)建和部署兩個軟件產(chǎn)品。主要內(nèi)容
◆ 與業(yè)務管理層良好協(xié)作所需的基本財務知識。
◆ 如何獲得中層管理者的支持。
◆ 如何可視化地為Scrum項目收集需求。
◆ 如何利用架構(gòu)愿景緩解團隊速率的波動。
◆ 如何為企業(yè)級的Scrum部署客觀地評估故事點數(shù)。
◆ 自動化、回歸、集成測試的重要性。
◆ Scrum環(huán)境中的團隊領導。
Scrum實戰(zhàn)讀書筆記
因為最近在學習項目經(jīng)理相關(guān)的知識。Scrum實戰(zhàn)讀完了第7章。前面4章其實感覺都沒有太大,只是作為一個學習書籍在看待。
從第5章開始,感覺這本書寫的太好了,上面描述的問題已經(jīng)遇到好多次了,這里算是找到原因了。
Scrum的三大角色:ScrumMaster、產(chǎn)品負責人、團隊成員 目前我們遇到的困境就是因為ScrumMaster、產(chǎn)品負責人都是由項目經(jīng)理兼任的,而且項目經(jīng)理還會遇到來著領導的壓力,所以對團隊成員的保護是沒有的,人人都是被壓榨的精疲力盡。
DoD:定義完成,這個也是我們目前遇到的問題之一。一個需求過來,3個字的需求不知道大伙見過沒有。3句話的需求是我們公司常見的事情。開發(fā)提交的代碼是根本無法集成的,或者集成了各種問題的。測試往往在沒有時間的時候只做了一個冒煙測試,時間來得及才能做功能測試。定義了DoD就好辦很多,需要要做需求澄清,開發(fā)要寫單元測試。測試要白盒測試和黑盒設置都做完,性能測試在每個發(fā)布之前都要檢查。
頭腦風暴:用戶故事的來源,不是項目經(jīng)理說的算,也不是系統(tǒng)分析師的活,更不是某個開發(fā)拍腦袋想出來的。用戶故事必須每個團隊成員達成共識。
第1章 敏捷和Scrum的基礎知識 1
1.1 敏捷軟件開發(fā)和項目管理的基礎是什么 2
1.2 Scrum起源 3
1.3 敏捷和Scrum為什么在軟件項目管理中有效 7
1.4 小結(jié) 9
第2章 關(guān)于財務 11
2.1 計算項目成本 11
2.2 選擇項目投資 12
2.2.1 投資回收期 12
2.2.2 購買與構(gòu)建 12
2.2.3 凈現(xiàn)值(NPV) 13
2.2.4 投資回報率(ROI) 14
2.3 監(jiān)控項目績效 15
2.3.1 成本績效 15
2.3.2 進度績效 16
2.3.3 項目預算預測 17
2.4 小結(jié) 18
第3章 如何與各層管理者溝通 19
3.1 與企業(yè)高層管理者溝通 20
3.2 與IT管理高層合作 22
3.3 與IT中層管理者一起工作 23
3.3.1 質(zhì)量保證 24
3.3.2 運維管理 24
3.3.3 企業(yè)架構(gòu) 24
3.4 把直接管理者變成盟友 28
3.5 小結(jié) 28
第4章 針對產(chǎn)品積壓工作的直觀的需求收集方法 29
4.1 一種新的針對敏捷和Scrum的直觀的需求收集過程 29
4.1.1 第一步:識別利益相關(guān)者和他們的目標 29
4.1.2 SMART原則 30
4.1.3 第二步:為產(chǎn)品積壓工作收集需求 31
4.1.4 CUTFIT原則 33
4.2 示例 33
4.3 小結(jié) 37
第5章 讓故事點評估具有可比性 39
5.1 非可比性故事點存在的問題 39
5.2 規(guī)劃撲克的文化問題 40
5.3 一種基于客觀標準的評估過程 40
5.4 小結(jié) 46
第6章 架構(gòu)愿景對團隊生產(chǎn)率和軟件質(zhì)量的影響 47
6.1 架構(gòu)愿景的重要性 48
6.2 如何識別架構(gòu)愿景 52
6.3 架構(gòu)愿景的另一優(yōu)點 54
6.4 小結(jié) 58
第7章 從架構(gòu)愿景到發(fā)布和沖刺規(guī)劃再到并行軟件開發(fā) 61
7.1 從架構(gòu)愿景到發(fā)布和沖刺規(guī)劃 61
7.2 從增量開發(fā)到并行軟件開發(fā) 66
7.3 小結(jié) 68
第8章 關(guān)于產(chǎn)品負責人 69
8.1 管理利益相關(guān)者的期望和優(yōu)先級 70
8.2 具備清晰的產(chǎn)品愿景和知識 70
8.3 知道如何為產(chǎn)品積壓工作收集需求 71
8.4 始終與團隊同在 71
8.5 知道如何成為出色的組織者 72
8.6 知道如何更好地溝通 72
8.7 知道如何成為服務型領導 72
8.8 小結(jié) 72
第9章 自動化測試和持續(xù)集成測試的重要性 73
9.1 “完成”的定義的重要性 74
9.2 最重要的測試 76
9.2.1 自動化測試 76
9.2.2 持續(xù)集成測試 76
9.3 組織測試基礎設施 77
9.4 小結(jié) 78
第10章 團隊合作的重要性 79
10.1 個人 79
10.2 小組 80
10.3 團隊 81
10.4 Keirsey的氣質(zhì)類型理論 81
10.5 團隊的5個階段 82
10.6 解決團隊沖突的方法 83
10.7 良好團隊合作的條件 83
10.8 小結(jié) 84
第11章 Scrum項目中管理和領導的新特質(zhì) 87
11.1 高績效訓練:GROW模型 90
11.2 關(guān)懷型領導者和管理者的特質(zhì) 91
11.3 小結(jié) 92
第12章 如何使Scrum適應環(huán)境 93
12.1 如何在不借口采取消極ScrumBut的前提下使Scrum適應環(huán)境 94
12.2 Scrum適應環(huán)境的一些例子 94
12.2.1 組織維度 94
12.2.2 基礎設施維度 96
12.2.3 團隊維度 97
12.2.4 技術(shù)維度 97
12.2.5 過程維度 97
12.2.6 業(yè)務維度 98
12.3 小結(jié) 99
第13章 Scrum項目準備程度的自我評估 101
13.1 評估Scrum準備程度的簡單工具 101
13.2 示例 106
13.3 組合在一起 109
13.4 小結(jié) 110
第14章 何時需要ScrumMaster 111
14.1 對Scrum的深厚理論和實踐知識 112
14.2 優(yōu)秀的服務型領導技能 112
14.3 強大的組織能力 112
14.4 出色的溝通能力 112
14.5 優(yōu)秀的演講技能 113
14.6 沖突解決能力 113
14.7 出色的人力開發(fā)能力 113
14.8 小結(jié) 113
第15章 臨別贈言 115
附錄A 兩個真實的軟件產(chǎn)品開發(fā)案例 117
附錄B 關(guān)于提前終止沖刺 175
關(guān)注公眾號【互聯(lián)互通社區(qū)】,回復【敏捷軟件項目管理與開發(fā)】獲取全部內(nèi)容