学习敏捷：构建高效团队
学习敏捷：构建高效团队
Andrew Stellman, Jennifer Greene 著
段志岩, 郑思遥 译
出版时间：2017年02月
页数：308
敏捷方法革新了软件团队的开发方式。然而，目前的敏捷实践门类众多，很多团队不知如果选择。本书立足实际情况，帮助准备接受敏捷的团队理清头绪。作者首先介绍敏捷方法背后的原则，进而详细详解四种常用的敏捷方法：Scrum、极限编程、精益和看板方法。
上述每一种方法都侧重于开发过程中的一个不同方面，但目标都是改变团队的思维方式，将服从计划的独立个体凝聚成共同决策的团队。无论是初次接触还是重新尝试，你和你的团队都可以借助本书学习如何选择最合适的敏捷方法。

● 理解敏捷价值观和原则的初衷
● 理解Scrum为何强调项目管理、自组织和集体承诺
● 通过测试先行、结对编程等极限编程实践聚焦软件设计和架构
● 使用精益思维给团队增添力量，避免浪费并快速交付软件
● 学习看板方法如何在实践中管理流程，协助交付优秀的软件
● 在教练指导下采用敏捷的实践和原则

”Andrew和Jenny对‘敏捷’概念给出了质朴。易于理解的定义，引起了人们的共鸣，这就是他们的贡献。通过阅读本书，你可以首先纵览所有敏捷方法，然后再决定使用哪一种，并且能够了解整个敏捷系统及其动作原理。“
—Johanna Rothman
《项目管理之道》作者，资深敏捷顾问
www.jrothman.com
  1. 序
  2. 前言
  3. 第1章　学习敏捷
  4. 1.1　什么是敏捷
  5. 1.2　本书的读者对象
  6. 1.3　本书的目标
  7. 1.4　努力建立敏捷思维
  8. 1.5　本书结构
  9. 第2章　理解敏捷价值观
  10. 2.1　团队主管、架构师和项目经理走进了一间酒吧……
  11. 2.2　没有银弹
  12. 2.3　敏捷可以拯救乱局吗
  13. - 2.3.1　引入敏捷，带来变化
  14. - 2.3.2　“聊胜于无”的结果
  15. 2.4　视角割裂
  16. - 2.4.1　视角割裂带来的问题
  17. - 2.4.2　为什么视角割裂只能做到“聊胜于无”
  18. 2.5　敏捷宣言帮助团队认识实践的目的
  19. - 2.5.1　个体和互动高于流程和工具
  20. - 2.5.2　可工作的软件高于详尽的文档
  21. - 2.5.3　客户协作高于合同谈判
  22. - 2.5.4　响应变化高于遵循计划
  23. - 2.5.5　原则高于实践
  24. 2.6　理解敏捷的“大象”
  25. 2.7　着手采用一套新方法
  26. 第3章　敏捷原则
  27. 3.1　敏捷软件开发的12条原则
  28. 3.2　客户总是对的吗
  29. 3.3　交付项目
  30. - 3.3.1　原则1：最优先要做的是尽早、持续地交付有价值的软件，让客户满意
  31. - 3.3.2　原则2：欣然面对需求变化，即使是在开发后期。敏捷过程利用变化为
  32. 客户维持竞争优势
  33. - 3.3.3　原则3：频繁交付可工作的软件，从数周到数月，交付周期越短越好
  34. - 3.3.4　改进电子书阅读器团队的项目交付计划
  35. 3.4　沟通和合作
  36. - 3.4.1　原则4：在团队内外，面对面交谈是最有效、也是最高效的沟通方式
  37. - 3.4.2　原则5：在整个项目过程中，业务人员和开发人员必须每天都在一起工作
  38. - 3.4.3　原则6：以受激励的个体为核心构建项目，为他们提供环境和支持，
  39. 相信他们可以把工作做好
  40. - 3.4.4　在电子书阅读器项目中采用更好的沟通方式　3.5　项目实施——推进项目
  41. - 3.5.1　原则7：可工作的软件是衡量进度的首要标准
  42. - 3.5.2　原则8：敏捷过程倡导可持续开发。赞助商、开发人员和用户要能够
  43. 共同、长期维持其步调，稳定向前
  44. - 3.5.3　原则9：坚持不懈地追求技术卓越和设计优越，以此增强敏捷的能力
  45. 3.5.4　改善电子书阅读器团队的工作环境
  46. 3.6　项目和团队的持续改进
  47. - 3.6.1　原则10：简单是尽最大可能减少不必要工作的艺术，是敏捷的根本
  48. - 3.6.2　原则11：最好的架构、需求和设计来自自组织的团队
  49. - 3.6.3　原则12：团队定期反思如何提升效率，并依此调整
  50. 3.7　敏捷项目：整合所有原则
  51. 第4章　Scrum和自组织团队
  52. 4.1　Scrum的规则
  53. 4.2　第1幕：Scrum的适用条件
  54. 4.3　Scrum团队中每个人都要对项目负责
  55. - 4.3.1　Scrum主管指导团队的决策
  56. - 4.3.2　产品所有者帮助团队了解软件的价值
  57. - 4.3.3　每个人都对项目负责
  58. - 4.3.4　Scrum有一组自己的价值观
  59. 4.4　第2幕：状态更新只是社交网络的玩法
  60. 4.5　整个团队参与每日Scrum例会
  61. - 4.5.1　反馈和“可见? 检查? 调整”周期
  62. - 4.5.2　最后责任时刻
  63. - 4.5.3　召开有效的每日Scrum例会
  64. 4.6　第3幕：将冲刺计划写到墙上
  65. 4.7　冲刺、计划和回顾会议
  66. - 4.7.1　迭代式与增量式
  67. - 4.7.2　冲刺成也在于产品所有者，败也在于产品所有者
  68. - 4.7.3　可见性和价值观
  69. - 4.7.4　计划并执行有效的Scrum冲刺
  70. 4.8　第4幕：尽力之后
  71. 第5章　Scrum计划和集体承诺
  72. 5.1　第5幕：出乎意料
  73. 5.2　用户故事、速度和普遍接受的Scrum实践　　
  74. - 5.2.1　提升软件价值
  75. - 5.2.2　以用户故事构建用户真正会用到的功能　　
  76. - 5.2.3　满意条件
  77. - 5.2.4　故事点和速度
  78. - 5.2.5　燃尽图
  79. - 5.2.6　通过用户故事、故事点、任务和任务板来计划并实施冲刺
  80. - 5.2.7　广受认可的Scrum实践
  81. 5.3　第6幕：第一次胜利
  82. 5.4　回顾Scrum价值观
  83. - 5.4.1　具体实践没有价值观也有效果（只是别管它叫Scrum）
  84. - 5.4.2　你的公司文化与Scrum的价值观兼容吗　　
  85. 第6章　极限编程与拥抱变化
  86. 6.1　第1幕：开始加班
  87. 6.2　极限编程的主要实践
  88. - 6.2.1　编程实践
  89. - 6.2.2　集成实践
  90. - 6.2.3　计划实践
  91. - 6.2.4　团队实践　　
  92. - 6.2.5　为什么开发团队抵制变化，上述实践如何提供帮助
  93. 6.3　第2幕：计划有变，但我们还是看不到希望　　
  94. 6.4　极限编程的价值观帮助团队改变心态
  95. - 6.4.1　极限编程帮助开发人员学会与用户协作　　
  96. - 6.4.2　开发团队的怀疑会破坏实践的效用
  97. 6.5　正确的思维从极限编程的价值观开始
  98. - 6.5.1　极限编程的价值观
  99. - 6.5.2　以善意铺就
  100. 6.6　第3幕：势头的变换
  101. 6.7　理解极限编程价值观，拥抱变化
  102. - 6.7.1　极限编程的指导原则
  103. - 6.7.2　极限编程指导原则可以加深对计划的理解　
  104. - 6.7.3　极限编程指导原则与实践相互促进
  105. - 6.7.4　反馈循环
  106. 第7章　极限编程、简化和增量式设计
  107. 7.1　第4幕：再次加班
  108. 7.2　代码和设计
  109. - 7.2.1　代码异味和反模式（如何判断你是不是聪明过头了）
  110. - 7.2.2　极限编程团队主动寻找和修复代码异味　　
  111. - 7.2.3　钩子、边界情况以及功能过多的代码
  112. - 7.2.4　代码异味会增加复杂性
  113. 7.3　把编码和设计决定留到最后责任时刻
  114. - 7.3.1　决然重构，偿还技术债务
  115. - 7.3.2　持续集成，排查设计问题
  116. - 7.3.3　避免一体式设计
  117. 7.4　增量式设计与极限编程的整体实践
  118. - 7.4.1　有时间进行思考，团队才能做好工作
  119. - 7.4.2　团队成员彼此信任并共同作出决定
  120. - 7.4.3　极限编程的设计、计划、团队和整体实践形成了一个带动创新的系统
  121. - 7.4.4　增量式设计与为了复用而设计
  122. - 7.4.5　简化单元交互，系统实现增量式成长
  123. - 7.4.6　优秀的设计源自简单的交互
  124. 7.5　第5幕：最终得分
  125. 第8章　精益、消除浪费和着眼全局
  126. 8.1　精益思维
  127. - 8.1.1　你已经理解了很多精益价值观
  128. - 8.1.2　承诺、选择意识和集合式开发
  129. 8.2　第1幕：还有一件事……
  130. 8.3　创造英雄与神奇思维
  131. 8.4　消除浪费
  132. 8.5　加深对产品的理解
  133. - 8.5.1　着眼全局
  134. - 8.5.2　找到问题的根本原因
  135. 8.6　尽快交付
  136. - 8.6.1　使用面积图可视化工作进度
  137. - 8.6.2　限制进行中的工作，控制瓶颈
  138. - 8.6.3　拉动式系统帮助团队消除约束
  139. 第9章　看板方法、流程和持续改进
  140. 9.1　第2幕：紧赶慢赶的游戏
  141. 9.2　看板方法的原则
  142. - 9.2.1　找到一个出发点并由此进行实验性的演进　
  143. - 9.2.2　用户故事进去，代码出来
  144. 9.3　用看板方法改进流程
  145. - 9.3.1　将工作流程可视化
  146. - 9.3.2　限制进行中的工作
  147. 9.4　测量并管理流量
  148. - 9.4.1　用CFD和进行中工作面积图测量并管理流量- 9.4.2　用利特尔法则控制系统的流量
  149. - 9.4.3　用进行中工作上限管理流量，自然地创造缓冲
  150. - 9.4.4　让过程策略明确统一
  151. 9.5　看板方法下自然发生的行为
  152. 第10章　敏捷教练
  153. 10.1　第3幕：还有一件事（又来了？！）……
  154. 10.2　教练要理解人们为什么不想改变
  155. 10.3　教练要理解人们如何学习
  156. 10.4　教练清楚如何让一套方法起作用
  157. 10.5　进行敏捷指导时的原则
书名：学习敏捷：构建高效团队
译者：段志岩, 郑思遥 译
国内出版社：人民邮电出版社
出版时间：2017年02月
页数：308
书号：978-7-115-44755-5
原版书书名：Leerning Agile
原版书出版商：O'Reilly Media
Andrew Stellman
 
Andrew Stellman，虽然是一个土生土长的纽约人，却曾两次居住在匹兹堡。第一次是从卡耐基梅隆计算机科学学院毕业，第二次则是他和Jenny开始着手开展他们的咨询业务，并为O’Reilly写他们的第一本书。
搬回故乡后，他在大学毕业后的第一份工作是在百代唱片公司EMI-Capitol Records做一名程序员——这不无道理，因为他曾在LaGuardia音乐艺术和表演艺术学校学习大提琴和爵士乐吉它。他和Jenny的第一次共事就是在这家财务软件公司，在那里他管理着一个程序员团队，所以独享特权，可以与一些了不起的程序员共事多年，并很高兴地从他们那里学到不少东西。
平常不写书时，Andrew会忙于写一些没用（但有趣）的软件，玩音乐（不过，更多的时间是打电子游戏），学中国的太极拳和日本的合气道。他有一个女朋友Lisa，还养着一只波美拉尼亚种小狗。
Jennifer Greene and Andrew Stellman have been building software together since 1998.
Andrew comes from a programming background and has managed teams of requirements analysts, designers, and developers. Jennifer has a testing background and has managed teams of architects, developers, and testers.
She has led multiple large-scale outsourced projects.
Between the two of them, they have managed every aspect of software development. They formed Stellman & Greene Consulting in 2003, with a focus on project management, software development, management consulting, and soft-ware process improvement. They have worked in a wide range of industries, including finance, telecommunications, media,nonprofit, enter-tainment, natural language processing, science, and academia.
For more information about them and this book, visit http://www.stellman-greene.com.
 
 
Jennifer Greene
 
Jennifer Greene在大学里学的是哲学，不过，与这个领域中的所有人一样，光凭哲学没办法找到工作。幸运的是，她是一位优秀的软件测试人员，所以最早在一个网上服务公司从事这个工作，这也是她第一次切实感觉到项目管理的意义。
她于1998年移居到纽约，在一家财务软件公司做软件测试工作。她在新成立的一家很棒的公司管理着一个测试人员团队（这家公司主要研究人工智能和自然语言处理）。
在那之后，她的足迹遍布世界各地，曾与不同的软件开发团队共事，并且构建了很多相当不错的项目。
她喜欢旅游、看好莱坞电影、看漫画书。她经常把她的Xbox弄坏，等着修理。她喜欢喝很多碳酸饮料，另外还有一个机灵的小狗陪伴左右。
Jennifer Greene and Andrew Stellman have been building software together since 1998.
Andrew comes from a programming background and has managed teams of requirements analysts, designers, and developers. Jennifer has a testing background and has managed teams of architects, developers, and testers.
She has led multiple large-scale outsourced projects.
Between the two of them, they have managed every aspect of software development. They formed Stellman & Greene Consulting in 2003, with a focus on project management, software development, management consulting, and soft-ware process improvement. They have worked in a wide range of industries, including finance, telecommunications, media,nonprofit, enter-tainment, natural language processing, science, and academia.
For more information about them and this book, visit http://www.stellman-greene.com.
 
 
购买选项
定价：79.00元
书号：978-7-115-44755-5
出版社：人民邮电出版社
联系出版社邮购

© 2026，奥莱利技术咨询(北京)有限公司。版权所有。
传真: +86-10-88097463
 京ICP备05003502号