敏捷开发Scrum开发模式

Scrum与传统瀑布模式开发的区别

Plan

瀑布模式开发通常要花几个月时间来规划产品

Build

再花几个月时间研发产品

Test & Review

接着进行产品的测试与评审

Deploy

最后发布产品

​ 瀑布模式的重点在于要求每个活动的结果都必须经过验证，并且只有经过验证之后才能作为后续开发的基础，这使得瀑布模型特别重视模型与文档，因为这是在可执行代码产生之前唯一能够用来验证的东西，所以瀑布模型被看做是“文档驱动”的，即按照文档的划分、产生和验证来规划、组织和控制开发活动。

​ 如果市场需求或技术环境发生了变化，那么此时研发出的产品很可能无法满足市场需求，瀑布模式的开发在遇到这种变化时会出现很多问题。

​ 首先，产品规划必须早于后续工作之前完成，在绝大多数案例中，规划环节结束时，并没有完全理解项目，但研发工作已经完成了。通常情况下，整个项目必须送回规划阶段，然后从头再来，否则研发人员就会因为不明白产品规划而受到批评。这种情况会反复出现，比如研发完成后，进行产品测试，发现问题就要重新开发，有时甚至需要重新规划产品。

​ 同理，在瀑布模型的其他环节，也可能会出现上述同样的问题。这很可能会导致整个产品发布时间推迟，短则几个月，长则数年。

敏捷开发

敏捷宣言

  • 个体和交互胜于过程和工具
  • 可以工作的软件胜于面面俱到的文档
  • 客户合作胜于合同谈判
  • 响应变化胜于遵循计划

敏捷开发的过程方法

  • 极限编程(XP)
  • Scrum
  • 特性驱动开发(FDD)
  • 自适应软件开发(ASD)
  • …

Scrum框架

Scrum一词来自英式橄榄球(Rugby)比赛，敏捷软件开发团队好比一支橄榄球队：

  • 他们有明确的最高目标，每时每刻都在朝着目标努力
  • 他们熟悉最佳实践，高度自我管理，高度协作，高度灵活地面对各种挑战

而当我们使用Scrum来实施敏捷开发时，情况就不同了，整个项目会分解成为几个不同的小部分。

首先，我们围绕最小化的可行产品的特性进行产品规划，然后将最小的可行产品制作出来。接下来，我们将测试和评审这个产品，直到准备发布。

《轻松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．持续集成的实践。