标签：style ar sp strong on 问题 bs as 时间
通过一段时间的推行，每日例会也取得了不错的效果，大家也都明白各自需要做的
工作事项。
敏捷开发中的每日例会，就是为了确定下一天所需执行的工作，以最大可能地履行其承诺。 团队的每个成员都应该描述自上次会议以来所做的工作。 他们计划在当天完成的工作，以及可能对其他团队成员产生影响或需要获得其他团队成员帮助的任何问题或碍。 为了确保会议准时开始并在 15 分钟或更短时间内结束。 在此会议中，每个团队成员都需要回答以下三个问题：
昨天我完成了哪些工作？
今天我将完成哪些工作？
哪些阻碍性问题或障碍可能影响我的工作？
但是，在每日例会实行的过程中也遇到了各种各样的问题，所以现在总结一下。
1. 会议无法按时召开
问题：以前是在早上开，但是老有人迟到，也无法硬性规定不能迟到。即使是大家都按时上班了，也会由于各种拖拉，导致例会不能按时召开。
解决：后来我们就放到了下午，下班前20分钟，提前10分钟提醒。这么调整之后，效果确实不错。所以确定一个大家都合适的时间，形成习惯和规律，坚持执行。可以有奖励和惩罚的措施。
2. 互不关心
问题：刚开始大家都在各自说着各自的事情，做的多少，准备做哪些。一个人讲话的时候，其他人都在想着自己的那点事情。各自讲完一遍之后，大家对其他人要做的东西和问题还是搞不清楚。
解决：为了解决这个问题，后来每日立会就采用了抽查提问的方式进行改善立会的问题，基本的形式就是，在每日立会上，当一个人讲完了之后，随机抽取一个人进行提问，问刚才讲了什么，有哪里不明白的。这个人要明明白白说出刚才那个人说了什么，如果说不出来，就让这个人去向刚才讲的人进行询问和了解。别人都在一旁看着这两个人进行对话，直到不明白的人能够清清楚楚的说出来为止，如果说不明白，就继续问。一段时间之后，发现效果不错，大家的情绪一下子提升起来了，气氛也热闹起来了。
3. 描述含糊
问题：立会上大家所说的话中如果存在含糊的词汇，就需要引起注意，含糊的地方，其实有可能就是需要注意的地方。比如“已经差不多完成了”、“这个任务有些复杂”、“遇到了点小麻烦”、“昨天弄点别的耽误了”，“有个地方有问题，需要重写”等等。咋一听，感觉上合理的，因为一些原因，导致今天的任务有所延误，也是合情合理的，但是仔细一想，导致这些问题没有被及时发现。这些地方其实就是问题的地方。
解决：如果出现模糊不清的词汇时，停顿下来，追问一下，差不多是多少，哪个地方有问题，为什么需要重写，什么小麻烦？？这样把真正的问题追问出来，及时的纠正和提供帮助，模棱两可的地方得到确认，避免开发人员带着疑问去开发。立会上不应该有含糊的词汇。不过需要注意的是在追问的语气和态度上需要把握一下，追问的目的是知道模糊的原因是什么，是为了帮助员工，为了整个团队的效率，而不是仅仅的去追究责任，增加压力。
4. 任务过大
问题：任务挪动不了，因为没有做完。连续两天可能都挪动不了。
解决：拆分任务，如果每天都挪动不了，会增加心理压力，产生沮丧感。拆分任务可以解决这部分问题。
5. 返工太多
问题：由于没有明确完成的定义，所以刚开发完，没有经过测试的任务，就直接说完成了。导致后期返工，又重新花时间去改之前的bug。
解决：明确完成的定义，团队所有人达成共识。我们对于人物的定义是：经过了开发人员自己的测试和另一位开发的交叉测试（具体在前面一片文章有讲）。这个任务才算完成，才可以挪到完成里面去。这样就促使开发人员，必须自己的测试全面，没有问题。也能够解决开发人员不愿测试的毛病。
标签：style ar sp strong on 问题 bs as 时间
原文地址：http://www.cnblogs.com/zhangweizhong/p/4166119.html
