论文部分内容阅读
摘要：敏捷开发过程重视团队的交流与管理问题，其提高开发效率的成果着实明显，一直在软件管理学术领域保持着充分的活力; SCRUM过程无疑是目前最为成功的敏捷方法。它强调的小团队、多交流、频繁发布的开发模式取得了巨大成功。
本文将结合实际，对SCRUM的思想和开发过程进行详述。
关键词：软件工程;敏捷开发;SCRUM
一、SCRUM的來源和理论
SCRUM很容易被认为是某些单词的首字母集合，但其实并不是。SCRUM是一个英文固有单词，原意是指英式橄榄球的一种争球活动。1986年，日本学者首次使用了Scrum来代指软件开发过程中的如下活动：
一种以团队为单位通过相互合作，来回传球，向前推进的软件开发方式。
看来，SRCUM的初衷就是重视团队之间的交流以及频繁的效果展示或交付。
SCRUM也推崇了增量模型的开发理念。软件开发的增量模型就强调要在开发过程中出现多个交付版本。最初的版本是“核心产品”，可以满足用户基本的需求;继而在后续多个增量中，产品的功能不断得到完善。比如，要为用户制作一款导航软件。那么在第一阶段，可以让用户能在软件中先看到地图，对软件的充满信心;第二个版本可以加入定位功能;第三个版本指定地点，进行测距;……最终一步步地完善产品的功能，使用户不断地对软件的未来充满希望，让需求一步步地被满足，尽可能避免了最终产品与需求偏差过大。这种开发过程将是十分具有成就感的。
二、SCRUM的开发过程
SCRUM推崇6至9人的小团队模式，认为这样能够较大地缩短交付时间和成本。当一个软件开发开始，其实谁都不能精确知道项目最终会做成什么样子;对于此，SCRUM要求将项目划分为多个里程碑。每次里程碑就相当于一个增量。每当完成一个里程碑任务，团队应当产生一个最初的可执行版本，并且及时地组织会议，对当前版本的开发情况进行探讨。每日例会是SCRUM开发的核心和精髓。会议内容大概可以分为三部分：发现和提出问题（展示已做的功能）、检查和修正开发方向、制定下一步的开发计划。
会议开始时，各个成员或者小组向大家讲述上一阶段的目标以及完成的情况，并展示相关功能或者出具组内设计和讨论的结果;接着，“检查和修正开发方向”，这一步是最为重要的，因为这一步和用户的需求直接挂钩，影响着整个产品的质量好坏，也决定着项目的成败。这里就要提到SCRUM中PO和SM两个角色。
SM，即Scrum Master，这个角色需要1～2名成员，它们需要在开发过程中一直保持头脑清醒，牢牢把握住项目的需求以及需求变更，以能够在每次里程碑会议上正确地判断当前项目的前进方向是否符合当前的项目需求，如果设计有跑偏的迹象，则要及时对项目的理念提出修改建议。可以说SM决定着项目的“生命”。
PO，即Project Owner，其任务是在每次讨论中综合大家提出的BUG或者改进意见，在会后能够将更新修改的部分整合到项目中，并根据SM的指导意见整理出团队的下一阶段目标。PO的存在保证了项目的完成质量。在较小的项目开发中，PO和SM两个角色也可以由同一人担任。
虽然最终的开发方向由SM来指导，但是SCRUM是鼓励每个成员在会议中积极发表意见，最好能形成头脑风暴，经常能产生一些极有价值的观点，最终可以被记录到阶段目标中，并将其逐步实现。
就这样，通过每次里程碑的团队会议，在纠正项目方向的同时保证产品的功能质量，逐渐地完成软件的增量。
三、功能设计要求
在设计软件的功能上，强调User Story（用户场景）和Acceptance Criteria（接受条件）。
用户场景是指，用户为了完成某一项操作，而要使用的一系列功能集合。这里可能牵扯到一个角色转换的问题。开发人员并不容易从用户的角度去考虑使用的问题，尤其是在面对自己做的功能时，很难发现一些使用户体验差的问题。而尝试编写一个用户场景能够较容易地将开发员人带入到用户的角色中思考问题。假如要设计一款具有定位发布签到功能的软件，那么从用户角度设想一下，为了发布签到，用户可能经过如下步骤：
1.点击发布签到按钮;2.设置签到名称;3.设置签到开始时间;4.设置签到结束时间;5.设置签到中心点;6.设置签到范围;7.点击发布按钮。
那么以上七步就是一个完整的User Story。User Story能够很有效地让开发人员尽早地发现用例设计的不足;或者是在测试时能够感觉到一些设计上对用户不友好的地方。
在考虑软件功能设计时，还可以通过考虑其接收条件来确保功能的完整性。也就是考虑AC-Acceptance Criteria。AC是User Story的一部分。它要求开发者考虑在执行User Story之前用户所必须已做的一些操作。
参考文献：
[1] [美] Roger S. Pressman，等.软件工程：实践者的研究方法（第8版）[M].郑人杰，等，译.北京：机械工业出版社， 2016： 32， 53-54.
[2] 叶俊文.基于Scrum敏捷方法的标准研制项目管理优化研究[D]. 广州： 华南理工大学， 2018.
本文将结合实际，对SCRUM的思想和开发过程进行详述。
关键词：软件工程;敏捷开发;SCRUM
一、SCRUM的來源和理论
SCRUM很容易被认为是某些单词的首字母集合，但其实并不是。SCRUM是一个英文固有单词，原意是指英式橄榄球的一种争球活动。1986年，日本学者首次使用了Scrum来代指软件开发过程中的如下活动：
一种以团队为单位通过相互合作，来回传球，向前推进的软件开发方式。
看来，SRCUM的初衷就是重视团队之间的交流以及频繁的效果展示或交付。
SCRUM也推崇了增量模型的开发理念。软件开发的增量模型就强调要在开发过程中出现多个交付版本。最初的版本是“核心产品”，可以满足用户基本的需求;继而在后续多个增量中，产品的功能不断得到完善。比如，要为用户制作一款导航软件。那么在第一阶段，可以让用户能在软件中先看到地图，对软件的充满信心;第二个版本可以加入定位功能;第三个版本指定地点，进行测距;……最终一步步地完善产品的功能，使用户不断地对软件的未来充满希望，让需求一步步地被满足，尽可能避免了最终产品与需求偏差过大。这种开发过程将是十分具有成就感的。
二、SCRUM的开发过程
SCRUM推崇6至9人的小团队模式，认为这样能够较大地缩短交付时间和成本。当一个软件开发开始，其实谁都不能精确知道项目最终会做成什么样子;对于此，SCRUM要求将项目划分为多个里程碑。每次里程碑就相当于一个增量。每当完成一个里程碑任务，团队应当产生一个最初的可执行版本，并且及时地组织会议，对当前版本的开发情况进行探讨。每日例会是SCRUM开发的核心和精髓。会议内容大概可以分为三部分：发现和提出问题（展示已做的功能）、检查和修正开发方向、制定下一步的开发计划。
会议开始时，各个成员或者小组向大家讲述上一阶段的目标以及完成的情况，并展示相关功能或者出具组内设计和讨论的结果;接着，“检查和修正开发方向”，这一步是最为重要的，因为这一步和用户的需求直接挂钩，影响着整个产品的质量好坏，也决定着项目的成败。这里就要提到SCRUM中PO和SM两个角色。
SM，即Scrum Master，这个角色需要1～2名成员，它们需要在开发过程中一直保持头脑清醒，牢牢把握住项目的需求以及需求变更，以能够在每次里程碑会议上正确地判断当前项目的前进方向是否符合当前的项目需求，如果设计有跑偏的迹象，则要及时对项目的理念提出修改建议。可以说SM决定着项目的“生命”。
PO，即Project Owner，其任务是在每次讨论中综合大家提出的BUG或者改进意见，在会后能够将更新修改的部分整合到项目中，并根据SM的指导意见整理出团队的下一阶段目标。PO的存在保证了项目的完成质量。在较小的项目开发中，PO和SM两个角色也可以由同一人担任。
虽然最终的开发方向由SM来指导，但是SCRUM是鼓励每个成员在会议中积极发表意见，最好能形成头脑风暴，经常能产生一些极有价值的观点，最终可以被记录到阶段目标中，并将其逐步实现。
就这样，通过每次里程碑的团队会议，在纠正项目方向的同时保证产品的功能质量，逐渐地完成软件的增量。
三、功能设计要求
在设计软件的功能上，强调User Story（用户场景）和Acceptance Criteria（接受条件）。
用户场景是指，用户为了完成某一项操作，而要使用的一系列功能集合。这里可能牵扯到一个角色转换的问题。开发人员并不容易从用户的角度去考虑使用的问题，尤其是在面对自己做的功能时，很难发现一些使用户体验差的问题。而尝试编写一个用户场景能够较容易地将开发员人带入到用户的角色中思考问题。假如要设计一款具有定位发布签到功能的软件，那么从用户角度设想一下，为了发布签到，用户可能经过如下步骤：
1.点击发布签到按钮;2.设置签到名称;3.设置签到开始时间;4.设置签到结束时间;5.设置签到中心点;6.设置签到范围;7.点击发布按钮。
那么以上七步就是一个完整的User Story。User Story能够很有效地让开发人员尽早地发现用例设计的不足;或者是在测试时能够感觉到一些设计上对用户不友好的地方。
在考虑软件功能设计时，还可以通过考虑其接收条件来确保功能的完整性。也就是考虑AC-Acceptance Criteria。AC是User Story的一部分。它要求开发者考虑在执行User Story之前用户所必须已做的一些操作。
参考文献：
[1] [美] Roger S. Pressman，等.软件工程：实践者的研究方法（第8版）[M].郑人杰，等，译.北京：机械工业出版社， 2016： 32， 53-54.
[2] 叶俊文.基于Scrum敏捷方法的标准研制项目管理优化研究[D]. 广州： 华南理工大学， 2018.