什么是Scrum敏捷开发
Scrum是敏捷开发的一种，是一种以人为本，迭代式增量软件开发的过程，以英式橄榄球争球队形（Scrum）为名，因此可以想象，整个团队是高效而富有激情的。以人为本，即Scrum开发特别强调沟通，要求团队所有人员都坐着一起工作，通过高效的沟通解决问题。
Scrum的模式和流程
标准的Scrum开发模式
以下是标准的Scrum开发模式：所有的需求都到达PO/PM这里，整理出Product backlog，每次的迭代开发（Sprint）都是PO/PM从Product backlog里挑出需要开发的部分需求，然后团队一起开planning meeting，确定出sprint backlog及交付日期。接下来利用2到4周的时间进行开发和测试，其中每天都要开站会（Scrum meeting），团队内部成员在这个会议上了解整个迭代的进展情况，最终交付后，团队一起开sprint review和retrospective会议，而这整个过程都有一个很关键的角色Scrum Master来把控和组织。
开发周期
Scrum开发一般建议为2-4周为一个周期，以两周为例，整个时间线大概如下，可以看到第一个迭代的结束和第二个迭代的开始是有重合部分的。
三三四原则
Scrum开发有一个“三三四”原则，即三个角色、三个产出物、四个会议：
三个角色：PO、Scrum Master、Dev Team
三个产出物：Product Backlog、Sprint Backlog、Potential Shippable Product Increment
Sprint Planning：需求评审会和迭代启动会，这个会议上，需要得出以下结论：
站会的目的有以下3个：
站会的时间，建议不超过15分钟，只描述状态和任务，不讨论技术细节，另外，每个人围绕以下3个话题来简单描述自己的进展：
Sprint Review：迭代评审会，此次会议的主要内容是相关利益者及团队成员展现本次迭代的功能增量，需要注意的是不展示未完成的功能，也不需要PPT，演示结束后记录好相关反馈。很多采用敏捷开的团队都不开Review会议，其实Review会议是有一定的好处和目的的：
“图片编辑功能“：不是一个好的User Story，首先颗粒度太大，其实大小不可评估，因此需要对这个需求做拆分，拆分成小的User Story；
”作为一个喜欢自拍，又希望自己可以拍出来比较白的用户，可以通过图片编辑的美白功能，使自己看起来白一点“：该Story是一个比较好的User Story，当然，思考这样思考，记录的时候，完全可以简单描述为”图片编辑增加美白功能“。
User Story的分解是一个技术活，对产品经理是有一定的要求的，当然，一切从用户角度出发，多思考用户场景，那么这个问题也就也就没有那么难了。
Product Backlog：User Story的集合，即产品需求池，这里面包含所有和该产品相关的需求，根据笔者经验，这些需求最好包含以下状态：need to check、pending、reject、planning、developing、released、wait to dev，这些状态基本包含了一个需求的所有可能的状态，对产品经理管理需求有非常大的帮助。
同时要在白板上画出燃尽图，燃尽图指示的是当前剩余的工作量，是一个跟踪项目进展非常好的指示器。燃尽图上一般有2条曲线，如下图的燃尽图，灰色的直线表示的是最优剩余工作量曲线，蓝色的表示实际的剩余工作量曲线，正常情况下，蓝色的线应该在灰色的线上下浮动，并在最后一天合到同一个点上。燃尽图可以在每天站会的时候由PO更新状态。
关于看板和燃尽图，有以下一些需要注意的点：
敏捷带来的价值
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/202036.html原文链接：https://javaforall.net
