硝烟中的Scrum和XP

硝烟中的Scrum和XP pdf epub mobi txt 电子书 下载 2026

出版者:infoQ
作者:Henrik Kniberg
出品人:
页数:133
译者:李剑
出版时间:2008
价格:0
装帧:
isbn号码:9789781430329
丛书系列:
图书标签:
  • Scrum
  • 项目管理
  • 敏捷开发
  • 敏捷
  • 软件工程
  • XP
  • 管理
  • 软件开发
  • Scrum
  • XP
  • 软件开发
  • 敏捷开发
  • 项目管理
  • 编程实践
  • 团队协作
  • 技术创新
  • 持续交付
  • 开发流程
想要找书就要到 图书目录大全
立刻按 ctrl+D收藏本页
你会得到大惊喜!!

具体描述

在本书中,作者Henrik Kniberg讲述了他在一年的时间里,带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸(3~12人)、sprint长度(2~6星期),定义“完成”的不同方式,不同的backlog格式,各种测试策略,在多个Scrum团队之间进行同步的多种方式。他们还尝试过XP实践——持续集成、结对编程、测试驱动开发等等,还试过了把XP跟Scrum组合。

本书描述的是一个成功敏捷团队的工作过程,没有理论、没有引用、没有脚注、没有废话。读者可以把它当作一些基础实践的入门指南,帮助团队进行正确实施——但不能模仿,你需要了解自己所处的环境,进而对具体实践做出取舍,创造出属于自己的过程。

作者简介

Henrik Kniberg(henrik.kniberg@crisp.se)是一名咨询师,在斯德哥尔摩的Crisp公司(www.crisp.se)工作。他的专长是Java和敏捷软 件开发。

自从第一本有关XP的书籍和敏捷宣言问世以来,Henrik就开始拥抱敏捷原则,并尝试在不同的组织中进行有效应用。在1998年至2003年间,他作为Goyada的合作创始人和CTO,构建并管理一个技术平台和30人的开发团队,充分试验了测试驱动开发及其它敏捷实践。这个网站上有他的更多信息:http://www.crisp.se/henrik.kniberg

目录信息

第1章 简介
免责声明
撰写本书的原因
Scrum到底是什么
第2章 我们怎样编写产品backlog
额外的故事字段
我们如何让产品backlog停留在业务层次上
第3章 我们怎样准备sprint计划
第4章 我们怎样制定sprint计划
为什么产品负责人必须参加
为什么不能在质量上让步
无休止的sprint计划会议
sprint计划会议日程
确定sprint长度
确定sprint目标
决定sprint要包含的故事
产品负责人如何对sprint放哪些故事产生影响
团队怎样决定把哪些故事放到sprint里面
用本能反应来估算
用生产率计算来估算
我们用的是哪种估算技术
我们为何使用索引卡
定义“完成”
使用计划扑克做时间估算
明确故事内容
把故事拆分成更小的故事
把故事拆分成任务
定下每日例会的时间地点
最后界限在哪里
技术故事
bug跟踪系统VS.产品backlog
sprint计划会议终于结束了
第5章 我们怎样让别人了解我们的sprint
第6章 我们怎样编写sprint backlog
Sprint backlog的形式
任务板怎样发挥作用
燃尽图如何发挥作用
任务板警示标记
嘿,该怎样进行跟踪呢
天数估算vs小时估算
第7章 我们怎样布置团队房间
让团队坐在一起
让产品负责人无路可走
让经理和教练无路可走
第8章 我们怎样进行每日例会
我们怎样更新任务板
处理迟到的家伙
处理“我不知道今天干什么”的情况
第9章 我们怎样进行sprint演示
为什么我们坚持所有的sprint都结束于演示
sprint演示检查列表
处理“无法演示”的工作
第10章 我们怎样做sprint回顾
我们如何组织回顾
在团队间传播经验
变,还是不变
回顾中发现的问题示例
第11章 sprint之间的休整时刻
第12章 怎样制定发布计划,处理固定价格的合同
定义你的验收标准
对最重要的条目进行时间估算
估算生产率
统计一切因素,生成发布计划
调整发布计划
第13章 我们怎样结合使用Scrum和XP
结对编程
测试驱动开发(TDD)
在新代码上进行TDD
在旧代码上进行TDD
增量设计
持续集成
代码集体所有权
充满信息的工作空间
代码标准
可持续的开发速度/精力充沛地工作
第14章 我们怎样做测试
你大概没法取消验收测试阶段
把验收测试阶段缩到最短
把测试人员放到Scrum团队来提高质量
测试人员就是“验收的家伙”
如果没有任何事情需要测试,那测试人员该做什么
在每个sprint中少做工作来提高质量
验收测试应该作为sprint的一部分么
sprint周期vs验收测试周期
方式1:“在旧版本可以产品化之前,不构建新特性”
方式2:“可以开始构建新东西,但是要给将旧功能产品化分配高优先级”
糟糕的方式——“只关注构建新东西”
别把最慢的一环逼得太紧
硝烟中的Scrum和XP
……
第15章 我们怎样管理多个Scrum团队
第16章 我们怎样管理分布式团队
第17章 ScrumMaster检查列表
第18章 结语
有关Henrik Kniberg
· · · · · · (收起)

读后感

评分

这本书很不错,轻松简单的带你进入Scrum之门,了解实施Scrum的一些实践。不想买的可以在InfoQ下载:http://www.infoq.com/cn/minibooks/scrum-xp-from-the-trenches 万恶的资本家原来想用高度自动化的工具把软件这个行业推向流水线生产,把本来已经杯具的代码工变成《摩登时代...  

评分

评分

这本书的实用不用我来废话了。我的team已经使用scrum有段时间了,今天我又重读了部分章节,现在是一个根据我的个人经验,反思我所在team的scrum实践所存在的不足。 1. 我们混淆了backlog的真正意义,他是产品负责人提出的,从业务角度出发的,可以demo的故事;但是我们的往往是...  

评分

正如本书的副标题所说的那样,“我们如何实施Scrum”,该书能够带你走进Scrum的世界,告诉你每个Scrum对应的事件具体该怎么实施,比如怎么开sprint planning, 怎么开daily scrum等。同时,它还给出了一些在实施过程中遇到的问题以及解决方案。即使你从没实施过Scrum,看完此书...  

评分

正如本书的副标题所说的那样,“我们如何实施Scrum”,该书能够带你走进Scrum的世界,告诉你每个Scrum对应的事件具体该怎么实施,比如怎么开sprint planning, 怎么开daily scrum等。同时,它还给出了一些在实施过程中遇到的问题以及解决方案。即使你从没实施过Scrum,看完此书...  

用户评价

评分

我最近读到的一本关于大规模敏捷框架(SAFe/LeSS等)的书籍,着重于如何将小型敏捷实践的优势,通过结构化的方式,扩展到数百人的大型组织中。这本书的叙事结构非常严谨,不像一些介绍SAFe的书籍那样堆砌术语,而是深入剖析了在跨团队依赖性极高的情况下,如何设计有效的同步机制。它没有盲目鼓吹“一切都敏捷化”,而是清晰地划定了敏捷框架可以发挥最大效用的边界,并解释了在何种规模和复杂度下,需要引入哪些程度的“结构化对齐层”。特别是关于“依赖性梳理工作坊”的详细步骤描述,非常具有操作指导性,它帮助我理解了,在宏观层面,结构并非扼杀敏捷,而是为敏捷提供了一个可以稳定运行的“骨架”,让底层团队能更专注于交付。

评分

最近翻阅的一本关于精益创业的书籍,其叙事风格极其有力,充满了对“浪费”的深刻批判。这本书最让我印象深刻的是,它颠覆了我过去对“规划”的认知。传统上,我们习惯于花费数月时间制定详尽的“完美蓝图”,然后坚信按照蓝图执行就不会出错。然而,这位作者尖锐地指出,在信息不完全的情况下,冗长的前期规划本身就是一种巨大的浪费——浪费了时间,更浪费了倾听市场反馈的机会。书中对于“最小可行产品(MVP)”的定义也极为务实,它不是一个半成品,而是一个能以最小成本验证核心假设的工具。这种对效率极致的追求,以及对“延迟决策”价值的推崇,为我提供了一个全新的批判性框架,去审视我们当前项目启动阶段那些看似必要却效率低下的仪式和会议。

评分

读完一本关于持续交付的书,我深切体会到,工具和流程的革新远不如文化和心态的转变来得困难和关键。这本书的独特之处在于,它没有将重点放在介绍最新的CI/CD流水线工具链有多么强大,而是花费大量篇幅探讨了“信任缺失”如何成为自动化进程的最大障碍。作者通过一系列引人入胜的案例,展示了当开发、测试和运维团队各自为政时,即使拥有最先进的自动化脚本也无法实现真正的敏捷。它强调了跨职能协作中的“共享心智模型”构建,比如,如何通过定期的“运营回顾会议”,让每个人都对最终交付的质量负起共同责任。这种从人本主义角度切入技术实践的视角,对我触动很大。它提醒我们,技术升级永远是手段,解决团队间的协作壁垒和心理隔阂,才是通往卓越交付的核心所在。

评分

另一本关于团队动力学的著作,专注于解释为何一些技术能力极强的团队却无法产出预期的成果。这本书的行文非常偏向心理学分析,它通过对“心理安全感”的量化研究,揭示了一个反直觉的事实:一个允许犯错、鼓励提问的团队,其长期创新能力远超一个追求零缺陷但压抑异议的团队。书中详细描述了如何设计结构化的反馈机制,确保批评是针对“工作产出”而非“个人能力”,这对于建立一个健康的、能够自我修复的工程文化至关重要。我特别喜欢它提出的“非暴力沟通在代码审查中的应用”这一章节,它提供了一套具体的话术和步骤,帮助团队成员在保持高标准的同时,避免人际冲突的升级,这对于维护团队士气至关重要。

评分

最近阅读了好几本关于敏捷开发实践的书籍,让我对如何在复杂多变的项目环境中保持高效和灵活有了更深的认识。市面上许多书籍都在强调“敏捷转型”的宏大叙事,但真正落地实施起来,特别是面对那些传统流程根深蒂固的团队时,往往会遇到重重阻力。我发现,最能打动人心的,往往是那些聚焦于具体实践、能够提供即时可操作建议的指南。比如,有些书会非常细致地剖析故事点估算背后的心理学陷阱,而不是泛泛而谈“估算很重要”。它们会深入探讨如何通过小步快跑、持续集成这些具体行动,来对抗需求蔓延和技术债务的侵蚀。这种脚踏实地的分析,对于那些在实际一线挣扎的团队来说,价值远超那些空洞的理论宣讲。一个优秀的实践指南,应该像一个经验丰富的教练,不仅告诉你该往哪个方向走,更重要的是,它会告诉你脚下的每一步该如何迈出,以及如何应对路上随时可能出现的绊脚石。

评分

等着三个项目组发布的过程中,居然看完了。一口气看完,这是一本好书,亲切、真诚,让我急于想付诸行动。值得读多次。

评分

非常不错的书,比文绉绉的只介绍概念的书好很多,有很强的实践性。

评分

是 @charlee 桑翻译的,多谢呢!

评分

确实是实践之书

评分

是 @charlee 桑翻译的,多谢呢!

本站所有内容均为互联网搜索引擎提供的公开搜索信息,本站不存储任何数据与内容,任何内容与数据均与本站无关,如有需要请联系相关搜索引擎包括但不限于百度google,bing,sogou

© 2026 book.wenda123.org All Rights Reserved. 图书目录大全 版权所有