1 头脑风暴
流程如下
1） 确定议题（由发起人在头脑风暴前确定，大家提前做好准备），确定风暴具体时间
2） 选举主持人
2） 独立思考3分钟（让大家有时间准备一下发言）
3） 主持人主持，每个与会者轮流发言（发言时间不限）。记录员记录每个人的发言
4）由主持人主持并总结每个人的发言，并跟每个人确认是否总结的合适，不合适要反馈修改
4） 进入自由讨论过程，整个过程不得超过60分钟
5） 最后主持人总结结论
可以以头脑风暴的形式产生User Story列表，团队对用户故事进行拆解和估算，形成最终的Product Backlog （建议：客户代表参与，这里的客户代表是指能代表客户的任何人）
表一 Product Backlog示例
编号 标题 描述(User Story) 优先级 Story Point
010100 定位对话 作为一个用户，我希望通过时间、角色、主题等来筛选我要的对话 1 9
由于团队初试Scrum，所有用户故事的拆解和估算由整个团队共同讨论产生。Backlog中的每个User Story必须控制在一个Sprint内可以完成，否则需要进行拆解。
注1：本次以演示Sprint计划会的形式对“User Story列表”进行Story Point的估算。建议在确定“User Story列表”后，大家回去思考一下，专门开一个拆解会，不要与Sprint计划会混淆，因为Sprint计划会是在“User Story列表”估算后得到了完整的Product Backlog后进行的。
注2：User Story优先级划分，四象限法，纵轴是用户需求，横轴是技术实现的难度，优先级最高区域在第二象限的 User Story（用户最需要且技术实际难度最低），优先级最低区域在第四象限的 User Story（用户需求最小且技术实现难度最大）。
2 立项会
2.1 市场价值
2.2 展示Product Backlog
2.3 确定项目组（PO、SM、Scrum Team、观察者）
PO：
SM:
Scrum Team:
观察者：
特别观察者：
2.4 预算投入
2.5 启动计划书
2.6 审批（审批结果：修改、执行或者驳回）
注：项目组各角色的职责
PO：产品负责人，代表公司和客户的利益，确保交互的产品是满足客户价值的产品。负责创建和维护Product Backlog，管理商业价值。计划产品的发布时间，对每次Sprint的结果进行评审和验收。跟踪团队进展情况。
SM：Scrum Master的角色是教练和服务者。负责Scrum敏捷开发的四个会议的主持。规则的维护者。障碍清除者，负责清除迭代中出现的各种障碍，帮助团队成员解决困难，维护障碍列表。促进过程改进，维护改进列表。
观察者：对整个过程，从产品立项到项目结束的过程的学习，不同角色的人有所偏向，如产品规划部的人偏向PO的工作的学习。
特别观察者：负责整个敏捷过程的监督，规则的草拟者和完善者（最终方案由团队或者管理层通过后具体实施），确保团队按照敏捷的思想进行管理及日常开发。
Scrum团队：Scrum的中心角色，负责开发出可交付的产品。包括开发，测试，文档，UI等产品交付的所有角色。终结目标是实行自组织，自管理。参与Sprint backlog的创建，领取任务，按承诺完成任务，及时向SM汇报障碍，每天更新任务的状态（未开发、进行中、阻塞、完成），配合团队清除障碍。保证整个迭代能够顺利完成。
3 敏捷开发流程（初稿，待细化和修正）
3.1 Sprint计划会
主持人：Scrum Master
与会者：全体项目组成员，包括PO、SM、Scrum Team，其他相关人员（如客户代表，在分解用户故事的时候，可以给出更具体的解释）
时长：控制在一个工作日内。
目的：确认迭代目标
内容：从Product Backlog中选取本次迭代的Sprint Backlog，将Sprint Backlog中的用户故事分解成任务列表，对每个任务估算时间，精确到小时，每个任务最长不超过8小时，否则需要拆解。Scrum Team成员根据自己的兴趣和特长领任务。SM确保每个任务都有人领。
3.2 每日站立会
主持人：Scrum Master
与会者：SM、Scrum Team，其他感兴趣的人（只允许SM和Scrum Team发言）
时长：15分钟内。（必须控制在15分钟内，站立的原因也在此，时间过长会导致成员疲惫，影响工作）
目的：让团队每一个成员清楚地知道团队整体进度，离目标的距离。
内容：每天同一时间开（一般为早上工作开始时间），每个人轮流汇报三件事：昨天的承诺完成的怎么样？今天承诺完成什么？影响承诺完成的困难是什么？会议不能讨论问题如何解决，SM记录每个人的困难，在会后组织相应的人讨论解决，清除障碍。
3.3 Sprint评审会
主持人：Scrum Master
与会者：全体项目组成员，包括PO、SM、Scrum Team，其他感兴趣的人。
时长：最长4小时
目的：演示成果，增加成员的成就感。确保成果与预期一致，收集反馈。
内容：SM介绍迭代的总体情况，目标和实际的结果，差距是什么，差距原因是什么。Scrum Team简要介绍所涉及的技术问题（如架构及其变更），演示已实现的功能。SM推动自由讨论，集思广益。最后，PO根据评审结果可能采取如下行动：更新Product Backlog（如没有按计划实现的功能，产生的新想法），重新设定优先级；决定是否将迭代发布成一个新版本；
3.4 Sprint回顾会
主持人：Scrum Master
与会者：SM、Scrum Team，其他感兴趣的人（如PO）。
时长：最长4小时
目的：评价迭代，总结经验教训，促进下一轮迭代的改进。
内容：SM总结本次迭代，重要的事情和决策，预期的和实际情况的差距，及原因。每个成员陈述迭代中的优缺点，SM进行记录。对重要的问题计划解决的措施。
注意：
1）用户故事才是开发的目标，而不是单个任务，故事全部完成才算达成目标。
2）评估时间（每个人给出一个时间，当不知道怎么评估时，可由最熟悉的人先发言，给出一个时间，并阐述原因，其他人据此补充，最后统一大家的评估，如果发生分歧时，取协商一致后的时间，如果不能达成一致，取较大值）
3）照明弹，当遇到没接触过的领域时，先安排时间调研，调研后再做决定。
附录：
记录员需要记录的点：
1.头脑风暴的过程，重点在于观点和观点的形成过程
2.user story列表
3.拆解和估算user story列表形成Product backlog的过程。包括优先级的估算以及Story Point的估算。
4.Story point，需要详细记录每个人对于point 的建议，以及点数估算，及最终大家达成一致的估算point
5.形成并记录 product backlog，backlog由story构成的，需要排列优先级，po是backlog的管理者，日常中要记录backlog的进度并及时跟整个团队汇报。Product backlog中的内容要逐个分析，挑选出本次迭代最终需要的sprint backlog
6.由sm主导将sprint backlog分发为task，task的时间粒度不能大于一天，精确到小时。Task要分发到人，记录员要根据list的每天实现情况，追踪和发现问题
7.经过几次的task执行和评估，逐渐形成一种标准，及按照平均数来估算相似任务需要多长时间，久而久之能够形成直接对product backlog的评估
8.每次迭代的情况，主要是针对燃尽图、估算的情况来整个复盘哪里出了问题，为复盘会提供支持，推动大家的分解和评估能力日趋提高，也推动团队能够有效能成长，及用相同的时间完成更多的points，这些points是按照标准确定下来的，所以会出现之后每个月完成更多points的情况，反应成长性
网友评论