思考一个问题，软件工程领域的项目管理是属于自然科学还是社会科学？
上大学的时候老师说过一句话，社会科学不同于自然科学的一点是，“社会科学没有天才”，社会科学的工作需要经验的积累，时间的积累；让一个天才的程序员去做领导，最大可能性的结果是他变成一个平庸的管理者；
Scrum是基于经验型过程的流程框架。
敏捷价值观的第一点是“个体和互动高于流程和工具”，强调的是让做事的人拥有自己的流程。因此，Scrum 定义的只是一个流程框架，留给做事的人充分的空间去制定并演进自己的流程。经验型过程是基于目标的检查适应。Scrum的活动设计基于经验型过程，在两个层次，一个是每天，另一个是每个迭代，分别对应于每日站会(每天发生)、迭代评审和回顾(每个迭代发生)。
下表总结呈现了经验型过程的要点，我们来详细阐述两个关键点:“以终为始”和“检查适应”（Inspect Adapt）。
以终为始
目标的定义是经验型过程控制的前提，我们分别来看对应于不同活动的目标。
1，迭代目标。每日站会是围绕迭代目标的检查适应。迭代目标的定义发生在迭代计划中。当团队和PO一起定义迭代目标后，团队通过每日站会的检查适应来达成目标。迭代目标可以定义成在迭代结束时需要完成相应的需求交付，也可以定义成更为抽象更接近价值的目标，比如实现某个用户场景（需要完成一系列）。无论如何，我们不应该把迭代目标定义成完成任务，因为任务会在迭代过程中随着检查适应而改变；
2，产品目标。迭代评审是围绕产品目标的检查适应。产品目标的定义通常发生在产品计划中，从最初的产品展望到持续的发布计划。产品周期可能很长，所以通常指导迭代评审检查适应的产品目标是阶段性的，比如发布目标或者季度目标。交付需求不应该是产品目标，定义产品目标的关键是回答为什么要交付这些需求，希望改变什么用户行为或者得到什么收益。这样一来，交付需求就变成了达到产品目标的途径。产品目标是由PO定义的，他通过迭代评审的检查适应来达成目标；
3.改进目标。迭代回顾是围绕改进目标的检查适应。Scrum中内置的一个重要改进目标是在迭代结束“做到完成”。“完成”的定义是考虑了现状之后认为确实可行，最终要达到潜在可交付的状态。如果我们已能持续“做到完成”，而“完成”的定义还没有达到潜在可交付的状态，就应该考虑扩展“完成”的定义。如果我们已能做到潜在可交付，还可以考虑缩短迭代周期。无论如何，改进目标必须能产生适度的挑战，以驱动改进。改进目标由整个Scrum团队拥有，他们一起通过迭代回顾的检查适应来达成目标。
很多时候，我们发现Scrum的经验型过程之所以不太奏效，是因为没有做到以终为始。没有目标的指引，检查适应就无从谈起。
检查适应
在目标明确后，每天（针对迭代目标）或者每个迭代（针对产品目标和改进目标），我们都需要做检查适应。
1，每日站会
团队通过每日站会来检查离迭代目标有多远以及接下来这天该如何调整。传统的迭代燃尽图基于任务完成，我们从中可以知道任务的进展。但是任务的进展并不意味着需求的进展，因此我们也可以基于需求来画迭代燃尽图。除此之外，我们也会关注任何影响这代目标达成的障碍和风险。
理解了现状后，团队决定接下来的调整。包括添加/修改/删除任务，改变任务优先级，重新分工，甚至加班。如果团队自发加班，并且不影响可持续开发，个人觉得这只是团队检查迭代目标和现状后做出的适应性举措。如果团队发现即使做了最大限度的调整，达成迭代目标还是危险，那就应该叫上PO一起来调整。需求的范围会被重新协商，通常当前迭代范围中最低优先级的需求会考虑放弃，团队在接下来的时间里专注于完成高优先级的需求。如果可能，最低优先级的需求会被拆分，以使部分需求仍然可以完成。注意，部分需求的完成，而不是需求的部分完成(比如编码完成而测试没完成)。极端情况下，PO会决定终止当前的迭代，重新开始一个新的迭代计划。
2，PO通过迭代评审来检查离产品目标有多远，在接下来这个迭代该如何调整
如何理解每个迭代的进展是个难题。整个迭代评审会有团队、用户/客户及各种干系人参加，PO会听取大家对产品的反馈。验收是迭代评审中检查的一部分，如果PO和团队在迭代中紧密协作，完成的需求通常都能被接受。发布燃尽图能帮我们理解当前迭代结束后相对于整体的发布情况如何。因为发布燃尽图是基于需求完成的，这里有个重要的假设，我们大致知道整体的发布范围，那样就可以知道大概完成了多少比例，根据速率就可以推导出大致还需要多少个迭代。这个假设只有在需求不确定性相对较小的项目中才成立。当不确定性较大时，究竞做哪些需求能够帮助我们达成价值目标是PO工作的最大挑战，也是PO给产品成功带来的最大贡献。PO会关注任何影响产品目标达成的障碍和风险。
理解了现状后，PO决定接下来的调整。最直接的调整反映在对产品待办列表的更新，包括添加/修改/删除需求、改变需求的优先级。发布计划和发布燃尽图也会相应更新，发布的范围/时间/成本可能会做调整。下一迭代的目标开始涌现，PO选取最能够帮助达成产品目标的需求进入下一迭代的计划活动。极端情况下，PO和管理层会一起决定终止该产品开发。
3，Scrum团队通过迭代回顾来检查离改进目标有多远，在接下来这个迭代该如何调整
Scrum团队包含团队、PO和SM。做事的人拥有自己的流程并对之加以改进，为此，我们需要整个Scrum团队一同来检查适应。在回顾中，SM引导大家检查过去迭代中发生的重要事件，产生的过程数据和趋势，尤其是与改进目标相关的部分。最重要的问题和改进机会会从回顾中逐步涌现。
当对需要改进的问题达成共识后，回顾的重点转向接下来如何调整。对问题的深入分析为采取行动奠定了坚实的基础。常见的质量流程改进方法在这时可以得到应用，比如鱼骨图、5个为什么和因果分析图等。当可能的根源显露出来后，Scrum团队一起设计行动实验在下一个迭代尝试。改进行动可能涉及协作方式、工程实践和组织结构等，也可能会更新工作约定或者扩展完成的定义。
理解经验型过程的应用原则，并关注每日站会、迭代评审和回顾中检查适应的效果，是实施Scrum的精髓所在。