幫助中心 | 我的帳號 | 關於我們
進階搜尋
car

同類熱銷排行榜

最近瀏覽的商品

突破敏捷困境(來自敏捷實踐的144個提示)

  • 作者：(日)渡會健|責編:劉淑麗|譯者:(日)高橋辰生//羅晨
  • 出版社：電子工業
  • ISBN：9787121513855
  • 出版日期：2025/11/01
  • 裝幀：平裝
  • 頁數：219
人民幣：RMB 69 元      售價：元
放入購物車
加入收藏夾
內容大鋼
    本書由日本敏捷管理領軍人物渡會 健先生，基於15年的敏捷實踐經驗撰寫，聚焦敏捷開發痛點，提煉來自敏捷實踐的144個提示，內容涵蓋敏捷基礎、團隊溝通、角色分工、成果交付、實踐方法到高階實踐，從基礎操作到跨團隊協作等難題的針對性解法，幫助敏捷從業者快速突破敏捷困境，引導敏捷項目走向成功。
    本書分為5章，是全面且實用的敏捷開髮指南，為敏捷項目管理賦能，適合敏捷開發的初學者、從業者及管理者閱讀和借鑒。
    第1章 你真的了解敏捷嗎
    介紹敏捷開發的基本概念、敏捷宣言及其背後的思考方式，糾正對敏捷的常見誤解。
    第2章 團隊溝通和角色分工
    探討如何提升團隊溝通效率，明確敏捷團隊中各角色（如產品負責人、開發團隊、Scrum Master等）的職責。
    第3章 敏捷團隊的成果
    講解如何創建和管理用戶故事清單、待辦事項清單，以及如何確保可交付成果的質量。
    第4章 敏捷的實施方法
    介紹敏捷開發的具體實施方法，包括迭代計劃、每日站會、任務看板、燃盡圖等工具的使用。
    第5章 高級篇：如何使敏捷更加完善
    探討多個團隊協作、DevOps實踐、敏捷合同等高級主題，以及如何借助外部專家力量提升敏捷實踐。
作者介紹
(日)渡會健|責編:劉淑麗|譯者:(日)高橋辰生//羅晨
目錄
10分鐘速讀敏捷的概述
敏捷背後的思考方式——敏捷宣言
專欄  敏捷不僅僅是Scrum
第1章  你真的了解敏捷嗎
  提示001  你真的需要「敏捷」嗎
  提示002  當「敏捷」成為最大的目標時，敏捷就會失敗
  提示003  在歐美，「敏捷是主流」並不是事實
  提示004  「敏捷開發方法源於歐美，不適合亞洲文化」是錯誤的說法
  提示005  不要害怕敏捷開發方法，已有許多成功案例可供參考
  提示006  敏捷開發方法不是萬能的（「換一種管理方法就能成功」 是不切實際的）
  提示007  靈活應變≠敏捷開發方法
  提示008  開始使用敏捷開發方法時，需要的不是標準而是指南
  提示009  接受變更≠工作量無限增加，這是需要達成共識的事情
  提示010  以瀑布式方法引入敏捷的悲劇
  提示011  不要隨意混合瀑布式和敏捷，混合管理很困難，原因何在
  提示012  讓自己從「一旦決定就很難改變」的束縛中解脫出來
  提示013  在大多數情況下，必須接受從第一個迭代開始成果無法按計劃達成的事實，否則很容易一開始就失敗
  提示014  在敏捷管理中，「允許失敗」是有很多「學問」的
  提示015  完全交由乙方的敏捷，註定會失敗
  提示016  被動參與的敏捷和被迫參與的敏捷
  提示017  不了解敏捷宣言的後果有哪些
  提示018  對於敏捷，你也許會認為即使沒有開發經驗也可以成功，這很奇怪
  提示019  對於不熟悉敏捷的人來說，和有經驗的人一起工作是最快的捷徑
  提示020  將敏捷應用於確定性高的項目而導致的失敗
第2章  團隊溝通和角色分工
  2-1  如何使團隊溝通更為順暢
    提示021  溝通是語言的接力，而不是理論的碰撞
    提示022  當團隊內部的溝通停滯時，從「我覺得你說得對」這樣的 認同開始
    提示023  有意識地創造閑聊時間
    提示024  「有意識地查看」與「無意識地輸入」信息共享的巨大差異
    提示025  在真正意義上，將看不見的「信息」替換為可見的「東西」
    提示026  會議主持人不應固定由Scrum Master擔任
    提示027  團隊規則（工作協議）的細化和遵守
    提示028  讓第三方公司打成一片
    提示029  對客戶保持信息公開，沒有任何隱瞞
    提示030  導入課題管理系統
    提示031  開發團隊內不創建次級團隊的真正原因
    提示032  促進可持續性開發，並不意味著不允許加班
    提示033  學會活用會議的節奏
    提示034  如何在遠程辦公中也能實現「在一起工作」
  2-2  敏捷團隊中各自的角色
    2-2-1  產品負責人
    提示035  產品負責人真的只能有一個嗎？團隊制也是一個選擇
    提示036  產品負責人不是「客戶」，而是一起工作的同伴
    2-2-2  開發團隊
    提示037  起用代理產品負責人，關鍵是要讓他能完全代入產品負責人的角色來進行決策
    提示038  敏捷開發團隊有很多事情要做
    提示039  開發團隊不必一開始就是多面手，他們會隨著團隊的成熟而逐漸成長
    提示040  開發團隊人數限制的陷阱
    2-2-3  Scrum Master

    提示041  Scrum Master不應該是敏捷團隊的主角
    提示042  Scrum Master的真正職責是塑造一個即便沒有他也能持續成長的團隊
    提示043  為什麼讓Scrum Master同時兼任產品負責人是不好的
    提示044  Scrum Master應該由產品負責人公司還是開發團隊公司的人來擔任
    提示045  以現有的角色直接代入敏捷團隊是不可取的
    2-2-4  傳統開發中項目經理的角色應該由誰來扮演
    提示046  為什麼要在敏捷方法中將項目經理的角色進行分割
第3章  敏捷團隊的成果
  3-1  創建項目核心的用戶故事清單
    提示047  需求定義書與用戶故事清單的決定性差別
    提示048  不是優先順序，而是優先順序
    提示049  調整用戶故事顆粒度的精髓
    提示050  用戶故事中必須寫的和不能寫的內容
    提示051  用戶故事和INVEST的陷阱
    提示052  從MECE（相互獨立，完全窮盡）的束縛中擺脫出來
    提示053  怎樣對用戶故事進行拆分
    提示054  用橫向切分的思維得出每個迭代的可交付成果
    提示055  如果在迭代中沒能按計劃完成用戶故事應該怎麼辦
  3-2  待辦事項清單要以迭代為單位進行創建和廢棄
    提示056  待辦事項清單與WBS的區別
    提示057  怎麼讓產品負責人參與待辦事項清單的創建
    提示058  待辦事項清單中需要寫哪些任務
    提示059  進度管理和適當的任務顆粒度
    提示060  怎麼處理突發任務
  3-3  可交付成果與其質量
    提示061  始終保持只有一個最新的「可交付成果」
    提示062  確保產品質量
    提示063  在敏捷中如何實現「共通化」
    提示064  只要出現Bug就立刻將其修復是否真的有價值
    提示065  傳統開發和敏捷開發是如何確保質量的
    提示066  如何縮小理想化的測試驅動開發與團隊能力之間的差距
  3-4  讓估算成為計劃的參照
    提示067  估算在敏捷開發方法中的作用
    提示068  由誰進行估算，這很重要
    提示069  估算需要開發團隊全員一起來做的理由
    提示070  估算的基準是「過去的我們」
    提示071  在敏捷中為什麼廣泛使用計劃撲克
第4章  敏捷的實施方法
  4-1  通過溝通和時間管理來促進團隊運作
    提示072  為什麼越是生產效率高的團隊，越會花時間進行溝通
    提示073  如何確定最適合自己團隊的迭代周期
    提示074  並不是說因為是敏捷所以不按時完成也沒關係。如果不進行反省和改進，那就只是單純的拖延
    提示075  迭代計劃與日曆之間的關聯
  4-2  迭代開始前需要做的事情
    提示076  不做「迭代0」的敏捷在起步時就會遭遇困難
    提示077  項目啟動藍圖不是成果，而是讓團隊成員之間達成共識的工具
    提示078  項目啟動藍圖類似於項目計劃書，但並不完全相等，並不是越詳盡越好
    提示079  項目啟動藍圖不能做完后就擱置不管
  4-3  對於敏捷來說，計劃也很重要
    提示080  迭代計劃會議的規劃

    提示081  做迭代計劃，等於在做群體設計
    提示082  要記住在敏捷中，設計的時機和實施與傳統方法有著根本的不同
    提示083  不要把迭代計劃會議分段執行
    提示084  為什麼與其他團隊比較Velocity數字是沒有意義的
    提示085  價值實現效率大於開發效率
    提示086  迭代計劃並不是敏捷中唯一的計劃，全體計劃也很重要
    提示087  對「如果不發生變化的話，會產生怎樣的效果」進行持續展示的重要性
  4-4  通過每日站會來找出變化
    提示088  如果團隊成員開始說「進度比計劃的要慢」，那就是一種危險的信號
    提示089  任務不應該靠「推」，而要去「拿」
    提示090  「一直沒有異常」本身就是一種異常 ，其原因是缺乏心理上的安全感
    提示091  每日站會中的三個問題的利與弊
    提示092  為了在每日站會中不錯過變化，需要做什麼
    提示093  在迭代實施過程中，任務的增加真的是不可接受的嗎
  4-5  熟練應用任務看板
    提示094  要注意任務看板上的優先順序
    提示095  迭代結束時如果任務看板總是呈現相同的狀態的話，則是一種異常
    提示096  在任務看板上，應該只在進行中的任務上註明其責任人
    提示097  看得到進行中的任務狀態的話，就能看到成員間的工作分佈不均
  4-6  燃盡圖的具體改進方法
    提示098  舉例說明可以通過燃盡圖發現的異常
    提示099  燃盡圖不僅僅是用來觀察進度的
    提示100  燃盡圖的利與弊，以及如何活用燃起圖
    提示101  燃盡圖的縱軸應該是任務數量還是估算點數
    提示102  可以從微笑日曆中獲得的信息
  4-7  關注任務的執行，以求能夠確實地實現可交付成果
    提示103  10分鐘規則（有不明白的事，立刻向知道的人詢問，要打造這樣的文化）
    提示104  在敏捷開發中如果不進行重構會怎麼樣
    提示105  開發團隊的效率提升取決於產品負責人是否能當機立斷（即使決策錯誤，也可以在下一個迭代中修正）
    提示106  不給成員選擇的餘地，強行推動配對工作或群體工作是危險的
    提示107  只是導入敏捷工具、實踐或活動的話，並不能實現真正的敏捷
    提示108  配置管理是敏捷的基礎
  4-8  怎樣的成果反饋能讓可交付成果變得更好
    提示109  成果反饋不是進度會議（只展示已經通過測試的內容）
    提示110  當成果反饋變成由產品負責人或利益相關者進行的審查會時，該如何突圍
    提示111  成果反饋不是用來進行公開測試的，獲得反饋才是真正的目的
    提示112  在成果反饋中進行追責只能換來沉默的結果，試著傳達一下感激之情吧
    提示113  讓產品負責人來擔任成果反饋主持人的意義
    提示114  要讓全體成員都參加成果反饋
  4-9  通過回顧促進團隊成長
    提示115  如果停止進行回顧的話，那麼團隊的成長也會一併停止
    提示116  在微弱的聲音中往往隱藏著對團隊有幫助的意見
    提示117  在回顧中要注意Try的欠債。在下一個迭代中確實能執行的，才算完成
    提示118  一開始從個人層面出發即可，隨著對回顧的熟練，再逐漸 過渡到團隊層面
    提示119  通過KPT確保心理上的安全感
    提示120  為什麼KPT模板在回顧中如此流行    提示124  如何熟練使用探針
    提示125  精煉的結果不能只體現在團隊內部，不能每次都與利益相關方分享的話就是失敗的
第5章  高級篇  如何使敏捷更加完善
  5-1  多個團隊共同創建一個產品
    提示126  在團隊劃分上的反面教材
    提示127  成果反饋和回顧應該共同進行
    提示128  專家應該與開發團隊一起參加活動
    提示129  小型產品的開發可以考慮組建聯合團隊
  5-2  開發和運維都讓同一團隊負責
    提示130  為了實現產品管理目的而進行的DevOps
    提示131  如何保持開發和運維的平衡
    提示132  為傳統的運維團隊導入敏捷，以實現工作方式改革
  5-3  敏捷與合同
    提示133  為什麼敏捷合同基本上採用准委任的方式
    提示134  學會利用個別合同實現敏捷
    提示135  如果甲方和乙方的關係是對等的話，就不會被視為虛假承包
  5-4  敏捷的理想與現實的解決方案
    提示136  發布迭代的利與弊
    提示137  Velocity數字應該保持穩定還是繼續增加
    提示138  敏捷中的KPI是Scrum Master能夠體現價值的地方
    提示139  應該專註于什麼才能高效地推進（資源效率與流程效率）
    提示140  守破離的誤用。為了不讓打破常規變成不倫不類，我們應該怎麼做
  5-5  借助外部專家的力量
    提示141  敏捷教練能為我們做什麼
    提示142  引入和利用A-CoE
    提示143  敏捷啟動指南的思路
    提示144  如何巧妙地利用敏捷培訓
寫在最後

  • 商品搜索：
  • | 高級搜索
首頁│ 新手上路│ 客服中心│ 關於我們│ 聯絡我們│ 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