本文将介绍Scrum的开发流程(Scrum Development Process)
PO将用户故事制作成用户需求列表，并挑选出最优先项
Sprint Planning Metting，整个团队讨论需求，估算一个Sprint开发时间(1~3周)的需求量，制作成tasks。
tasks确定后，团队开始进入开发状态，在这期间，所有的tasks是No changes，不可修改的。(敏捷开发不是对付需求的变动吗？为什么需求不做变动？团队已经把这个使用者的需求制作成tasks，只要变成tasks就开工去做，所以做的时候是明确的，如果需求变来变去，做的就是白工，一直做返工的动作，所以一个Spring 期间是No Change，这一点整个团队和Scrum Master严格遵守)
站立会议：工作透明化，方便了解Spirnt进度，对团队成员中遇到的麻烦进行增派人手，对已完成的其工作的成员可以加入到其他工作进行学习，比如开发者完成模块开发或可配合测试进行工作，共同学习，提高整体开发团队的能力，反之也一样。
产品功能细化：是讨论下一个Spint周期，我们要做的需求的新增、删除、修改，而不是本次Sprint要做的事
评审会(review meeting)：也就是把Sprint的结果(可发布产品)做一个增量的demo展示给客户，客户借此回馈
反思会：把这次Sprint做得好的地方继承下来，下一次继续做得更好，把不好的做修正
Scrum会比瀑布模型聪明很多吗？并没有。瀑布是预期一次就可以做完，Scrum分成好几次，根据项目复杂度调整它的多广。通过四个会议来强调沟通的重要性。会议最重要的就是沟通和会议记录做成结果。
在瀑布模式中，每个人都有自己的角色，在不同的时间点分配任务，但是在Scrum不这么认为，所有的角色应该是全职能的，只有三种角色，PO代表客户，团队有疑问就去问PO，它管理所有的需求。在专案开发中，PO不断调整他的需求，但需求制作成Tasks时进入Sprint周期里面，需求不做修改。这时候PO就调整下一个Sprint的需求，持续地排序，排序按照市场、对手、最有力，是一个舵手，决定产品开发的方向。再接下来是团队，全职能的团队，不去区分你是项目经理、设计师。Scrum Master通常不做coding，它是保证整个团队开发过程里面都能保证Scrum的规范，排除对团队开发中的任何障碍，减少团队开发中的打断。
产品待办PB:客户需求以使用者故事的形式撰写、展现。
SP：决定了团队这个Sprint要做多少需求、任务，代办这个Sprint的产能。
增量：一个冲刺Sprint所产出的具体成果，展现给客户欣赏，并取得回馈，，是一个潜在可交付的增量，因为还做过用户测试和比较完成的整合性测试。
Product Backlog(需求)：需求庞大由PO负责，他代表客户，主管所有需求，持续地做需求的增删改查，其他人仅可建议，但是只有他有权限抉择。
Sprint Planning meeting(工作解析)：一个Sprint的周期在两个星期，会给四个小时的工作解析时间。在该时间会分成两个判断，第一个是PO对他的需求做明确的说明，团队针对此提出意见。分析目的正确与否，有无提供足够的资料。第二部分是团队拆解，由团队做时间预估。传统是由系统分析对客户的需求进行收集，设计、向下分配任务，而Scrum则是让PO说他的需求，团队进行提问，让正在做事的人把问题弄清楚。是不是这样做来达到目的。
Scrum很鼓励成员第二天通过daily Scrum来确定今天要做啥，团队每个人心里都有数要做什么事，但是谁每天都有机会去拿不同的工作，做不同的学习，让每个成员在Scrum sprint中得到成长。团队的共同成长就是最大的获益。
Scrum不是一个快速开发的方法，但是每次都能提前交卷的原因，就是团队不断增强的开发能力。
Daily Scrum通常讲三件事：昨天到现在，昨天我做了些什么，对团队有贡献的事，这个牵扯到工时，一天是工作8个小时呢？还是个小时，Scrum不鼓励加班，Scrum鼓励是对团队做了什么有贡献的事。第二件事是描述今天我准备做什么？隐含学习和成长，最后是昨天的工作里有无碰到困难，由团队成员共同解决。
Sprint包含开发测试除错，解决主要bug，简单的留给下一个Sprint，需要2个小时以上的bug需要计算工时，这可以更好地在burndownchart上的tasks能够真正反映出它的效果，当遇到难度高的时候，burndownchart本来就应该不会顺畅，然后团队公同解决的时候，如何把tasks做的更顺畅就会掉下来。
增量：客户的期待，会给Sprint取一个名字，而不是取sprint1、sprint2，而是如何工作的sprint1，会有一个target，这个目的就是增量。
只看产物，传统的开发，所有的需求都需要做完。敏捷开发是将重要性进行排列，有些需求是可有可无，但客户觉得已经足够了，满足了他当下的需求，而市场上的价值跟这个时间点跟他的产出物配合得最好，他就可能拿这个产品进行产出，所以并不是把所有的需求都做完，通常来说，一般只有40%的功能被经常用到，大部分功能都是没有人去使用的。体现需求按优先排列的优点。
tasks都使用看板的方式，显现真正的工作流程
回顾
Scrum架构：3角色+4会议+3产物
每日站立会议：今天要做啥，昨天要做啥，碰到啥困难。这个是在冲刺Sprint里举行，我在冲刺里每天都学到东西，所以进度会快。
BurnDown chart：每日的站立会议后都需要使用burnDown chart显示。
Scrum三支柱：透明化，检验和调适性，后两者是团队成员利用会议来做检验和调试。
问题：
1加班有没有用？只有开始和结束是有用的。开始的时候是为了把问题搞得更清楚，直到后面怎么做；如果结束时是为了把产品做得更好。
消除浪费，增强学习，看板中明显地显示项目得开发是透明得，当你看得到，就知道如何消除浪费。
user story Mapping：用阶层的方式把需求做为一个分类。当你能倒过来把user story Mapping讲故事给客户听，“对你讲的故事就是我需要的”，跟用户做的方向的交流。团队看到所有的user story Mapping后