团队一直在推行敏捷的项目开发，在不同的场合中多次提到了目前行业盛行的一些方法，我也是囫囵吞枣般的快速略过，不求甚解。终于前段时间拜读了一些敏捷管理方法学大师的著作，再次对这些广为运用的方法，如Scru、XP、Evo、UP等进行系统性的学习，记录下一些学习笔记，以供今后回顾。
首先，Scrum作为一种敏捷方法学众多方法之一，它本身是具有独特的实践、理念和价值观。它强调一套项目管理的价值和实践、而并不关注需求和实现等具体的环节，它在理念中强调的是经验型过程而并非规定型过程。即是说，Scrum方法认为我们所有的软件开发过程都是一种创新型的工作，在工作过程中，蕴含有巨大的复杂性和不可预见性，往往需要依赖开发人员的个人能力和经验来解决，而不是传统行业流水线式的既定工作模式。Scrum虽然对正规性要求不高，但是并不是说Scrum方法排斥文档，Scrum更注重实效，避免不必要的格式化的说明。
Scrum的一个标识性实践：迭代周期通常是30天。（Scrum中用sprint代表迭代，而不是我们常用的iterative），但是这句话似乎被很多人误解，其实Scrum只是觉得30天是一个比较合适的迭代周期，而并不是强制要求采用Scrum方法就必须30天。
在Scrum项目生命周期的四个阶段，计划、过渡、开发和发布，引入了四种角色，他们分别是客户（产品所有人）、Scrum主管、Scrum团队，其他属于这个项目而不在前面范围的人员均属于其他相关方。
客户（产品所有人）：在计划阶段需要负责创建产品需求列表，确定其中的优先级，以及确认下一次sprint的范围及目标，在sprint后期需要review Scrum团队所交付的功能组件；
Scrum主管：需要确保并贯彻Scrum的价值和实践，扫除开发项目过程中的所有障碍；
Scrum团队：充分自主的利用自身的经验完成当次sprint中所列出的工作；
其他方：在迭代过程中，其他人只能观望，不能干预。
在这个角色描述中，也包含了Scrum的另外一些关键性的实践：
Scrum团队应该是一支自我组织和自我管理的团队，管理者需要对团队充分的信任。团队成员所负责的迭代的清单任务，应该是由团队成员自我认领的，而并非分配，因为这样可以更大程度调动主动性和创造性；
一次迭代任务一旦明确，就不能增加额外的工作任务，其他人对其的功能需求只能放到下次迭代中，非项目成员不得对项目干预；
每次迭代后，Scrum主管都需要向客户做成功演示。
Scrum对stand meeting有更为严格的要求，并且站立会议也是作为Scrum的一个核心实践被记载的，它要求每天、在相同的时间、地点举行，会议上的每个团员都需要按规定回答五个问题：
1、自从上次会议你都做了什么？
2、从现在开始到下次会议，你将要做什么？
3、什么阻碍了任务完成？
4、有没有新的，没有在原功能列表中遗漏的功能需要添加？
5、相对于其他团队成员，是否学到了或做出了新的决定？
为了更有效的执行Scrum的站立会议，Scrum主管应该控制到发言的时间（2~3分钟/人）、人员（团队成员发言，其他人只能听）、内容（不能深入探讨，如工作有阻碍，需要明确记录下来）。Scrum站立会议的优点在于，它是有共同语言和开发内容的一群人的交流，沟通顺畅；团队每个成员的发言既是对其工作内容的一个承诺，有责任感；会议明确了问题的存在，并在接下来的时间内可以去解决；会议可以快速的通报当前任务的进展情况，使外部人员也可准确、及时的了解。
站立会议也正体现了Scrum方法的五大价值观：承诺、专注、公开、尊重和勇气。
相关阅读：
