專業的Scrum團隊圖書 The Professional Scrum Team

Peter Götz ，Uwe Schirmer ， Kurt Bittner 譯者 李靜

專業的Scrum團隊圖書

買這商品的人也買了...

中文年末書展｜繁簡參展書2書75折 詳見活動內容 »

相關主題

商品描述

本書通過一個關於Scrum團隊的故事介紹團隊成員如何一起面對共同的挑戰，從而交付有價值的產品增量。
在敘述上，本書結合案例研究與相關討論，首先介紹Scrum 團隊遇到的特定挑戰，然後探索應對該挑戰的替代方案。
本書可以幫助讀者將Scrum框架規則應用到日常工作中，優化團隊和個人的表現，
改進他們的工作方式和交付有價值的產品，創造更多的價值。

 本書適合所有在Scrum團隊工作的人閱讀，包括剛接觸這個框架的人與經驗豐富的Scrum實踐者。

作者簡介

李靜，Agilean高級諮詢顧問、HSA幸福研究院認證講師，致力於讓知識工作者更幸福。她曾為多家製造、網絡、教育、金融證券以及保險等產業內的企業組織提供專案管理、流程體現建置、精實敏捷DevOps諮詢教輔服務。

目錄大綱

序
前言
致謝
作者簡介
第1章成為一個高效的Scrum團隊
1.1 產品負責人與開發團隊之間的協作
1.1.1 不要把業務和IT分開
1.1.2 為有價值的產品負責
1.1.3 協助管理產品待辦列表
1.1.4 Sprint範圍不是固定的
1.1.5 產品負責人參與
1.2 創建Scrum團隊的透明度
1.2.1 假設驅動的產品待辦列表
1.2.2 產品待辦列表驅動對話
1.2.3 著眼於大局
1.2.4 產品待辦事項需要創造價值
1.2.5 Sprint待辦列表不僅僅是一個任務板
1.2.6 應該由誰來更新Sprint待辦列表
1.2.7 Sprint待辦列表不應該被隱藏
1.2.8 Sprint待辦列表作為進度報告
1.2.9 工作燃盡圖很少是完美的
1.2.10 防止Sprint待辦列表過時
1.2.11 完成代表著可發布
1.2.12 度量和驗證產品的價值
1.3 總結
第2章常見問題
2.1 缺少基礎知識
2.1.1 Scrum的早期失誤
2.1.2 缺少共同的價值觀
2.1.3 缺少產品願景
2.1.4 缺少跨職能特質
2.1.5 缺少自組織特質
2.2 對Scrum的常見誤解
2.2.1 封閉的Sprint
2.2.2 承諾範圍
2.2.3 會議太多了
2.2.4 Sprint評審會中沒有利益相關者
2.2.5 Scrum不是一種宗教
2.3 可以避免的錯誤
2.3.1 只是名義上的ScrumMaster
2.3.2 太多的產品待辦事項
2.3.3 舔餅乾
2.3.4 找不到的產品負責人
2.3.5 每週開兩次站會
2.4 總結
第3章光有Scrum是不夠的
3.1 戰略：顧全大局
3.1.1 誰在Scrum中解決戰略問題
3.1.2 什麼是湧現的結構
3.1.3 為什麼沒有文檔是個壞主意
3.2 策略：從想法到結果
3.2.1 產品待辦列表的不同抽象層級
3.2.2 如何進行有意義的估算
3.2.3 當我們有看板時，還需要Scrum嗎
3.2.4 如何度量成功
3.3 如何改進跨職能
3.3.1 協作是改進的驅動力
3.3.2 每個人都需要做所有的事情嗎
3.3.3 使用測試先行的方法
3.4 應對不斷的變更
3.4.1 為什麼重構是必選項
3.4.2 在變成大問題之前解決它們
3.4.3 根據原則而不是規則工作
3.5 總結
第4章“可發布”小於“已發布”
4.1 什麼是DevOps
4.1.1 它是一個角色……它是一種工具……它是DevOps
4.1.2 DevOps與工具有何關係
4.1.3 DevOps就夠了嗎
4.2 如何結合Scrum和DevOps
4.2.1 DevOps正在取代Scrum嗎
4.2.2 Scrum允許持續部署嗎
4.2.3 Scrum原則和DevOps文化是相輔相成的
4.2.4 如何使用DevOps改善流動
4.3 總結
第5章解決衝突
5.1 可以由當事人解決的衝突
5.1.1 並非所有的分歧都會導致衝突
5.1.2 誰有最終發言權
5.1.3 衝突應該由當事人來解決
5.2 需要外部乾預的衝突
5.2.1 升級的健康衝突
5.2.2 有些衝突需要暴露出來
5.2.3 忠於Scrum團隊還是你的部門
5.3 需要更強乾預的致命衝突
5.3.1 給Scrum團隊施加壓力
5.3.2 換一支隊伍來保護它
5.4 總結
第6章度量成功
6.1 朝著目標努力
6.1.1 我們需要更快地交付
6.1.2 我們是否在交付價值
6.1.3 什麼是價值
6.1.4 實驗迴路
6.2 改進團隊成果
6.2.1 速率不是績效
6.2.2 如何（不）提升績效
6.2.3 你改進不了你無法度量的東西
6.2.4 監控改進，而不是指標
6.3 總結
第7章Scrum和管理
7.1 Scrum中的管理角色
7.1.1 透明不是監視
7.1.2 負責不是控制
7.2 如何實現自組織
7.2.1 領導不是指導
7.2.2 自組織並不缺乏管理
7.2.3 自組織並不容易
7.3 總結
第8章敏捷組織
8.1 組織架構既可能幫助Scrum也可能阻礙Scrum
8.1.1 新工作，舊環境
8.1.2 職能型組織可能阻礙團隊發展
8.1.3 職能型組織提供了職業發展路徑，但要付出代價
8.2 複雜的組織需要徹底的簡單
8.2.1 Scrum可以幫助實現徹底的簡單
8.2.2 徹底的簡單需要徹底的透明
8.2.3 用透明取代匯報鍊和治理流程
8.2.4 打破“孤島”，圍繞客戶價值進行調整
8.3 總結
第9章持續改進永遠不會停止
9.1 如何持續改進
9.1.1 失敗：學會的第一步
9.1.2 我們已經改進了我們能改進的一切
9.1.3 ScrumMaster要被淘汰嗎
9.2 回顧是改進的驅動力
9.2.1 強化積極面
9.2.2 專註於一個單一的改進
9.2.3 隨著時間的推移改變組織的文化以提高專註度
9.3 Scrum會實現嗎
9.3.1 我們什麼時候才能實現Scrum
9.3.2 在產品上線後如何使用Scrum
9.3.3 Scrum不需要外部專家的意見
9.4 總結
參考文獻

類似商品

最後瀏覽商品 (11)