前言
作者所在的公司在项目开发的过程中采用着当下互联网公司中流行的小步快跑开发策略，特别借鉴了敏捷开发中的迭代递增思想来指导项目的开发。我们经过对相关敏捷开发方法的调查研究，最终采用了Scrum敏捷开发方法来管理项目。敏捷开发思想和相关方法的应用降低了项目的风险，极大地提升了项目团队对需求变更的响应速度和处理能力，每个迭代周期的版本发布都是对团队成员对激励，让整个团队对项目的信心越来越强。今天作者和大家聊聊Scrum敏捷开发方法以及它的实践。
敏捷开发原则
《敏捷宣言》中发布了12条敏捷原则和相关的敏捷开发价值观，用来指导软件开发过程。其中我们在项目中主要遵循的两条关键原则是：可工作的软件优于面面俱到的文档；对需求变化的响应优于对计划的遵循。
其中，可工作的软件系统优于面面俱到的文档这一原则是强调通过频繁持续地提供可供用户使用的软件系统来提升用户和开发团队对软件系统的信心，能够更及时地获取到用户和市场的反馈，调整后续的开发计划和需求的优先级。用户最终需要的是一个满足需求的可工作的软件系统而不是面面俱到的文档，过多过复杂的文档会成为开发团队的负担，而且也没有人愿意去读。根据作者多年的软件项目开发和管理经验来看，这个观点是在当前的互联网环境下是十分适用的。当前的互联网应用迭代更新很快，市场的需求也在瞬息万变，在半年前还十分重要的需求，在半年后可能也已经不是一个优先级很高的需求了。而且，及早地发布可以使用的软件版本确实可以尽早地收集到用户的反馈，从而及时调整后续项目的开发方向。举例来讲，Instgram在最初的版本只是一个简单的根据地理位置进行打卡的工具。市场的反响不是很理想，同时发现用户对地理位置不是很在乎，反而对上传照片很感兴趣，后来就调整了开发的方向转做图片上传的软件。
对需求变化的响应优于对计划的遵循。敏捷开发承认开发过程中的不确定性，在开发的过程中需要通过不断规划，执行和调整来消除不确定性。如果一味地遵循一个庞大而复杂的计划，会使团队变得很被动，无力抵抗需求的变化，最终开发出的软件系统并不满足市场和用户的需求。作者对这一点深有体会，作者之前所在的公司是一家传统的商业智能分析公司，其BI产品在市场中占有很高的占有率。2013年，公司的高级管理层做出一个决定，要做一款软件，帮助人们享受智能生活，只要有一部智能机在手就可以满足人们所有的日常生活需要，其愿景有点儿类似今天的支付宝和微信。为此，公司做了一个长达一年的开发计划，投入了很多优秀的开发人员和软硬件资源，但是因为没能够及时获取到市场的反馈，投入市场的APP并没有得到市场的认可。
Scrum开发方法
通过对当前各种类型敏捷开发方法的分析和比较，以及结合我们公司的实际情况。我们最终选择了Scrum敏捷开发方法，Scrum敏捷开发方法流程如下图所示。
Scrum开发方法包含5种不同类型的会议，每一种会议都有它明确的目标。
1.Sprint计划会议
在每个迭代开发周期的开始阶段，Sprint计划会议被召开。通常来讲，整个团队成员最好都参加计划会议。计划会议的目的是制定出一份切实可行的待办需求列表，同时选择出一个最高优先级的需求，每个需求的开发周期最好在2周以内。产品经理可以给开发团队解释待办需求列表中的每一个需求。
2.每日站会
当一个迭代开发周期被启动之后，每天举行站会是十分必要的，该会议的持续时间要严格控制在15分钟之内。该会议上面每个人都要回答三个问题：
- 你昨天完成了哪些任务？
- 今天你的工作安排是什么？
- 是否有任何障碍影响了你的工作进度？
3.Sprint评审会议【可选】
每个迭代开发周期结束的时候，最好举行一个评审会议，这个会议的主要目标是向大家演示产品的功能，让大家了解到我们完成的产品是符合预期的。随着互联网应用的更新迭代速度越来越快，实际上现在每个迭代开发周期结束后都举行一次评审会议，已经变得不是十分必要了。
4.Sprint回顾会议
Sprint回顾会议，顾名思义，主要是帮助团队来总结每次迭代开发周期中有哪些地方做得好，哪些地方做得不好，未来有哪些需要改进的地方。
5.Backlog Refinement会议【需求细化会议】
在Sprint计划会议之前，实际上还有一个需求细化会议，其主要目标是对待办需求列表中的需求进行细化，让团队能够更好地理解需求细节以及需求的目标是什么。需求细化会议可以减少Sprint计划会议的持续时间，同时也给团队成员一些时间去思考需求的问题、意义和优先级。
实践与问题
在实践中，我们不能去生搬硬套Scrum开发方法的流程，而是要从自身的开发环境和需要出发制定适合自己团队的开发流程。
1.取得团队成员的认同
很多时候，你的团队成员可能并不会认同Scrum开发方法，他们可能会认为依照Scrum开发流程没什么好处，只是单纯地在浪费时间而已。因此，我们必须尽可能让团队成员理解这个开发流程和项目的目标。这样有助于将团队所有成员凝聚成一个整体，消除团队成员在方向和认知上面的冲突。
2.会议目标要明确
在每次会议之前我们都要有明确的会议目标，否则的话我们的会议很容易就变成漫无目的的闲聊。
3.面对陌生领域
有些待开发的需求会涉及到技术上的未知领域，开发团队不好对相关需求所需的时间和资源进行评估。我们会根据实际情况采用如下的解决方案。如果相关技术领域团队的人员比较充足，我们会拆分部分开发成员去调研相关技术领域的解决方案；如果相关技术领域团队人员不足，我们会首先调整待开发需求的选择，不再采用“高价值”优先的选择策略，而且采用避重就轻的策略选择技术难度较低的需求，从而给相关的技术团队留出相应的技术调研时间。如果，没有这样的需求可供选择，我们会单独安排一个小的周期专门用于相关技术调研。
4.团队成员缺席
在开发的过程中，难免会遇到团队成员请假的情况，从而影响整体的开发进度。这个时候，我们采用的做法是留出相应的冗余时间，我们给出15%的冗余时间用来应对部分团队成员因为不可预知的情况而缺席迭代开发任务的情况。
总结
Scrum开发的迭代增量思想非常适合当前的互联网项目开发，但是必须根据自身的情况进行相应修改。没有放之四海而皆准的开发流程，在任何的开发管理流程中都会需要突发情况，对于相应的突发情况，我们要做好相应的预案尽可能降低项目的风险。
标签：需求,Scrum,开发方法,开发,敏捷,团队 From： https://www.cnblogs.com/kaiblog/p/16984396.html