关于敏捷入门的一本好书推荐

最近几天看了一本好玩又有知识的敏捷入门书《轻松scrum之旅》，值得推荐。

书中总结的实践经验和一些概念如下：

第 4 章  Sprint 1——新手上路
1．当开始研发新产品或者已有产品的新模块时，由于各方面的原因，整个团队 没有能力在 Sprint 的开始就做出一份非常详实的计划，因此，采用“照明弹”策略 绝对不失为一个好办法。
2．对于每一个 Story，要尽可能了解它的需求。
3．在开发过程中，为了提高交流的效率，要尽量避免把精力浪费在不必要的文 档上，取而代之的是要提倡团队之间面对面的直接交流。
4．在实际工作中，Scrum 提倡团队自我管理，在任务分配时每个人都可以按自 己的兴趣来选择任务。
5．团队成员的技能培训是要在做 Sprint 计划时就考虑在内的。
6．虽然每日 Scrum 会议的持续时间会根据整个团队的大小而有所不同，但是， 请不要超过 15 分钟。
7．经理应该充分信任开发团队，不该把每日 Scrum 会议当成每日汇报。
8．在 Scrum 工具的使用上，一定要确保每天都进行准确的更新，只有这样才能 让团队的其他成员以及项目经理掌握及时、准确的项目进度信息。
9．通过 Burndown Chart，Scrum 将给项目带来更多的可视性。
10．每日 Scrum 会议举行的时间应该在早晨还是下午？
11．在每日 Scrum 会议上不要过多地讨论技术难题的细节，如果有团队成员遇 到无法解决的困难时，Scrum Master 应该将其记录下来，会后再调配资源去解决。
12．Scrum 如何解决开发与测试工作同步的问题？
13．每个 Sprint 结束后，最基本的目标是得到一个可以工作的产品。Sprint 结束 时的 Sprint 评审会议和 Sprint 回顾会议都至关重要。 


第 5 章  Sprint 2——计划与变化
14．在 Sprint 计划会议中，Scrum Master 应该主动与 Product Owner 一起制定和 讨论这个 Sprint 的工作。
15．在 Sprint 计划会议中，Scrum Master 不应该抛弃团队成员，团队成员必须全 体参与到计划的讨论中去，并且及时对不明白的地方以及用户需求等进行提问。
16．采用 Wiki 进行文档管理。
17．在 Sprint 计划会议中应该如何制定具体的计划？
18．在 Sprint 进行过程中，遇到临时的员工变化，比如请假，应该怎么办？
19．在 Sprint 计划会议中，应该如何更准确地估计每个 Task 的时间？应该怎样 用计划扑克来估计时间？
20．在 Scrum 中，例如调试机器、准备开发环境这样的任务的工作量也应该体 现在 Sprint 的工作分配中。
21．关于 Scrum 团队大小的讨论。
22．Scrum 与 XP 以及其他一些敏捷方法的关系是怎样的？
23．每日 Scrum 会议为什么需要团队成员站着开，而不能坐着？
24．每日 Scrum 会议需要每天进行，而不能因为每天的任务相似就不召开。Scrum Master 应该在每日会议中敏锐地发现问题，并积极地鼓励团队成员进行讨论。
25．作为一个 Scrum Master，对于自己上司临时安排的非 Sprint 计划的任务，应 该尽量提前在 Sprint 的计划阶段就留出一定的缓冲时间用于处理这些事情，并应该 尽量协调安排好，避免过多非 Sprint 计划的任务出现。
26．作为一个 Scrum Master，应该如何有效地向经理汇报项目进程？
27．Scrum 不鼓励加班。 
 

28．对于不好演示的功能，可以用运行测试用例等其他方式在 Sprint 评审会议 中进行展示。
第 6 章  Sprint 3——深入 Scrum
29．创造一个敏捷的工作环境，让每个 Scrum 团队成员都坐在一起工作。
30．敏捷开发的思想之一也包括避免不必要的浪费，在做 Sprint 计划时应该放 弃实现一些不必要的功能。
31．如何制定一个 Sprint 的目标？
32．Sprint 计划会议需要团队成员事先进行很充分的准备。
33．测试应如何介入 Sprint 中？
34．尝试“结对编程”。
35．在敏捷开发中，应该尽可能地寻找有效的工具提高效率。“工欲善其事，必 先利其器。”
36．对于异地团队，增强沟通是最关键的。初期最好的沟通方式是面对面的交 流。核心人员最好能进行一些面对面的接触。
37．Scrum Master 的职责之一是在完成日常工作的同时，还需要随时帮助团队 成员排除障碍。
38．测试人员应该融入 Scrum 团队，这样做有利于开发团队与测试团队之间的 沟通，以共同保证产品的质量。
39．Scrum 强调团队协作，并且在业绩评定上一直都是以整个团队的成果来衡 量的，这似乎对团队中的某些成员不太公平，毕竟术业有专攻。这种情况下应该怎 样衡量每个人的绩效价值呢？
40．由于团队成员的每个个体在技能、精力、经验上的差别，所以必然会导致 效率的差别。那么，应该如何消除这种差别带来的问题？ 

41．对于项目进行中有可能影响项目结果和交付日期的突发事件，绝不能隐瞒， 而是应当从客户的立场出发，告诉客户实情，并在现有的条件下尽可能满足客户的 需求，同时为客户提供多个解决方案作为备选。
第 8 章  Scrum 4——最后的冲刺
42．在一个 Sprint 结束和新一个 Sprint 开始的中间，应该有一定的缓冲时间。
43．采用 Scrum 回顾模板“团队听诊工具”进行 Scrum 回顾。
44．利用演示工具有效地传递 Sprint 需求。
45．采用 Scrum 后的新部门组织结构。
46．推荐敏捷工具 IBM Rational Team Concert。
47．如果测试人员不习惯自身的角色转换，应该鼓励他们转变思维方式，主动 参与开发过程。
48．关于性能测试的介入时机问题，常见的做法是在第 N+1 个迭代测试第 N 个 迭代的功能。
49．测试新功能前要对老功能做回归测试，以保证新功能不会破坏老功能。
50．关于自动化测试，应该尽力而为，但不能急于求成。
51．一个产品的成功与否需要市场来检验。在产品正式发布之前，如果能有客 户尽早地参与到开发过程中进来，无疑会增加成功的砝码。
52．Scrum 强调在一个 Sprint 中团队的稳定，一个 Sprint 中间的人员变动会对 Sprint 不利，即使加进来足够多的人往往也不能起到提高效率的作用。
53．如何管理素质较低的团队？
54．传统的软件管理体系 CMM/CMMI 的理念与 Scrum 的关系。
55．持续集成的实践。 
               

相关概念 ：
Agile ：敏捷开发。
Backlog ：一项工作。
Build : 指已经编译、构建好的一个可运行的软件版本。
Burndown Chart :  用来显示当前还剩下多少工作未完成的图形化工具。通常以时间为横轴，以本次迭代要完成的工作为纵轴。
Code Review: 代码审核，通常由非代码编写者完成。
Daily Scrum Meeting :
每日 Scrum 会议。每天 15 分钟的每日例会，团队中的每个成员都要回答以下 3 个问题：上次例会到现在我完成了哪些工作？下次例会前我将完成哪些工作？有没 有什么事情阻碍了我的工作？
In Progress : 进行中。
Product Backlog : 产品功能特性列表，主要由产品责任人负责维护并定义优先级。
Product Backlog Item : 产品功能特性列表中的条目，每个条目就是一个工作单元，其大小必须限制在团队可以在一个迭代之内完成。一个工作单元可以被分解成多个任务。
Product Owner : 产品责任人，负责确定 Backlog 中各条目的优先级，同时解决所有关于需求的 问题。
Safari : 苹果操作系统上的浏览器。
Scrum : Scrum 一词来自英式橄榄球，它把软件开发团队比作橄榄球队。Scrum 是当今流 行的敏捷开发方法之一。
Scrum Master : 负责管理每日 Scrum 流程的人，是 Product Owner 和 Team 之间的桥梁，要推动 双方的合作，负责为 Team 成员解决障碍和问题，保证他们工作的顺利进行。Scrum Master 相当于传统软件开发项目中的项目经理或主管。
Sprint : Sprint 代表 Scrum 的一次迭代，周期通常是 30 天，期间不能给 Team 增加额外 的需求，以确保迭代结束时能够获得预期的结果。
Sprint Planning Meeting : Sprint 计划会议，在一次迭代开始时召开，由 Team 与 Product Owner 一起商讨本 次迭代的目标，决定本次迭代要完成哪些工作。
Sprint Review Meeting :Sprint 评审会议，在一次迭代结束时召开，一般以 Demo 的形式由 Team 展示这 个迭代中完成的功能。 
 


Sprint Retrospective Meeting :
Sprint 回顾会议，在 Sprint 评审会议之后召开，由 Team 与 Scrum Master 共同讨 论这个迭代中哪些地方做得比较好，哪些地方需要改进，使团队持续成长。
Stakeholders :
利益相关者，是项目成败对他们影响不大的一类人，他们参与提出产品的需求 并积极提出反馈意见。
Task : 任务。
Team :
跨功能的 Scrum 团队，人数限制在 3～10 人，可能包括的角色有开发人员、架 构师、测试人员、UI 设计师等，是一个自组织的团队，由团队成员自己决定如何更 好地满足用户需求，并承担相应的责任。
User Story :
用户故事（情景），从用户的角度对系统的某个功能模块进行简短描述。
Welcome Lunch  欢迎午宴。
Wiki :
维基百科，一种开放和共享的在线文档编辑系统，任何人都可以在这个系统中 编辑和修改文档，最早的应用是在线的开放式百科全书，现在广泛应用于各种文档 系统。