​ 这段时间,我读了一本书《轻松Scrum之旅》,这是一本小说般的一本技术书籍,作者使用了小说的形式来介绍Scrum的基本概念,并且使用了一个完整的项目来向读者呈现出书中的主人公关毅在实行Scrum框架中遇到的各种问题以及解决思路,使读者产生更加感性的认识。

​ 在传统的瀑布模型中,我们需要按部就班完成从需求分析,软件设计,编码实现,软件测试到软件交付与维护等一系列步骤,一般前一个步骤完成不了后一个步骤就无法推进,而这层层推进需要对文档有着很强的依赖,然而软件开发中变数太多,有时经常会遇到客户的需求发生变更等异常情况,所以提前预测变得相当困难,故如今瀑布模式的软件开发已经不适用了,现在比较流行的软件开发方法就是敏捷开发(Agile)。

敏捷宣言

对于敏捷开发宣言中的每一项,我的理解如下:

  • 个体和交互胜于过程和工具,这句话强调以人为本。

  • 可以工作的软件胜于面面俱到的文档,这句话强调了文档的地位在敏捷开发中的地位被削弱,每个环节的沟通一般采用最有效的方式沟通,即面对面的交流,能产出能用的产品才是重要的。

  • 客户合作胜于合同谈判,这一点强调了敏捷开发中,客户不能像订购日用品一样订购软件,仅仅写下一份软件描述,而要有着频繁的,有序的客户反馈,让客户也真正地参与在项目中,提供经常地反馈。

  • 响应变化胜于遵循计划,传统的瀑布模型,往往前期做大量的计划,制定约束,编写详细的文档,而现实世界变化往往大于不变的,适用环境,客户需求等常常发生变更,这使得传统的瀑布模型不再适用。

​ 从敏捷宣言中,我们可以看出,敏捷开发的核心价值观非常符合现代的软件开发需求,所以如今我认为学习了解一些敏捷开发思想相当重要,敏捷开发中常用的过程方法有极限编程(XP),Scrum,特性驱动开发(FDD),自适应软件开发(ASD)……

​ 迄今为止,Scrum最常用于管理复杂的软件和产品开发。它由三个角色,三个工件,五个事件所构成。

三个角色

  1. Product Owner
    产品负责人,产品经理,用于负责确定 Product Backlog 中各条目的优先级,其中的每一个条目又叫做用户故事(User Story),它必须从客户价值角度描述,并按优先级排序。

  2. Scrum Master
    负责管理每日 Scrum 流程的人,是 Product Owner 和 Team 之间的桥梁,要推动双方的合作,负责为 Team 成员解决障碍和问题,保证他们工作的顺利进行。Scrum Master 相当于传统软件开发项目中的项目经理或主管。

  3. Team
    跨功能的 Scrum 团队,人数限制在 3~10 人,可能包括的角色有开发人员、架构师、测试人员、UI 设计师等,是一个自组织的团队,由团队成员自己决定如何更好地满足用户需求,并承担相应的责任。

三个工件与Sprint流程

​ 产品负责人建立产品功能列表(Product Backlog)。产品功能列表是一组条目化需求,每一项又叫做User story用户故事,它必须从客户价值角度描述,并按优先级排序。
​ 在Sprint 1开始之前,由Product Owner确定Product Backlog,然后就能够开始正式的Sprint流程了。
Sprint代表Scrum的一次迭代,周期通常为30天,期间不能给Team增加额外的需求,以确保迭代结束时能够获得预期的结果。

image-20211013065604052

​ 如图,这是一次Sprint的完整流程,首先开展Sprint计划会议,确定Sprint Backlog即这次Sprint中所需要完成的所有Story并按优先级排序,如果某个Story太大,还需要进一步地分解。
​ 然后每日开展Sprint站会,让整个团队清楚地知道在这一个Sprint周期内各项任务的进展,所有的任务是否能够按时完成。每日站会可以根据需求在每日早上上班后或下午下班前开展。

​ 经过一段时间的开发测试后,产出可以运行,能够展示的Demo用于在Sprint评审会议上展示。 Sprint评审会议结束之后,开展Sprint回顾会议,由Team与Scrum Master共同讨论这个迭代中哪些地方做得比较好,哪些地方需要改进,下一个Sprint中应当如何改进,这有利于使团队持续成长。

​ 三个工件中,increment即Product backlog中所有已标记为Done(已完成)的story。

五个事件

Sprint

一个Sprint实际上是一次迭代周期,是一个大事件,其中包含了如下四个事件。

Sprint Planning Meeting

​ Sprint 计划会议,在一个迭代开始时召开,由Team与Product Owner 一起商讨本次迭代的目标,确定本次迭代要完成的哪些工作。
​ 首先由Product Owner(产品负责人或产品经理)列出Product Backlog(产品需求列表),并按优先级对它进行排序,其中包含了客户想要的东西,并用客户的术语加以描述。其中的每个条目我们称之为backlog item(需求事项)或user story(用户故事)

Daily Sprint Meeting

这是Scrum的活力源泉,Daily Sprint Meeting每日站会。

参会人员:Scrum Master, Team
地点:固定地点
时间:固定时间,一般在早晨,时长不超过15分钟
要求:站立进行,Scrum Master需要向团队提出以下问题

  1. 你昨天完成了哪些工作?
  2. 你今天计划做哪些工作?
  3. 目前的困难及障碍?

意义: 让整个团队清楚地知道在这一个Sprint周期内各项任务 的进展,所有的任务是否能够按时完成

Sprint Review Meeting

​ Sprint 评审会议,在一次迭代结束时召开,一般以Demo的形式由Team展示这个迭代中已完成的功能。

Sprint Retrospective Meeting

​ Sprint 回顾会议,在Sprint 评审会议之后召开,由Team与Scrum Master共同讨论这个迭代中哪些地方做得比较好,哪些地方需要改进,使团队持续成长。

​ 如同《敏捷革命》所说的那样:Scrum需要实践和专注,只有持续不断地付出努力,才能达到新的状态。希望我们在前进的路上,我相信,我们会越来越好!

问题讨论

Scrum Master与传统项目经理的对比

Scrum Master的职责

  • 帮助,促进,鼓励,保护团队,为团队扫清一切障碍

  • 守护Scrum的规则

  • 学习与分享

项目经理的职责

对项目与团队的计划,控制,领导,管理,组织,协调

1、传统的项目经理在组织中是经过授权的,而ScrumMaster在团队中没有授权,ScrumMaster在组织中最重要的职责是实践敏捷思想,确保Scrum流程的正确执行并使得Scrum的收益最大化。

2、传统的项目经理负责团队成员任务的分工,而Scrum中强调自管理,ScrumMaster很重要的任务是帮助团队得到能力的提升,不负责具体的任务。

3、ScrumMaster属于服务型领导,负责在自组织和跨职能方面提供指导

use case 与 user story

Use Case(用例) :在不展现一个系统或子统内部结构的情况下,对系统或子系统的某连贯的功能单元的定义和描述。
User Story(用户故事):描述对软件(或系统)用或客户有价值的功能,只是需求描述,而不是详细的求规范。
从定义上其实可以看出来,Use Case是UML中一个重要的概念,他采用actor和系统交互的方式来描述用户需求,使用了一套逻辑上相对完整的事件流来定义,他包括了名称、描述、主要事件流、扩展流、异常流、前置条件和后置条件等等元素,可见他描述需求是相当详细的,在RUP过程中使用得比较多。User Story描述用户需求则是离客户更近一步,他所使用的描述语言类似于“作为XXXX,我希望xxxxxx”这种方式,例如,作为用户,我希望能够查看订单列表,简单的描述用户需要的东西。而没有定义如何交互等事件流方式,这种需求描述形式是比较抽象的,使用User Story在敏捷项目中使用比较多,当然Use Case 也适合敏捷项目。

Scrum适合开发像操作系统这样的复杂的大型项目吗?

不同规模的公司可能会使用不同的过程和实践。与涉及到一个或者两个人的项目相比,涉及到数百人的项目肯定会有不同的控制和抑制因素。沟通频率会随着项目成员的增加而按指数增加。为了获取重要的交流信息,大型的团队必须以更加严格和正式的方式进行工作。上面所有我提到的公司,运行的是敏捷方法很适合的项目。可能并不是所有的项目都认同敏捷,但是许多公司确实是认同的。这样的项目与顾客有规则的交流,并且必须处理需求的快速更改。开发团队成员相互之间必须有紧密的合作,并要快速不带迟疑的对系统作出决定。

像操作系统这样的大型项目,开发人员肯定不是那种几人的小项目,敏捷提倡的面对面的沟通在这样的项目中将会变得非常复杂,而敏捷不提倡书写大量的精美的文档是因为提倡使用面对面的沟通,但若开发操作系统这样复杂的软件,大量的文档个人认为是必不可少的,这样团队成员在开发操作系统的某个模块时,就没必要熟悉项目的代码了,可以只负责自己的那一部分,通过文档来熟悉其他模块。而且像操作系统这类软件,有着前人的经验,不像是定制一个新软件,可能拥有灵活的需求变动,只要按部就班就能完成项目,故我认为对于操作系统这类软件,传统的瀑布模型可能会更加适合,但我们也可以从敏捷开发中借鉴一些思想到这里来,如结对编程,测试驱动开发等。