这是《落叶》文集里第 80 片落叶，希望你能喜欢，不为别的，只为这份坚持。
“十宗罪”之三：缺乏沟通
很多团队在切入敏捷模式之后，还仍然保留着原本瀑布模式下的习惯，开发阶段时，测试和开发很少沟通，都等到开发完成，提交测试时，有了bug才会开始有些沟通。给人感觉，就还是原本的流水线模式，一个环节完成了，移交到下个环节，然后上个环节的人就不闻不问了，坐等bug出现。所以在一个团队里，很容易出现彼此都不知道在做些什么，所以遇到问题，也不太清楚该找谁处理，或者说很难协调。
而敏捷从字面上就能很容易地看出来，追求的就是速度对吧。所以在沟通上，就应该是及时的、高效的、透明的。而不是消极的、被动的在等问题，而应该是积极地、主动地去找问题、去解决问题。
Scrum 里的 Daily Scrum Meeting 最主要的一个作用其实就是让每个人每天都能了解到其他人都在做什么、当前还有哪些问题、并能及时找到问题的解决者。我之前就采用单独引入每日站会这个方法，解决了一个项目组实际项目中的沟通问题，让项目经理对整个项目的进度和每个成员的状态有了及时清晰地了解。
同时，每个 User Story 的验收，每个 Sprint 的计划会议和反思会议，都是为了增加团队沟通的机会，通过在前期和后期的充分沟通，而减少在执行过程中的偏差，降低返工的几率，减少不必要的成本消耗。
所以，在敏捷里，我们一定要重视沟通，凡事都要及时沟通，而且是高效率的沟通，而且从沟通效率和正确率来考量，以下是几种沟通方式的顺序：面对面沟通 > 电话沟通 > IM 沟通 > 邮件沟通，不过如果是那种需要记录存档的沟通，建议还是辅以邮件，会比较好。
“十宗罪”之四：缺乏评估
敏捷里评估的最小对象颗粒是 User Story，相当于把之前一个比较大的需求任务拆分成了若干个 User Story，所以很多人都不习惯了，不习惯在原有一个整体的评估基础上，再细分拆解，觉得太麻烦了，觉得多此一举，没有那个必要，往往就会省去这一步骤，只对大的需求做一个评估，对拆分出来的 US 就不再细评估了。
在整个 Sprint 不出问题，或者说没有临时任务插入时，你的确感觉不到做这么细颗粒度评估的作用在哪。但你想想，一旦 Sprint 进行过程中，临时来了一个重要的 User Story，大概需要5个人日，试问一下，在你没有对现有 Sprint 的所有 US 做评估时，你怎么去消化这额外的5个人日的 US？加班？还是延期？我想，这时候，SM 一定很头痛，怎么去做这个决定？接，还是不接？能不能接？不能接，那依据什么呢？。。。
假如你在计划阶段，对每个 US 都做了评估，再遇到这种情况时，你就可以根据优先级和工作量两个维度的匹配，找出可以被置换出当前 Sprint 的 US，这样，你既可以很好的消化掉这个紧急且重要的 US，又不需要加班或者延期去完成这个 Sprint，从 SM 的角度，是不是能更得心应手地去应对这种临时任务呢？
作者简介：14 年测试经验 + 11 年项目管理经验 + 11 年团队管理 = 一个测试老兵
