标签：
scrum简介：Scrum是一个敏捷开发框架，是一个增量的、迭代的开发过程。在这个框架中，整个开发周期包括若干个小的跌代周期，每个小的的跌代周期称为一个Sprint，每个Sprint的建议长度2到4周。
在Scrum中，使用产品Backlog来管理产品或项目的需求，产品backlog是一个按照商业价值排序的需求列表，列表条目的体现形式通常为用户故事。Scrum的开发团队总是先开发的是对客户具有较高价值的需求。
在每个Sprint中，Scrum开发团队从产品Backlog中挑选最有价值的需求进行开发。 Sprint中挑选的需求经过Sprint计划会议上的分析、讨论和估算得到一个Sprint的任务列表，我们称它为Sprint backlog 。在每个迭代结束时，Scrum团队将交付潜在可交付的产品增量。
Sprint backlog是大概4周的时间，其中包括2天的sprint 计划会议,2.5周的开发，每日例会穿插在开发时间里，1周的测试改bug，1天的sprint评审会议和sprint回顾会议。
在开sprint 计划会议前，产品经理必须所要实现的产品需求（产品Backlog）以用户故事的形式确定下来，并画好原型图，UI应该要出设计稿（在sprint 计划会议前出设计稿很重要，因为设计对估算时间影响非常大）。产品经理同时确定各个产品需求的优先级。
开sprint 计划会议期间（一般是2天），开发团队的成员不应该做任何的开发工作，把全部精力都放在把产品需求变为一个个开发任务，并对开发任务估算时间。
估算时间有几点注意：
1. 对于需要使用的新技术，要估算学习和调研的时间。
2. 根据统计，每个程序员每天的有效工作时间是5个小时左右，其他时间都被沟通，喝水，休息，上洗手间等占据，所以如果某个任务估算超过5个小时，那就代表了这个任务完成需要超过一天的时间。
3. 对于开发任务，估算尽可能的细，一般来说，每个任务的估算不应该超过5个小时，如果超过5个小时，就应该再把这个任务细分。只有尽可能细的估算任务，总的时间是大概精确地，因为估算时间是一个正态分布，有的任务估算的时间偏大了，有的时间任务估算的时间偏小了，估算越细，总体下来估算还是准确了。
最后，根据产品经理的优先级和开发人员的估算时间，确定最终的开发任务和优先级，即完成Sprint backlog。
在每个Sprint backlog，后台和app的交互都是通过api，所以由后台先写好相关的api并编写假数据，先让app端可以顺利开展工作。
先编写api和假数据，有两个好处：
1. 能对整个开发计划有个总体的规范。
2. 相当于是TDD（测试驱动开发）。
遇到问题的时候，必须要及时找相关的人员沟通。但这样有个问题，如果开发人员正在开发，被打扰可能会被决定很不爽，为了保证沟通的效果，可以：
1. 如果真的不是非常紧急，可以等相关的人员休息的时候再沟通。
2. 解决一个问题，先梳理情绪，再梳理人际关系，最后才是问题本身。多微笑，别苦着脸，平时待人以善，说好话，存好事，做好事，沟通的时候只针对问题，不针对别人的不良情绪。
3. 可以试一下番茄工作法。但根据我们自身的实践经验，效果不理想。
在创业开发团队中，scrum master 一般是由技术总监担任的。团队外部的沟通，必须统一通过scrum master。即如果市场部，运营部对开发团队有任何要求，必须要经scrum master同意后由scrum master传递进开发团队内部。团队内部的沟通，由团队成员自己解决，如果有重大的决策，必须经scrum master同意。通过scrum master遮蔽外部对开发团队的影响。
在一个Sprint backlog中，需求不能变更，UI确定后原则上只能做小修改。
标签：
原文地址：http://www.cnblogs.com/dgj1314/p/5326325.html
