中圖網小程序
一鍵登錄
更方便
本類五星書更多>
-
>
全國計算機等級考試最新真考題庫模擬考場及詳解·二級MSOffice高級應用
-
>
決戰行測5000題(言語理解與表達)
-
>
軟件性能測試.分析與調優實踐之路
-
>
第一行代碼Android
-
>
JAVA持續交付
-
>
EXCEL最強教科書(完全版)(全彩印刷)
-
>
深度學習
離岸交付 分布式團隊協作指南 版權信息
- ISBN：9787115491657
- 條形碼：9787115491657 ; 978-7-115-49165-7
- 裝幀：一般膠版紙
- 冊數：暫無
- 重量：暫無
- 所屬分類：>
離岸交付 分布式團隊協作指南 本書特色
你經歷的項目有沒有虎頭蛇尾的？開始的時候轟轟烈烈，很快就歸于平淡，*后在度日如年中草草收場。有沒有團隊積極性始終無法提高的？任憑你如何吶喊、推動，大家卻踟躕不前。有沒有團隊很努力但客戶卻總是不滿意的？每次交付不是需求有偏差，就是質量有問題。有沒有對與遠程團隊的溝通感到很無奈的？溝通效率很低，有時候根本不知道另一個團隊在做什么，或者發現南轅北轍的時候為時已晚。如果你對以上問題感同身受，并感到束手無策，請務必仔細閱讀本書。本書作者結合自身的經歷和實踐經驗，從交付效率、交付質量、客戶滿意度等項目交付*重要的著眼點，賦能你和團隊，并且有啟發、可參考，能夠引發你對自身工作的思考，快速提升交付水平。本書中提到的技巧不僅能夠讓服務外包的團隊服務好企業級交付，也能順應協助傳統企業利用IT技術創新的潮流，讓團隊之間的協作更加有效，有助于達成團隊的技術目標和業務目標。
離岸交付 分布式團隊協作指南 內容簡介
本書的內容源自作者的實踐經歷和工作積累。在長期的實踐中作者發現，越來越多的離岸交付需要適應敏捷開發的模式。本書結合分布式團隊溝通、協作中的痛點，系統地分析了很多離岸項目虎頭蛇尾的原因，并給出可供參考的解決方案。對于很多公司和組織頭疼的如何讓分布式團隊推行敏捷的離岸交付的問題，本書給出很多成功經驗。此外，本書還系統介紹了建設自組織團隊的一些措施和方法。 涉及離岸交付的軟件組織以及其他各類存在分布式團隊合作的軟件組織都能從本書中得到很多有價值的提示。本書適合開發人員、測試人員、需求管理人員或項目經理等參考閱讀。
離岸交付 分布式團隊協作指南 目錄
目錄
第 1章 分布式團隊的現狀 1
1．1 分布式團隊介紹 1
1．1．1 分布式團隊的快速發展 1
1．1．2 客戶為何如此看重CMMI認證 2
1．1．3 分布式團隊的類型 3
1．1．4 什么樣的團隊可以稱為分布式團隊 5
1．2 服務外包行業的現狀 5
1．3 離岸團隊的組建 7
1．3．1 組建分布式團隊的原則 7
1．3．2 組建分布式團隊 8
1．3．3 建立一個離岸團隊的投入和效益 9
1．3．4 分布式團隊需要注意的問題 10
1．4 軟件外包服務大方向的變化 11
1．4．1 人才戰爭已經打響 11
1．4．2 戰略合作的成果—建立離岸交付中心 12
1．4．3 客戶衡量外包服務的方式在發生變化 12
第 2章 分布式團隊的溝通 13
2．1 管理客戶的期望值 13
2．1．1 了解客戶 14
2．1．2 保障客戶的知情權 17
2．1．3 維護客戶的期望值 19
2．1．4 超越客戶期望值 23
2．1．5 L項目的案例 24
2．1．6 拆屋效應 25
2．1．7 項目的成敗是由客戶的期望值決定的 25
2．2 溝通是分布式團隊*大的挑戰 26
2．2．1 分布式團隊*基本的溝通方式：電子郵件 27
2．2．2 常規意義上的溝通：異步溝通和實時溝通 29
2．2．3 工具的利與弊 32
2．2．4 主動的溝通 32
2．2．5 溝通中的沖突 33
2．2．6 同理心 36
2．2．7 清楚而坦誠的溝通 38
2．2．8 成功的離岸團隊還需要關注的 39
2．3 會議的組織 41
2．3．1 典型的會議 43
2．3．2 離岸團隊的會議技巧 56
2．3．3 小結 57
2．4 常駐代表和短期面對面的訪問 57
2．4．1 常駐代表 58
2．4．2 短期面對面的溝通 61
2．4．3 一次訪問客戶現場之后的復盤 68
2．4．4 小結 70
2．5 虛擬交流工具 71
2．5．1 知識分享類 72
2．5．2 即時溝通類 72
2．5．3 工作協作類 73
2．5．4 流程控制類 74
2．5．5 融合即時溝通和知識分享的工具類 75
2．5．6 小結 77
2．6 溝通失敗的案例 79
2．6．1 麥道飛機DC-10重蹈覆轍發生空難的教訓 79
2．6．2 某大型能源企業的一次集成失敗 81
2．6．3 L項目首次用戶測試失敗 81
2．6．4 小結 81
第3章 分布式團隊的協作 83
3．1 團隊協作初識 83
3．1．1 溝通與協作的關系 84
3．1．2 意見統一是協作的前提 88
3．1．3 協作更強調行動—執行力 92
3．1．4 對協作有益的方法 94
3．1．5 傷害協作的行為 98
3．1．6 帶動客戶 99
3．1．7 協作技巧 104
3．1．8 關鍵的協作點 105
3．1．9 Scrum of Scrums會議 108
3．1．10 團隊內部的協作 112
3．1．11 小結 115
3．2 提升離岸團隊協作的水平 115
3．2．1 使用假設 116
3．2．2 雙向溝通 117
3．2．3 使用業務語言和實例 118
3．2．4 建立離岸團隊的規律性 120
3．2．5 持續提升離岸團隊的協作水平 122
3．2．6 小結 129
3．3 規范化提升分布式團隊協作 130
3．3．1 需求分析的規范化 130
3．3．2 技術的規范化 134
3．3．3 測試的規范化 137
3．3．4 規范化自動化測試 140
3．3．5 小結 141
第4章 可視化的應用 142
4．1 可視化的目的 143
4．1．1 展示項目的狀態 143
4．1．2 消除需求的理解偏差 145
4．1．3 反饋軟件的質量 146
4．1．4 代碼的測試覆蓋率 146
4．1．5 描述復雜的業務流程 147
4．1．6 理解項目全景 148
4．1．7 幫助團隊思考的思維導圖 150
4．2 可視化的方法 150
4．2．1 項目狀態的展示之看板 152
4．2．2 項目狀態的展示之燃盡圖和燃起圖 155
4．2．3 業務流程的展示 165
4．2．4 項目需求的全景展現 168
4．2．5 需求故事的表達 169
4．2．6 思維導圖的使用 171
4．2．7 數據可視化 173
4．3 使用可視化度量我們的工作 173
4．3．1 開發和測試工作的度量 173
4．3．2 對團隊工作度量的建議 174
4．4 團隊協作可視化工具的介紹 174
4．4．1 Mingle的基本介紹 175
4．4．2 Trello的基本介紹 175
4．5 小結 175
第5章 分布式團隊中的浪費 177
5．1 人的因素造成的浪費 177
5．2 團隊協作中的浪費 180
5．2．1 浪費來自哪里 181
5．2．2 浪費解決之道 183
5．2．3 小結 185
5．3 流程中產生的浪費 186
5．3．1 縮短流程 186
5．3．2 簡化復雜的環節 187
5．3．3 加快進度的重要途徑 187
5．3．4 過度設計也是一種常見的浪費 187
5．4 信息處理中的浪費 188
5．4．1 組織結構產生的浪費 188
5．4．2 知識管理中的浪費 189
5．4．3 信息過多造成的浪費 190
5．4．4 解決信息處理造成的浪費 191
5．5 隱性浪費 192
5．5．1 給丈母娘送海參的故事 192
5．5．2 快速試錯消滅浪費 193
5．5．3 識別隱形浪費需要一點點洞察力 193
5．5．4 隱性浪費之不清楚進度 194
5．5．5 技術債和需求債 194
5．5．6 缺少優先級 194
5．5．7 分布式團隊中的隱性浪費 195
5．5．8 隱性浪費帶來的后果 195
5．6 不要把BDD變成團隊中的浪費 196
5．7 小結 197
第6章 自我管理的離岸團隊 199
6．1 傳統文化對團隊的影響 200
6．2 團隊的驅動力 202
6．2．1 驅動源自何處 203
6．2．2 建立扁平化的組織 207
6．2．3 人，才是組織的核心 208
6．2．4 扁平化的團隊需不需要領導力 210
6．2．5 傳統組織如何向自組織轉型 211
6．2．6 扁平化不是萬能的 214
6．3 塑造團隊的專業性 216
6．3．1 團隊的能力建設 216
6．3．2 養成好習慣 217
6．3．3 公司內部的流程標準化對團隊的正面影響 218
6．3．4 成為項目中的重要貢獻者 219
6．3．5 如何對待文檔 219
6．3．6 把簡單的事情做好就是專業 220
6．3．7 團隊要以業務價值為導向 223
6．4 讓信息透明化 223
6．4．1 傳統團隊中信息流動不暢的問題 224
6．4．2 透明化的挑戰 225
6．4．3 高透明度是不可逆轉的趨勢 227
6．4．4 離岸團隊的信息透明化 228
6．5 跳出舒適區 228
6．5．1 找到舒適區 228
6．5．2 為什么要跳出舒適區 229
6．5．3 團隊驅動跳出舒適區 229
6．5．4 自我驅動跳出舒適區 230
6．5．5 企業KPI驅動跳出舒適區 231
6．5．6 小結 231
6．6 項目經理做什么 231
6．6．1 傳統項目經理的特點 233
6．6．2 自我管理團隊的項目經理 234
6．6．3 項目經理之于團隊 235
6．6．4 項目經理之于客戶 237
6．6．5 成功的項目經理之團隊管家 239
6．6．6 成功的項目經理之正確看待領導力 240
6．6．7 成功的項目經理之解決沖突 241
6．6．8 做什么 241
6．6．9 怎么做 243
6．6．10 更多地關注項目風險 246
6．6．11 小結 247
6．7 建立全團隊意識 247
6．7．1 需求的全團隊參與 247
6．7．2 測試的全團隊負責 249
6．7．3 開發實踐 251
6．7．4 系統安全意識 252
6．7．5 小結 253
6．8 反饋是分布式團隊持續改進的推進器 253
6．8．1 我們為什么要重視反饋 253
6．8．2 做好反饋的要點 254
第7章 服務于客戶的離岸團隊 257
7．1 建立與客戶的互信 257
7．1．1 目標 258
7．1．2 建立信任的客戶關系 261
7．1．3 建立和維持客戶關系實例 262
7．1．4 小結 262
7．2 當與客戶意見相左時 263
7．2．1 處理分歧 264
7．2．2 客戶的意見決定交付質量 266
7．3 按人天收費的交付項目 267
7．4 固定金額的交付項目 268
7．4．1 工作量大小和價格的估算 268
7．4．2 固定金額項目的管理 271
7．4．3 商務層面的關切 275
7．4．4 固定金額項目的風險 276
7．4．5 建議、提示和可能的陷阱 276
7．5 與客戶的工作銜接 277
7．5．1 項目啟動 277
7．5．2 項目進行中 280
7．5．3 項目后期 281
7．5．4 其他 282
7．6 幫助客戶敏捷轉型 283
7．6．1 能力建設 283
7．6．2 強化敏捷的優勢，堅定所有參與人的信念 283
7．6．3 建立跨職能團隊/功能團隊 287
7．6．4 小結 287
第8章 分布式團隊的未來 289
8．1 離岸團隊中的人 289
8．1．1 人員變動的應對 289
8．1．2 關注個人績效 291
8．2 分布式團隊仍然面臨的問題 292
8．2．1 很多人說，敏捷項目不能外包 293
8．2．2 團隊的領域知識管理和提升 294
8．2．3 離岸團隊的效能 295
8．2．4 以史為鑒，面向未來 296
8．3 離岸團隊的未來 296
8．3．1 聘請遠程開發團隊的理由 297
8．3．2 國際競爭 298
8．3．3 協助傳統行業數字化創新 299
8．3．4 離岸團隊的敏捷模型 299
8．3．5 與客戶一起創新的實踐 300
8．3．6 小結 301
8．4 離岸團隊要為技術變革做好準備 302
8．5 低成本的離岸交付是一條不歸路 303
8．6 小結 304
后記 305
參考文獻 306
第 1章 分布式團隊的現狀 1
1．1 分布式團隊介紹 1
1．1．1 分布式團隊的快速發展 1
1．1．2 客戶為何如此看重CMMI認證 2
1．1．3 分布式團隊的類型 3
1．1．4 什么樣的團隊可以稱為分布式團隊 5
1．2 服務外包行業的現狀 5
1．3 離岸團隊的組建 7
1．3．1 組建分布式團隊的原則 7
1．3．2 組建分布式團隊 8
1．3．3 建立一個離岸團隊的投入和效益 9
1．3．4 分布式團隊需要注意的問題 10
1．4 軟件外包服務大方向的變化 11
1．4．1 人才戰爭已經打響 11
1．4．2 戰略合作的成果—建立離岸交付中心 12
1．4．3 客戶衡量外包服務的方式在發生變化 12
第 2章 分布式團隊的溝通 13
2．1 管理客戶的期望值 13
2．1．1 了解客戶 14
2．1．2 保障客戶的知情權 17
2．1．3 維護客戶的期望值 19
2．1．4 超越客戶期望值 23
2．1．5 L項目的案例 24
2．1．6 拆屋效應 25
2．1．7 項目的成敗是由客戶的期望值決定的 25
2．2 溝通是分布式團隊*大的挑戰 26
2．2．1 分布式團隊*基本的溝通方式：電子郵件 27
2．2．2 常規意義上的溝通：異步溝通和實時溝通 29
2．2．3 工具的利與弊 32
2．2．4 主動的溝通 32
2．2．5 溝通中的沖突 33
2．2．6 同理心 36
2．2．7 清楚而坦誠的溝通 38
2．2．8 成功的離岸團隊還需要關注的 39
2．3 會議的組織 41
2．3．1 典型的會議 43
2．3．2 離岸團隊的會議技巧 56
2．3．3 小結 57
2．4 常駐代表和短期面對面的訪問 57
2．4．1 常駐代表 58
2．4．2 短期面對面的溝通 61
2．4．3 一次訪問客戶現場之后的復盤 68
2．4．4 小結 70
2．5 虛擬交流工具 71
2．5．1 知識分享類 72
2．5．2 即時溝通類 72
2．5．3 工作協作類 73
2．5．4 流程控制類 74
2．5．5 融合即時溝通和知識分享的工具類 75
2．5．6 小結 77
2．6 溝通失敗的案例 79
2．6．1 麥道飛機DC-10重蹈覆轍發生空難的教訓 79
2．6．2 某大型能源企業的一次集成失敗 81
2．6．3 L項目首次用戶測試失敗 81
2．6．4 小結 81
第3章 分布式團隊的協作 83
3．1 團隊協作初識 83
3．1．1 溝通與協作的關系 84
3．1．2 意見統一是協作的前提 88
3．1．3 協作更強調行動—執行力 92
3．1．4 對協作有益的方法 94
3．1．5 傷害協作的行為 98
3．1．6 帶動客戶 99
3．1．7 協作技巧 104
3．1．8 關鍵的協作點 105
3．1．9 Scrum of Scrums會議 108
3．1．10 團隊內部的協作 112
3．1．11 小結 115
3．2 提升離岸團隊協作的水平 115
3．2．1 使用假設 116
3．2．2 雙向溝通 117
3．2．3 使用業務語言和實例 118
3．2．4 建立離岸團隊的規律性 120
3．2．5 持續提升離岸團隊的協作水平 122
3．2．6 小結 129
3．3 規范化提升分布式團隊協作 130
3．3．1 需求分析的規范化 130
3．3．2 技術的規范化 134
3．3．3 測試的規范化 137
3．3．4 規范化自動化測試 140
3．3．5 小結 141
第4章 可視化的應用 142
4．1 可視化的目的 143
4．1．1 展示項目的狀態 143
4．1．2 消除需求的理解偏差 145
4．1．3 反饋軟件的質量 146
4．1．4 代碼的測試覆蓋率 146
4．1．5 描述復雜的業務流程 147
4．1．6 理解項目全景 148
4．1．7 幫助團隊思考的思維導圖 150
4．2 可視化的方法 150
4．2．1 項目狀態的展示之看板 152
4．2．2 項目狀態的展示之燃盡圖和燃起圖 155
4．2．3 業務流程的展示 165
4．2．4 項目需求的全景展現 168
4．2．5 需求故事的表達 169
4．2．6 思維導圖的使用 171
4．2．7 數據可視化 173
4．3 使用可視化度量我們的工作 173
4．3．1 開發和測試工作的度量 173
4．3．2 對團隊工作度量的建議 174
4．4 團隊協作可視化工具的介紹 174
4．4．1 Mingle的基本介紹 175
4．4．2 Trello的基本介紹 175
4．5 小結 175
第5章 分布式團隊中的浪費 177
5．1 人的因素造成的浪費 177
5．2 團隊協作中的浪費 180
5．2．1 浪費來自哪里 181
5．2．2 浪費解決之道 183
5．2．3 小結 185
5．3 流程中產生的浪費 186
5．3．1 縮短流程 186
5．3．2 簡化復雜的環節 187
5．3．3 加快進度的重要途徑 187
5．3．4 過度設計也是一種常見的浪費 187
5．4 信息處理中的浪費 188
5．4．1 組織結構產生的浪費 188
5．4．2 知識管理中的浪費 189
5．4．3 信息過多造成的浪費 190
5．4．4 解決信息處理造成的浪費 191
5．5 隱性浪費 192
5．5．1 給丈母娘送海參的故事 192
5．5．2 快速試錯消滅浪費 193
5．5．3 識別隱形浪費需要一點點洞察力 193
5．5．4 隱性浪費之不清楚進度 194
5．5．5 技術債和需求債 194
5．5．6 缺少優先級 194
5．5．7 分布式團隊中的隱性浪費 195
5．5．8 隱性浪費帶來的后果 195
5．6 不要把BDD變成團隊中的浪費 196
5．7 小結 197
第6章 自我管理的離岸團隊 199
6．1 傳統文化對團隊的影響 200
6．2 團隊的驅動力 202
6．2．1 驅動源自何處 203
6．2．2 建立扁平化的組織 207
6．2．3 人，才是組織的核心 208
6．2．4 扁平化的團隊需不需要領導力 210
6．2．5 傳統組織如何向自組織轉型 211
6．2．6 扁平化不是萬能的 214
6．3 塑造團隊的專業性 216
6．3．1 團隊的能力建設 216
6．3．2 養成好習慣 217
6．3．3 公司內部的流程標準化對團隊的正面影響 218
6．3．4 成為項目中的重要貢獻者 219
6．3．5 如何對待文檔 219
6．3．6 把簡單的事情做好就是專業 220
6．3．7 團隊要以業務價值為導向 223
6．4 讓信息透明化 223
6．4．1 傳統團隊中信息流動不暢的問題 224
6．4．2 透明化的挑戰 225
6．4．3 高透明度是不可逆轉的趨勢 227
6．4．4 離岸團隊的信息透明化 228
6．5 跳出舒適區 228
6．5．1 找到舒適區 228
6．5．2 為什么要跳出舒適區 229
6．5．3 團隊驅動跳出舒適區 229
6．5．4 自我驅動跳出舒適區 230
6．5．5 企業KPI驅動跳出舒適區 231
6．5．6 小結 231
6．6 項目經理做什么 231
6．6．1 傳統項目經理的特點 233
6．6．2 自我管理團隊的項目經理 234
6．6．3 項目經理之于團隊 235
6．6．4 項目經理之于客戶 237
6．6．5 成功的項目經理之團隊管家 239
6．6．6 成功的項目經理之正確看待領導力 240
6．6．7 成功的項目經理之解決沖突 241
6．6．8 做什么 241
6．6．9 怎么做 243
6．6．10 更多地關注項目風險 246
6．6．11 小結 247
6．7 建立全團隊意識 247
6．7．1 需求的全團隊參與 247
6．7．2 測試的全團隊負責 249
6．7．3 開發實踐 251
6．7．4 系統安全意識 252
6．7．5 小結 253
6．8 反饋是分布式團隊持續改進的推進器 253
6．8．1 我們為什么要重視反饋 253
6．8．2 做好反饋的要點 254
第7章 服務于客戶的離岸團隊 257
7．1 建立與客戶的互信 257
7．1．1 目標 258
7．1．2 建立信任的客戶關系 261
7．1．3 建立和維持客戶關系實例 262
7．1．4 小結 262
7．2 當與客戶意見相左時 263
7．2．1 處理分歧 264
7．2．2 客戶的意見決定交付質量 266
7．3 按人天收費的交付項目 267
7．4 固定金額的交付項目 268
7．4．1 工作量大小和價格的估算 268
7．4．2 固定金額項目的管理 271
7．4．3 商務層面的關切 275
7．4．4 固定金額項目的風險 276
7．4．5 建議、提示和可能的陷阱 276
7．5 與客戶的工作銜接 277
7．5．1 項目啟動 277
7．5．2 項目進行中 280
7．5．3 項目后期 281
7．5．4 其他 282
7．6 幫助客戶敏捷轉型 283
7．6．1 能力建設 283
7．6．2 強化敏捷的優勢，堅定所有參與人的信念 283
7．6．3 建立跨職能團隊/功能團隊 287
7．6．4 小結 287
第8章 分布式團隊的未來 289
8．1 離岸團隊中的人 289
8．1．1 人員變動的應對 289
8．1．2 關注個人績效 291
8．2 分布式團隊仍然面臨的問題 292
8．2．1 很多人說，敏捷項目不能外包 293
8．2．2 團隊的領域知識管理和提升 294
8．2．3 離岸團隊的效能 295
8．2．4 以史為鑒，面向未來 296
8．3 離岸團隊的未來 296
8．3．1 聘請遠程開發團隊的理由 297
8．3．2 國際競爭 298
8．3．3 協助傳統行業數字化創新 299
8．3．4 離岸團隊的敏捷模型 299
8．3．5 與客戶一起創新的實踐 300
8．3．6 小結 301
8．4 離岸團隊要為技術變革做好準備 302
8．5 低成本的離岸交付是一條不歸路 303
8．6 小結 304
后記 305
參考文獻 306
展開全部
離岸交付 分布式團隊協作指南 作者簡介
曲正平，現就職于滴滴出行公司，從事質量管理工作，日常需要協調多個團隊進行質量改進。在此之前就職于ThoughtWorks，參與和主導過大量的項目測試和交付工作，客戶遍布美國、澳大利亞、英國及國內許多地方。對建立分布式團隊的溝通計劃、分布式敏捷協作、質量保證流程以及敏捷實踐有非常深刻的理解。除了項目交付，還曾為多家傳統企業提供敏捷實踐方面的咨詢服務。
書友推薦
- >
伊索寓言-世界文學名著典藏-全譯本
- >
朝聞道
- >
中國歷史的瞬間
- >
大紅狗在馬戲團-大紅狗克里弗-助人
- >
人文閱讀與收藏·良友文學叢書:一天的工作
- >
龍榆生：詞曲概論/大家小書
- >
詩經-先民的歌唱
- >
上帝之肋:男人的真實旅程
本類暢銷
