互联网敏捷开发-scrum实践

互联网公司推崇敏捷开发快速迭代，敏捷开发的方法也有很多，主要包括极限编程（XP）、Scrum、水晶方法（Crystal Methods）、自适应软件开发（ASD）、特性驱动开发（FDD）、动态系统开发（DSDM）、轻量级RUP、测试驱动开发（TDD）等等。而在众多的敏捷开发方法中，尤以实施Scrum比较流行。所在公司目前采用的也是scrum敏捷开发方法，所以我将我的观察和感悟总结在这篇文章中。

scrum是什么？

Scrum起源于橄榄球运动的一个专业术语，表示“争球”的动作；在敏捷中，把一个开发流程的名字取名为Scrum，主要寓意在于提现整个团队的积极奋战的开发状态。是一个用于开发和维护复杂产品的框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发过程由若干个短的迭代周期组成，一个短的迭代周期称为一个Sprint，Sprint是短距离赛跑的意思，这里面指的是一次迭代，每个Sprint的长度是2到4周。

scrum的核心思想？

Scrum坚持如下敏捷开发原则：保持简单、接受变化、不断迭代、不断的反馈和改善、 协作和减少浪费 ， 其中有以下几个原则：

Get early Feedback：尽早获得反馈

2.Delivery Value：每个 Story 必须可以独立产生价值

3.Focus on one thing at a time：一次专注做一件事，并把它做好

4.Avoid Inventory：不留存货。完成一件事，再进行下一件，不要进行返工

5.Pay Tech Debt early：技术债要尽早偿还，因为「债」会产生利息，技术债也一样

6.Sustainable Pace：保持可持续发展的节奏。创造优秀的产品是一场马拉松，不是 110 米栏

Scrum的一些关键概念

3个角色：Scrum master、Product Owner和Team，这三个对等的角色形成scrum中平衡的关系，保证项目正常推进。

Scrum master：Scrum Master不是项目经理，但他要维护每个sprint的流程，确保每个sprint能够顺利的实施以及完成，并且负责主持召开sprint期间的每一个会议。Scum Master 的核心职责是发现 Scrum Team 的实践敏捷开发的问题，并牵头改善，包括是否按照符合认可的价值观的方式做事，促进团队自组织，组织 Sprint 回顾，例如：鼓励人人关心 Sprint 的风险，人人关心产品是否能够成功，大家坦诚交流等。

2.Product Owner：PO是管理产品backlog的责任人，够把握产品的方向，担负起产品短期以及中长期的规划与管理；能够根据战略要求，进行用户研究和产品功能规划，深度跟踪、分析、挖掘不断变化的需求。 当项目组成员完成某个需求后，是product owner进行功能测试，进行验收，他认可后才能认为某个需求完成了。

3.Team：是技术的责任人，他们负责实现这个系统，他们是自我管理的，不需要外部的管理者来管理他们。

3个文档：

Product Backlog：Product backlog 中列举了本项目应该实现的需求，需求采用了用户故事的方式进行描述，用户故事是一句简短的采用用户熟悉的术语表达的需求，是用户讲给开发人员的故事，Story 应该包括几个要素：1、用户角色；2、需要的功能；3、功能的目的；4、用户故事的验收标准，或者叫用户故事的测试要点

2.Sprint Backlog：Sprint Backlog就是任务列表，这个任务列表是根据优先级从Product Backlog中选取的，包含以下要素：

3.Burn down chart：翻译为燃尽图或燃烧图，很形象，是Scrum中展示项目进展的一个指示器。燃尽图可以每天画，表示完成某个迭代的进展趋势，也可以某次迭代结束的时候画，表示完成整个项目的进展趋势，此时横坐标就是迭代的顺序号：

scrum需要准备什么

Story ：这一列代表的是用户故事，用户故事是敏捷开发中的需求表达方式，每个用户故事代表了从产品的用户视角表达的一条用户需求。用户故事这一列放的是这个迭代需要完成的所有用户故事，这些故事加在一起就是这个迭代的目标。这些故事通常按照优先级从上到下排列。

在Scrum中，使用产品Backlog来管理产品的需求。产品backlog按照实现的优先级进行排序，以商业价值作为排序的主要原则。在Sprint中，Scrum团队从产品Backlog中挑选最高优先级的需求进行开发。挑选的需求在Sprint计划会议上经过讨论、分析和估算得到相应的任务列表，称它为Sprint backlog。当Scrum团队完成Sprint backlog列表中的所有任务时，本次Sprint结束，进入下一个Sprint迭代周期。

scrum的流程是什么样的？

产品负责人首先将需求按照优先级进行排列，产生一个Product Backlog。作用类似于传统开发中项目经理先确定需求文档。

有了ProductBacklog列表，我们需要通过Sprint Planning Meeting（Sprint计划会议） 来从中挑选出一个Story作为本次迭代完成的目标，这个目标的时间周期是1~4个星期，然后把这个Story进行细化，形成一个Sprint Backlog；

Sprint Backlog是开发人员的任务，每个成员根据SprintBacklog再细化成更小的任务（细到每个任务的工作量在2天内能完成）；

在开发人员完成计划会议上选出的Sprint Backlog过程中，需要进行 Daily Scrum Meeting（每日站立会议），每次会议控制在15分钟左右，每个人都必须发言，并且要向所有成员当面汇报你昨天完成了什么，并且向所有成员承诺你今天要完成什么，同时遇到不能解决的问题也可以提出，每个人回答完成后，要走到看板前更新自己的 Sprint burn down（Sprint燃尽图）；

scrum怎样进行风险控制?

用户 Story 尽量细分。每一个能单独产生价值、单独上线，且有相当工作量（大于 1 人天）的模块，都应该拆分为不同的 Story。

每个 Story 都应该有优先级。

每个 Sprint 评估时间时，要留出充分的测试时间。

4.每日站立会，如果燃尽图上出现风险（高于预期线半天），则 Scrum Master 应该考虑是否需要与 PM 一起重新评估优先级和排期

scrum的缺陷

1、如果pm就是scrum master，整个team就是在一个不平等的环境下，可能会造成团队任务推进不力的问题

2、快速发布实际上导致 Scrum 团队的抗风险能力弱于瀑布模型团队,因为一个人的离职或病假都可能对单一功能的进度造成影响,不利于短期频繁发布，这就需要在Sprint Plan Meeting 时重点确认是否有人员有休假或离职计划。

总结

scrum是一套完整的方法论，不仅阐释了项目的开发流程，而且是敏捷开发需要遵守的团队准则。一句话送给大家：No matter what you want to do, choose what is good for your team.（无论你选择做什么，选择对你的团队有利的事）

最后祝大家项目需求都能按时上线，从不延期.

以上内容来自于“高三零班” 明明同学

如果你周围也有产品经理，这篇文章应该对他会有帮助