“越来越多的人开始谈论敏捷开发，也许你所在的企业正在向敏捷转型，而你正在经历或者将要经历敏捷开发。当我们不知敏捷为何物的时候，如IBM，丰田等大型企业早已转型成功，所以敏捷再也不能被束之高阁 ”
提要：敏捷开发中两周或四周为一个迭代（2周-1个sprint）。迭代开始的第一天和最后一天为计划和总结时间，所有有效地工作时间为8天，即掐头去尾。一天为2分，每天工作8小时，一个迭代每人16分。
Sprint开始的第一天
两会：
1. Refine meeting
2. Plan meeting
会议成员：开发人员，系统设计人员，项目负责人，系统架构师，还有scrum master 。
1. Refine meeting
如果是项目刚开始立项，就从项目背景开始介绍，对项目要解决的问题，将要开发什么样的系统，系统有什么功能，第一个Sprint的工作范围是什么，MVP包括了那些具体功能。介绍完之后，系统架构师介绍系统的整体架构，以及用到的技术，各个成员负责的具体内容，如果开发人员没有疑问，就对自己未来8个工作日的工作量进行估算，并估分。
注意：这个环节开发人员一定要注意听，而且有不懂的，或者有不同的意见一定要提出来，任何埋在肚子的里的疑问，都会在开发中变成坑，不是坑自己，就是坑队友。每个人对自己的scope要清晰，如果觉得自己任务量太大，要提出来。（强化MVP的意义，最小可用的产品），每一个sprint结束，都要产生一个MVP。
2. Plan meeting
基于Refine meeting ，如果开发人员对需求或者未来两周的工作内容和范围有疑问，就让系统设计人员或者架构师进行答疑，之后进入plan环节，plan一共分为三个阶段，记为plan1，plan2，plan3，每个阶段15-20分钟，plan结束后，下示表格中的各项也都应该确定下来。
a. scope：对于前端而言要完成首页的UI，并且具备load数据的功能，而后端可能需要搭建好服务端，给前端提供完整的API和数据，sprint结束的时候，前后端要完成集成，整个项目要部署到对应的服务器上。
b. Break Down： 即userStory，完成scope需要多少工作量。一般userStory按照功能点来划分，每个userStory最小为1分，最大不要超过8分（一共8个工作日，每人16分），最好为2分或者3分，也就是一天或者一天半一个人可以完成的工作量。
c. Score：所有userStory的总分。
d. Velocity/load：velocity，即score的结果。velocity是一个定值比如一共5人，共80分，即为80(所有人正常上班的情况下，如果有一个人休了一天家，则velocity为78)。
e. Risk/Support： 完成MVP是否存在风险，风险是什么，通过什么方式，什么人可以减小。与什么人，或者什么机构有将强的依赖，是否需要某人或者某团队的支持。
f. Statement： 在plan3的时候，向老板（Production owner）commit一下自己两周以后需要交付的产品（MVP），以及未来两周自己有哪些userStory。把自己最终要交付什么样的产品以卡片的形式（如果有jira工具，则建立新卡）进行记录，以便在sprint结束的时候进行评测，大家的工作是否100%的完成。
以上6项内容进行完了之后，如前端，后端不同服务开发人员的代表站在最前面对项目组所有成员说明自己在这个sprint中的工作内容和最后的产出。
注意事项：
（1）velocity和load的关系
load>velocity，最终给老板commit的比80大（所有人正常出勤所有完成的userstory总分），这种情况下可能需要经过加班才能完成commit的所有内容。说明估分的时候大家很谨慎或者本身要做的东西比较多，敏捷开发提倡不加班，所以这对敏捷开发原则是一种破坏，所以这种情况下，项目可能会有失败的风险。
load=velocity，最终的commit刚好和80相等，这肯定会存在风险，因为未来两周，可能会有一个或多个人请假，或者公司有一些集体的会议等等，而在估分的过程中显然对这些情况没有做充分的考虑。
load< velocity，这是最理想的状态，为一些不确定因素提供了一些生长空间。
（2）对于风险的管理
风险一定要可控，如若不然就会置项目于险境。下图为风险管理坐标系。
Reject：拒绝，老板拒绝承认的风险，老板认为你有能力有办法承受并解决此问题，所以在老板看来这不是风险。
Accept：老板承认并接受这样的风险。
Owner： 此风险有完美的处理人选。
Migration：通过其他途径，其他的办法，可以规避或者转移此风险。
（3）关于commit
一定要记录在案，要不然在sprint结束的时候，大家早已忘记当初自己给老板commit了什么，最终给老板的MVP不是当初老板想要的样子。
（4）关于plan
plan环节需要开发人员自主进行userstory的拆分并且进行估分，这就要求每一位开发人员清楚的知道自己未来两周要做什么，实现每个功能要花费多少时间，如果在拆分userstory的过程中发现有些功能之间存在依赖，就要提前做好安排，不要在开发过程中发现A的某一功能没有做，B的另一个功能不能开始，这对人力是最大的浪费，而且会影响项目的进度。另外如果在plan中发现架构或者UI设计存在不合理的地方，一定要讲出来，发现问题越早对项目成功率越高。
（5）关于Refine meeting
如果plan的三个阶段在1h-1.5h还没有结束，就说明Refine meeting存在严重的问题，要么是开发人员走马观花的听了，或者也认真的听了，心里面有疑问但是没有及时说出来，也有可能系统UI设计人员没有很清楚的表达系统要干什么，开发人员需要开发出怎么样的MVP。总之Refine meeting存在很大的问题。
Sprint中的每一天
三个问题：
1. 昨天干了什么？
2. 有没有被block?
3. 今天干什么？
userStory监测板
这是类似于Jira的一个board，每天早晨站会大家都聚在板子前面，在scrum master与会的情况下，开发人员逐一回答上述三个问题，并且更新板子中userStory的状态。
每天早晨固定的时间开始早会，时间15分钟左右，项目开发人员依次发言，阐述自己昨天做了什么，有没有遇到什么困难，今天要做什么。工作量按userstory评定，也可以说昨天完成了哪个userStory，或者某个userStory完成了多少，还剩多少。
如果有开发人员遇到了一些自己无法解决的问题，此时Scrum master要做好协调，帮开发人员扫清前方的障碍，保证项目的进度可以正常的推进。
早会要简短，每个人总结性的说明上述的三个问题，细节的问题不要在早会中说，早会结束可以找相关人详细的沟通。
特别提示：当sprint进行到1/2的时候需要再开一次Refine meeting，确定开发人员的进度是否正常，此时如果开发人员觉得自己无法在sprint结束的时候完成自己的工作，就要立马说出来。开发人员将自己剩余的userstory进行梳理，排优先级，从优先级最低的userstory开始移除，直至可以完成为止（此时也可以看出userstory拆的小的好处了）。
Sprint的最后一天
两件事:
1. 展示成果
2. 总结此sprint， 确定action
展示成果，即Show case，前后端可以各派一个代表对这个sprint的工作成果进行展示，在项目演示的过程中，任何人都不要打断，讲解和演示完毕后，大家可以提出对项目改进的意见，或者对当前成果不满的地方，在后续的开发中进行完善和改进。
sprint总结大会，主要对两方面进行总结，good和improve，即好的和需要提高的。每个人都要发言，scrum master对所有人的意见进行统计，最后经过大家投票选出2-3条最需要提高的建议，作为下一个Sprint首先要执行的action。
sprint end
后记：
1.每个sprint结束的时候，开发成果都是一个MVP。
2.在plan meeting的时候，要将每个人工作之间的依赖性降到最低，绝对不能再开发过程发现互相等的现象。
3.敏捷开发中，开发人员互相之间需要尽量多的交流合作，对同一问题的理解，或者对整个项目的理解一定要统一，否则最后集成会出很大的问题。
4.在项目开发中如果发现项目可能延期，此时最不正确的做法就是往项目组增加人手。新的成员，需要花费一些时间了解项目，在一知半解的情况下进入开发，可能会对项目产生严重的破坏。此时应该想想二八原则，只要保证20%的核心系统能够完成即可。
5.如果项目开发中，要用多许多新的技术，而开发人员不具备此番能力，此时要为他们的学习预留一定的时间。
6.敏捷开发消除了层级，所有人都是平等的，所以每个人都要有主人翁意识，而这种责任感需要长时间的培养，不能一蹴而就。
7.让团队收获更多成功的喜悦和成就感，以及荣誉感。
8.发现问题的第一反应是寻求如何解决问题的办法，而不是翻邮件，翻笔记，追查到底是谁的问题。当然对于错误源头的责任人一定要找到，帮助他发现问题，并从问题中得到提高，这对于个人和整个团队来说才是最重要的。
9.敏捷是为了更加适应变化，但并不意味着朝令夕改。频繁的改动，项目注定失败。
10.每个人对自己承诺的东西一定要保质保量的完成，如果经常延期，对自己的自信和团队的发展会产生破坏。所以这就要求我们在plan meeting的时候一定要量力而行。
11.最后要提一下的是敏捷团队中不可或缺的重要角色，Scrum master，作为团队的核心，他参与了项目开发的整个流程，对项目的进度进行把控，对开发人员的遇到的问题由他进行协调，对MVP的成功和所有会议的成功，以及团队建设的成功起着至关重要的作用，是团队的灵魂人物。
