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

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

”Andrew和Jenny对‘敏捷’概念给出了质朴。易于理解的定义,引起了人们的共鸣,这就是他们的贡献。通过阅读本书,你可以首先纵览所有敏捷方法,然后再决定使用哪一种,并且能够了解整个敏捷系统及其动作原理。“
—Johanna Rothman
《项目管理之道》作者,资深敏捷顾问
www.jrothman.com
  1. 前言
  2. 第1章 学习敏捷
  3. 1.1 什么是敏捷
  4. 1.2 本书的读者对象
  5. 1.3 本书的目标
  6. 1.4 努力建立敏捷思维
  7. 1.5 本书结构
  8. 第2章 理解敏捷价值观
  9. 2.1 团队主管、架构师和项目经理走进了一间酒吧……
  10. 2.2 没有银弹
  11. 2.3 敏捷可以拯救乱局吗
  12. - 2.3.1 引入敏捷,带来变化
  13. - 2.3.2 “聊胜于无”的结果
  14. 2.4 视角割裂
  15. - 2.4.1 视角割裂带来的问题
  16. - 2.4.2 为什么视角割裂只能做到“聊胜于无”
  17. 2.5 敏捷宣言帮助团队认识实践的目的
  18. - 2.5.1 个体和互动高于流程和工具
  19. - 2.5.2 可工作的软件高于详尽的文档
  20. - 2.5.3 客户协作高于合同谈判
  21. - 2.5.4 响应变化高于遵循计划
  22. - 2.5.5 原则高于实践
  23. 2.6 理解敏捷的“大象”
  24. 2.7 着手采用一套新方法
  25. 第3章 敏捷原则
  26. 3.1 敏捷软件开发的12条原则
  27. 3.2 客户总是对的吗
  28. 3.3 交付项目
  29. - 3.3.1 原则1:最优先要做的是尽早、持续地交付有价值的软件,让客户满意
  30. - 3.3.2 原则2:欣然面对需求变化,即使是在开发后期。敏捷过程利用变化为
  31. 客户维持竞争优势
  32. - 3.3.3 原则3:频繁交付可工作的软件,从数周到数月,交付周期越短越好
  33. - 3.3.4 改进电子书阅读器团队的项目交付计划
  34. 3.4 沟通和合作
  35. - 3.4.1 原则4:在团队内外,面对面交谈是最有效、也是最高效的沟通方式
  36. - 3.4.2 原则5:在整个项目过程中,业务人员和开发人员必须每天都在一起工作
  37. - 3.4.3 原则6:以受激励的个体为核心构建项目,为他们提供环境和支持,
  38. 相信他们可以把工作做好
  39. - 3.4.4 在电子书阅读器项目中采用更好的沟通方式 3.5 项目实施——推进项目
  40. - 3.5.1 原则7:可工作的软件是衡量进度的首要标准
  41. - 3.5.2 原则8:敏捷过程倡导可持续开发。赞助商、开发人员和用户要能够
  42. 共同、长期维持其步调,稳定向前
  43. - 3.5.3 原则9:坚持不懈地追求技术卓越和设计优越,以此增强敏捷的能力
  44. 3.5.4 改善电子书阅读器团队的工作环境
  45. 3.6 项目和团队的持续改进
  46. - 3.6.1 原则10:简单是尽最大可能减少不必要工作的艺术,是敏捷的根本
  47. - 3.6.2 原则11:最好的架构、需求和设计来自自组织的团队
  48. - 3.6.3 原则12:团队定期反思如何提升效率,并依此调整
  49. 3.7 敏捷项目:整合所有原则
  50. 第4章 Scrum和自组织团队
  51. 4.1 Scrum的规则
  52. 4.2 第1幕:Scrum的适用条件
  53. 4.3 Scrum团队中每个人都要对项目负责
  54. - 4.3.1 Scrum主管指导团队的决策
  55. - 4.3.2 产品所有者帮助团队了解软件的价值
  56. - 4.3.3 每个人都对项目负责
  57. - 4.3.4 Scrum有一组自己的价值观
  58. 4.4 第2幕:状态更新只是社交网络的玩法
  59. 4.5 整个团队参与每日Scrum例会
  60. - 4.5.1 反馈和“可见? 检查? 调整”周期
  61. - 4.5.2 最后责任时刻
  62. - 4.5.3 召开有效的每日Scrum例会
  63. 4.6 第3幕:将冲刺计划写到墙上
  64. 4.7 冲刺、计划和回顾会议
  65. - 4.7.1 迭代式与增量式
  66. - 4.7.2 冲刺成也在于产品所有者,败也在于产品所有者
  67. - 4.7.3 可见性和价值观
  68. - 4.7.4 计划并执行有效的Scrum冲刺
  69. 4.8 第4幕:尽力之后
  70. 第5章 Scrum计划和集体承诺
  71. 5.1 第5幕:出乎意料
  72. 5.2 用户故事、速度和普遍接受的Scrum实践  
  73. - 5.2.1 提升软件价值
  74. - 5.2.2 以用户故事构建用户真正会用到的功能  
  75. - 5.2.3 满意条件
  76. - 5.2.4 故事点和速度
  77. - 5.2.5 燃尽图
  78. - 5.2.6 通过用户故事、故事点、任务和任务板来计划并实施冲刺
  79. - 5.2.7 广受认可的Scrum实践
  80. 5.3 第6幕:第一次胜利
  81. 5.4 回顾Scrum价值观
  82. - 5.4.1 具体实践没有价值观也有效果(只是别管它叫Scrum)
  83. - 5.4.2 你的公司文化与Scrum的价值观兼容吗  
  84. 第6章 极限编程与拥抱变化
  85. 6.1 第1幕:开始加班
  86. 6.2 极限编程的主要实践
  87. - 6.2.1 编程实践
  88. - 6.2.2 集成实践
  89. - 6.2.3 计划实践
  90. - 6.2.4 团队实践  
  91. - 6.2.5 为什么开发团队抵制变化,上述实践如何提供帮助
  92. 6.3 第2幕:计划有变,但我们还是看不到希望  
  93. 6.4 极限编程的价值观帮助团队改变心态
  94. - 6.4.1 极限编程帮助开发人员学会与用户协作  
  95. - 6.4.2 开发团队的怀疑会破坏实践的效用
  96. 6.5 正确的思维从极限编程的价值观开始
  97. - 6.5.1 极限编程的价值观
  98. - 6.5.2 以善意铺就
  99. 6.6 第3幕:势头的变换
  100. 6.7 理解极限编程价值观,拥抱变化
  101. - 6.7.1 极限编程的指导原则
  102. - 6.7.2 极限编程指导原则可以加深对计划的理解 
  103. - 6.7.3 极限编程指导原则与实践相互促进
  104. - 6.7.4 反馈循环
  105. 第7章 极限编程、简化和增量式设计
  106. 7.1 第4幕:再次加班
  107. 7.2 代码和设计
  108. - 7.2.1 代码异味和反模式(如何判断你是不是聪明过头了)
  109. - 7.2.2 极限编程团队主动寻找和修复代码异味  
  110. - 7.2.3 钩子、边界情况以及功能过多的代码
  111. - 7.2.4 代码异味会增加复杂性
  112. 7.3 把编码和设计决定留到最后责任时刻
  113. - 7.3.1 决然重构,偿还技术债务
  114. - 7.3.2 持续集成,排查设计问题
  115. - 7.3.3 避免一体式设计
  116. 7.4 增量式设计与极限编程的整体实践
  117. - 7.4.1 有时间进行思考,团队才能做好工作
  118. - 7.4.2 团队成员彼此信任并共同作出决定
  119. - 7.4.3 极限编程的设计、计划、团队和整体实践形成了一个带动创新的系统
  120. - 7.4.4 增量式设计与为了复用而设计
  121. - 7.4.5 简化单元交互,系统实现增量式成长
  122. - 7.4.6 优秀的设计源自简单的交互
  123. 7.5 第5幕:最终得分
  124. 第8章 精益、消除浪费和着眼全局
  125. 8.1 精益思维
  126. - 8.1.1 你已经理解了很多精益价值观
  127. - 8.1.2 承诺、选择意识和集合式开发
  128. 8.2 第1幕:还有一件事……
  129. 8.3 创造英雄与神奇思维
  130. 8.4 消除浪费
  131. 8.5 加深对产品的理解
  132. - 8.5.1 着眼全局
  133. - 8.5.2 找到问题的根本原因
  134. 8.6 尽快交付
  135. - 8.6.1 使用面积图可视化工作进度
  136. - 8.6.2 限制进行中的工作,控制瓶颈
  137. - 8.6.3 拉动式系统帮助团队消除约束
  138. 第9章 看板方法、流程和持续改进
  139. 9.1 第2幕:紧赶慢赶的游戏
  140. 9.2 看板方法的原则
  141. - 9.2.1 找到一个出发点并由此进行实验性的演进 
  142. - 9.2.2 用户故事进去,代码出来
  143. 9.3 用看板方法改进流程
  144. - 9.3.1 将工作流程可视化
  145. - 9.3.2 限制进行中的工作
  146. 9.4 测量并管理流量
  147. - 9.4.1 用CFD和进行中工作面积图测量并管理流量- 9.4.2 用利特尔法则控制系统的流量
  148. - 9.4.3 用进行中工作上限管理流量,自然地创造缓冲
  149. - 9.4.4 让过程策略明确统一
  150. 9.5 看板方法下自然发生的行为
  151. 第10章 敏捷教练
  152. 10.1 第3幕:还有一件事(又来了?!)……
  153. 10.2 教练要理解人们为什么不想改变
  154. 10.3 教练要理解人们如何学习
  155. 10.4 教练清楚如何让一套方法起作用
  156. 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.