做了这么长时间的敏捷开发，第一次对一个冲刺有这么刻骨铭心的印象。我想主要有以下几点造成的。第一，是有一个全新的团队，非常年轻几乎没有经历过任何正规化流程的人员构成的团队。第二，是*把很多基础性的工作拉进来还不得显性的列在backlog中。第三是，从需求到技术再到部署，都没有在一开始就定好准备好，都是随着时间在迭代。
团队。和任何一个经验丰富的scrum master聊天，我想都会感觉到不是每个人都是和做敏捷的。敏捷对人的要求是很高。以前我自己在做传统过程的时候，通常的感觉是自己挖坑，然后再把萝卜往里面填。萝卜只负责在某一个坑里面默默成长；而做敏捷，是整个团队在挖坑，谁合适谁就主动跳进去填坑，长的不错了，再跳出来接着找一个合适的坑。做敏捷对沟通的时效性非常讲究，一个问题，你决定在什么时间点抛出来，如何选择最佳的沟通方式，邮件还是电话还是IM，都是判断。还有就是表达的准确性，如果一个问题你无法表达清楚，那么团队就无法帮你去解决，久而久之，你就会更习惯于自己去闷头解决。不知不觉形成了孤立。
隐性任务。敏捷的burndown chat是非常有益的。因为敏捷的理念是只有时间固定的，那么应该将在某一时间内做的事情完全的可视化。这不仅是让所有项目干系人都清楚的认识到你在做什么，也让每件事情更易于管理。否则，每个冲刺积累下来的数据对以后的计划是无意义的。
变化与迭代。我想选择敏捷就必须拥抱变化。如何在一个冲刺中管理好变化实在是太重要了。面对任何变化，任何外在的冲击，我想我们必须牢牢记住一个核心目标，那就是接收故事。我们需要开动脑筋认真分析，想出一个能在最短时间内完成任务的工作方式。比如说如果一些基础组件还在同步开发中，那我们就需要在日常开发中，锁定这些组件的版本，隔离其不稳定的部分，用各种假对象等方式作出必要的封装。对于需求的变化，也需要和PO认真讨论，看是否是即时修改还是可以放到以后再做。这里面都是大有学问的。我想，这不是文字可以说清楚的，是随着项目的推进经验的积累所带来的。玩敏捷真的是一个经验活。因为敏捷本身是没有方法学的。它只有几个核心概念，如何去理解全看个人。
明天要开回顾会议了，我想每个人都一定有很多话要说。我很喜欢这种碰撞，因为这对我来说，可以更全面的了解敏捷在各种生态环境下的运行情况。