敏捷过程备忘

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 回顾会议都至关重要。
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 不鼓励加班。
272
28．对于不好演示的功能，可以用运行测试用例等其他方式在 Sprint 评审会议
中进行展示。
29．创造一个敏捷的工作环境，让每个Scrum 团队成员都坐在一起工作。
30．敏捷开发的思想之一也包括避免不必要的浪费，在做Sprint 计划时应该放
弃实现一些不必要的功能。
31．如何制定一个Sprint 的目标？
32．Sprint 计划会议需要团队成员事先进行很充分的准备。
33．测试应如何介入Sprint 中？
34．尝试“结对编程”。
35．在敏捷开发中，应该尽可能地寻找有效的工具提高效率。“工欲善其事，必
先利其器。”
36．对于异地团队，增强沟通是最关键的。初期最好的沟通方式是面对面的交
流。核心人员最好能进行一些面对面的接触。
37．Scrum Master 的职责之一是在完成日常工作的同时，还需要随时帮助团队
成员排除障碍。
38．测试人员应该融入Scrum 团队，这样做有利于开发团队与测试团队之间的
沟通，以共同保证产品的质量。
39．Scrum 强调团队协作，并且在业绩评定上一直都是以整个团队的成果来衡
量的，这似乎对团队中的某些成员不太公平，毕竟术业有专攻。这种情况下应该怎
样衡量每个人的绩效价值呢？
40．由于团队成员的每个个体在技能、精力、经验上的差别，所以必然会导致
效率的差别。那么，应该如何消除这种差别带来的问题？
273
案例索引
41．对于项目进行中有可能影响项目结果和交付日期的突发事件，绝不能隐瞒，
而是应当从客户的立场出发，告诉客户实情，并在现有的条件下尽可能满足客户的
需求，同时为客户提供多个解决方案作为备选。
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．持续集成的实践。