今天阅读了构建之法第六章敏捷流程，在软件工程的语境里，敏捷流程是一系列价值观和方法论的集合。在敏捷开发的过程中，可以使团队提高效率，并付诸行动；实现团队的自我管理。在这一章中剖析了Scrum这个方法论：第一步找出完成产品需要做的事情；第二步决定当前冲刺需要做的事情；第三部冲刺。在我们这次的软件开发的过程中，我们实施了这一次敏锐流程的方法论，在冲刺阶段每天开一个站立会议，说一说我昨天做了啥，今天做了啥，我碰到了哪些问题。并将这些做一个个人的记录，同时我们也做了燃尽图和看板图，将实际和预期做了一个对比；可以说我们在冲刺结束后收获颇多。第四部：得到软件的增量版本，发布给用户。
但是在我们这样的理论实践中也会碰到这样那样的问题。各个需求和任务之间是有种种复杂的依赖关系的，除了 优先级之外，我们还要考虑相互的依赖关系。还有把一个任务从产品层级的描述逐渐细化到技术实现层面，是很需要技术能力和交流能力的。当然还有我们的每日例会，会议中我们提到，昨天我写了代码，今天我写了代码，我没遇到困难，这样的会议显然并没有什么作用。当得到了一个增量软件发布后，谁来验证这个增量是否满足了事先的计划呢？
在我看来，衡量一个开发流程是否适合自己的团队，在于实现团队的自主管理、和自我组织能力，和团队的总结能力。如果你的团队很弱，还强行把其他高级的方法论运用到自己的身上，这样也许会适得其反，如果自己的团队拥有了以上实现的能力，保持这样的方法继续下去，依然能创造出很好的项目。