幫助中心 | 我的帳號 | 關於我們

專業的Scrum團隊/敏捷開發技術叢書

  • 作者:(德)彼得·格茨//烏維·M.席爾默//庫爾特·比特納|責編:劉鋒//馮潤峰|譯者:李靜
  • 出版社:機械工業
  • ISBN:9787111721598
  • 出版日期:2023/03/01
  • 裝幀:平裝
  • 頁數:202
人民幣:RMB 79 元      售價:
放入購物車
加入收藏夾

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

作者介紹
(德)彼得·格茨//烏維·M.席爾默//庫爾特·比特納|責編:劉鋒//馮潤峰|譯者:李靜

目錄

前言
致謝
作者簡介
第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  總結
參考文獻

  • 商品搜索:
  • | 高級搜索
首頁新手上路客服中心關於我們聯絡我們Top↑
Copyrightc 1999~2008 美商天龍國際圖書股份有限公司 臺灣分公司. All rights reserved.
營業地址:臺北市中正區重慶南路一段103號1F 105號1F-2F
讀者服務部電話:02-2381-2033 02-2381-1863 時間:週一-週五 10:00-17:00
 服務信箱:bookuu@69book.com 客戶、意見信箱:cs@69book.com
ICP證:浙B2-20060032