本文详细介绍了Scrum敏捷开发的方法论，包括Scrum的关键角色、流程步骤、关键会议等内容。Scrum强调增量、迭代开发，注重团队沟通和自我组织能力。
Scrum开发的步骤及准备
Scrum敏捷开发的关键字就是增量、迭代，他更重视项目团队之间的现场沟通，不向传统瀑布式开发那样需要万事具备，才开始开发，Scrum在大方向和小故事点确认好了后，团队就可以开动了。
Scrum的团队一般都不大，一Scrum团队人数一般在10人左右，主要角色有：
product owner（产品负责人）、scrum master（团队负责人）、scrum team（开发/测试团队）。
Product owner :需求方，提出需求，能对功能流程、业务流程拍板的人。
Scrum master :团队负责人，负责解决团队各类问题，领导项目的人。
Scrum team :项目执行人员，一般指项目具体开发和测试的人员。
Scrum开发的步骤：
步骤一：头脑风暴
如果product owner（产品负责人）对产品需求非常清楚，就可以省略这个步骤；开发遵守“先紧后松”原则，必须先把需求了解清楚；这里product owner（产品负责人）可以召集技术团队/用户群体对其需求进行公开征求意见，最后输出一个产品建议表。
步骤二：product owner（产品负责人）对产品建议表进行筛选并做减法，提炼最核心的需求。
在确定了需求后，由scrum master（产品负责人）进行输出prd(product requirement document),这里就和传统的瀑布模式一样了，该有的文档都必须有，必须由scrum master（团队负责人）和product owner（产品负责人）确定好需求，包括业务逻辑、功能流程等。
步骤三：工作量估算
把任务量化，包括原型、logo设计、ui设计、前端开发等，尽量把每个工作分解到最小任务量，最小任务量标准为工作小时不能超过16小时，然后估算总体项目时间。
把每个任务都贴在白板上面，白板上分三部分：
（1）to do-待完成（2）in progress-进展中（3）done-完成
步骤四：Sprint
经过讨论后，已经把任务量化到需要具体完成的时间，然后把n个任务按照开发的重要度，组合成n个sprint（冲刺），每次执行一个sprint。
Sprint：每个sprint都是独立的，一般先做主要功能，再到次要功能，再到小功能，最后的sprint一般是修复bugs。）
Sprint：因为任务都被量化了，每天工作了多少小时，完成了多少任务量，通过每天的例会scrum master就非常清楚，并且在time burn down chart（时间燃尽表）进行表示，我们就可以直观看到任务的进度了，而且是具体到多少小时。
Sprint：在burn down chart里面，不管任务是否按时完成都必须记录。
Bugs：每个sprint都必须测试，尽量大家一起测试，如果太多bugs就开一个sprint来修复bugs。
站会：每天要做的是，要开standing meeting，因为大家的时间都是非常紧张的，一般是站着开的，时间不要长，10分钟左右为宜。会议必问开发团队每个人三个问题：（1）今天做了什么（2）明天打算做什么（3）遇到什么困难
scrum master要解决开发团队的困难，让项目快速进展下去；每周一次周会，product owner最好在场；每个月一次月会，product owner最好在场，指出产品开发是否在product owner期待范围内；如此重复下去，直到开发完成。
（时间燃尽表：scrum的精华，通过该表格可以可视化任务的时间进度，从图中可以看到，day1是整个任务的总共时间，每天按照任务完成度更新剩余时间，或者增加时间（例如发现一个技术难点、团队成员请假等要增加开发时间））。
步骤五：评估
product owner和其团队/用户会对产品进行评估，可能还会有各种不满意的地方，不过product owner要求需要改的地方还是要改的，建立一个bugs sprint，把产品做到product owner最想要为止。
补充说明
SCRUM也有其自身的先天缺点，就是对团队要求高，团队成员有能力且相互信任度高，不会相互推卸责任。
新团队使用该方法，起初会有各种问题，需要多多磨合。
参考：https://blog.youkuaiyun.com/jamenew/article/details/54864440
====================================================
Team——开发人员、测试人员、美工设计、DBA等全职能性团队
Product Owner——产品负责人、产品经理、运营人员
User——最终用户、运营人员、系统使用人员
Manager——管理层、投资人
Customer——客户、系统使用人员、运营人员
每日立会（Daily Standup Meeting）——建议下班前开始
会议目的
•团队在会议中作计划，协调其每日活动，还可以报告和讨论遇到的障碍。
•任务板能够帮助团队聚焦于每日活动之上，要在这个时候更新任务板和燃尽图。
构成部分
•任务板、即时贴、马克笔
•提示：ScrumMaster 不要站在团队前面或是任务板旁边，不要营造类似于师生教学的气氛。
基本要求
•成员：团队、Scrum Master
•无法出席的团队成员要由同伴代表。
•持续时间/举办地点：每天15分钟，同样时间，同样地点。
•提示：团队成员在聆听他人发言时，都应该想这个问题：“我该怎么帮他做得更快？”
会议输出
•团队彼此明确知道各自的工作，最新的工作进度图。
•得到最新的“障碍 Backlog”
•得到最新的“Sprint Backlog”
会议过程
•团队聚在故事板旁边，可以围成环形。
•从左边第一个开始，向团队伙伴说明他到现在完成的工作。
•然后该成员将任务板上的任务放到正确的列中。
•如果可以的话，该成员可以选取新的任务，交将其放入“进行中工作”列。
•如果该成员遇到问题或障碍，就要将其报告给 Scrum Master。
•每个团队成员重复步骤2到步骤5。
每个人三个问题：
•上次会议时的任务哪些已经完成？：把任务从“正在处理”状态转为“已完成”状态。——今天完成了什么？
•下次会议之前，你计划完成什么任务？：如果任务状态为“待处理”，转为“正在处理”状态。如果任务不在 Sprint Backlog 上，则添加这个任务。如果任务不能在一天成，把这任务细分成多个任务。如果任务可以在一天内完成，把任务状态设为“正在处理”。如果任务状态已经是“正在 处理”，询问是否存在阻碍任务完成得问题。——明天做什么？
•有什么问题阻碍了你的开发？：如果有阻碍你的开发进度的问题，把该障碍加入到障碍 Backlog中。——今天遇到了什么问题？
注意事项
•不要迟到
•不要超出限制时间
•不要讨论技术问题
•不要转变会议话题
•不要在没有准备的情况下参加
•Scrum Master 不要替团队成员移动任务卡片，不要替团队更新燃尽图。
•Scrum Master 不要提出问题，团队成员不要向 Scrum Master 或管理层人员报告。
•如果不能出席会议，需要通知团队，并找一名代表参加。
任务板
•任务板只能由团队维护，使用不同颜色的“即时贴”来区分开发人员，或者在“即时贴”写上接受任务的姓名。
•尽量使用大白板，也可以使用软件。
任务板有4列：
•选择好的 Product Backlog：按照优先级，将团队在当前 Sprint 中要着手的 Product Backlog 条目或是故事放在该列中。
•待完成的任务：要完成一个故事，你得完成一些任务。在 Sprint 规划会议中，或是在进行当前 Sprint 中，收集所有特定 Backlog 条目需要完成的新任务，并将它们放入该列。
•进行中的工作：当团队成员开始某个任务后，他会将该任务对应的卡片放到“进行中的工作”列中。从上个每日 Scrum 例会开始，没有完成的任务都会放在该列中，并在上面做标记（通常是个红点）。如果某个任务在“待完成任务”列中所处时间超过一天，就尽量将该任务分为更小 的部分，然后把新任务放到那一列，移除其所属大任务卡片。如果一个新任务因为某个障碍无法完成，就会得到一个红点标记，Scrum Master 就会记下一个障碍。
•完成：当一个任务卡完成后，完成此任务的成员将其放入“完成”列，并开始选取下一张任务卡
燃尽图
•团队每天更新燃尽图。
•如果燃尽图一直是上升状态，或当 Sprint 进行一段时间之后，Sprint 燃尽图上的Y值仍然与 Sprint 刚开始时相差无几，就说明这个 Sprint 中的 Story 过多，要拿掉一些 Story 以保证这个 Sprint 能顺利完成。 如果Sprint 燃尽图下降得很快，例如 Sprint 刚过半时Y值已经接近0了，则说明这个 Sprint 分配的任务太少，还要多加一些任务进来。在 Sprint 计划会议上，如果团队对即将要做的任务理解和认识不充分，就很可能导致这两种情况的出现。（锻炼团队人员的自我估算时间）
•燃尽图要便于团队更新，没必要让它看起来很炫，也不要过于复杂，难以维护。
Release 燃尽图：记录整个Scurm项目的进度，它的横轴表示这个项目的所有Sprint， 纵轴表示各个Sprint开始前，尚未完成的工作，它的单位可以是个（Story 的数量），人天等。
估算会议
•要做好战略规划，你需要知道 Backlog 中各项的大小，这是版本规划的必要输入；如果想知道团队在一个 Sprint 中能够完成多少工作，这个数据也是必须的。
•团队成员可以从会议中知道项目接下来的阶段会发生哪些事情。
基本要求
•只有团队才能作估算，Product Owner（产品负责人）需要在场，以帮助判定某些用户故事能否拆分为更小的故事。
构成部分：
•Product Owner 根据业务价值排定 Product Backlog 各项顺序。
•需要参加的人员：Team、Product Owner、User、Scrum Master
注意事项：
•不要估算工作量大小——只有团队能这么做。
•Product Owner 不参与估算。
会议过程
•Prodcut Owner 展示她希望得到估算的 Product Backlog 条目。
•团队使用规划扑克来估算 Backlog 条目。
•如果某个 Backlog 条目过大，需要放到下一个或是后续的 Sprint 中，团队就会将该大 Backlog 条目划分为较小的几个 Backlog 条目，并对新的 Backlog 条目使用规划扑克进行估算。
•重新估算 Backlog 中当前没有完成、但是可能会在接下来三个 Sprint 中要完成的条目。
持续时间：该会议时间限制为不超过90分钟。如果 Sprint 持续时间长于一周，那么每个 Sprint 举行两次估算会议比较合适。
会议输出
•经过估算的 Product Backlog。
•更小的 Backlog 条目。
扑克牌估算
•每个人各自估算后独立出暗牌，听口令一起开牌。
•数值最大者与最小者PK，其他人旁听也可参考。
•讨论结束后重新出牌和开牌。
•重复上述过程，直到结果比较接近。
常见问题
1、为什么任务要分给组而不是个人？
答：因为怕出错了牌又说不出所以然，这样即使日后他不做这个功能，也对这个功能很了解。
2、为什么不让最后领任务的人自己估算？
答：因为他很可能因为不知道某代码可用、不知道某软件不行....而选择了错误的实现方法。
3、为什么不让师傅估算大家采纳，他不是最厉害吗？
答：师傅的想法常常是徒弟们理解不了的，比如为什么不留在女儿国而偏偏去西天取经之类的，共同估算就是让大家在思考中对照自己的实现方法和师傅差异的过程。
扫一扫
42
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
