敏捷开发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.持续集成的实践。