科技公司如何做敏捷开发？

软件开发是一项复杂的活动，敏捷开发也有自己的一种框架：Scrum。

Scrum是什么？

Scrum是基于敏捷思想的开发框架，用于迭代式增量软件开发过程。 它基于经验型流程控制理论，所以Scrum框架的坚信：

1.知识源于经验

2.决策基于已知的事物

3.透明性、检视、调整是经验型流程的三大支柱

4.采用迭代增量式的方法来优化可预测性和管理风险

如下是标准的Scrum标准流程示意图：

Scrum详细介绍

我们先来看下Scrum的三种角色：Product Owner、Scrum Master、Team。Product Owner负责产品需求管理、需求优先级定义、及产品验收等；Scrum Master作为团队Scrum流程的引导者；Team负责根据需求交付产品。这三个角色分别代表业务方、实施方、及项目流程管理方。

下面我就通过讲故事来描述，各个角色参与的活动，及在活动中产出物。

总工作量

Product Owner通过各种手段收集产品需求（产品愿景、市场分析、竞品分析、用户、管理层、干系人），然后把这些需求整理成story列表，并按优先级来排序。这个排过序的列表就是Product Backlog。Product Backlog定义产品的业务需求，供产品开发团队使用。

当影响产品发展方向的因素发生改变，则Product Backlog也要进行审视，新加、更改或者删除一些story。

本迭代工作量

Scrum每一个迭代叫Sprint，一个Sprint 1周到4周不等。在一个Sprint开始时，Team和Product Owner在Sprint Planning Meeting上，挑出本Sprint能完成的若干高优先级story。这些story组成Sprint Backlog。

迭代开发

团队开始开发Sprint Backlog里面的story，每天Daily Scrum Meeting（站会），商量开发中遇到问题，看团队其他人可以帮忙或分享自己开发过程中得到的知识。在开发过程中，如果有什么业务问题，需要及时和Product Owner进行确认，确保做出来的东西是正确的。

整个开发过程用物理墙可视化。

迭代成果演示

如果一切顺利，到Sprint结尾，团队基本开发完了所有Sprint Backlog里的story。Product Owner会和团队发起Sprint Review会议，团队会演示story、回顾这个Sprint的开发情况，展示Burn Up Chart，RAIDs等。

迭代反思

如果Product Owner对于story没有什么意见，那么本次Sprint就结束了。团队如果觉得该Sprint开发过程中，存在一些问题需要改进，就可以一起进行Sprint Retrospective，在会议上反思在这一迭代中哪些做的好，哪些做的不好，有什么建议，并且产出改善团队开发的行动，并且制定Owner，在下一Sprint进行执行。在我看来Retrospective是敏捷最迷人的地方，能保证团队持续改进，提高生产效率。

敏捷开发与传统瀑布模式有何区别

敏捷开发：

1.专人专职

2.TeamLeader把控项目进度

3.需求独立，业务尽量避免交叉

瀑布模式：

1.计划

2.需求

3.架构

4.细化架构

5.编码

6.测试

敏捷所追寻的是响应计划高于遵循计划。前期科技公司转敏捷会不太适应，敏捷开发没有固定的交付时间节点，只能在响应中不断确定需求中价值高的来优先处理。从每个迭代的看板中我们可以在迭代回顾会时候看燃尽图分析和总结，不断完善敏捷这套开发模式。

喜欢科技互联网趣事请关注小编，每天更新精彩不断！