一个快速有效提升团队效率和质量的方法

一个快速有效提升团队效率和质量的方法

在为客户提供教练服务过程中,我尝试过各种方法,发现其中有个方法提升团队的效率和质量最快速有效。简单概括就是实例化需求,但其实只用做一部分就可以有不错的效果。 为什么说这个方法快速有效?说快速是因为只需改变需求讨论会议或者Scrum中Product Backlog Refinement(PBR)的方式,通常就会在当前迭代看出效果来。有效是因为通常改善了团队的工作效率,减少了迭代内的bug,从而减少了开发和测试间的来来回回,提升了工作质量。过往的客户有做过Bug的根源分析,发现有一半是因为需求沟通的问题导致的。 具体做法是: 在开始开发前举行需求讨论会议。也就是Scrum中的PBR,通常在迭代的中间发生,用于讨论并澄清后续迭代的需求。 会议需要三个角色,产品经理或者Product Owner(PO),开发人员和测试人员。Scrum中就是PO和开发团队(包括了开发和测试等) 会议中产品经理简短介绍一下要讨论的需求,开发和测试用测试用例的方式描述需求,即验收条件。以5个需求和8人团队为例: PO花10分钟左右简单介绍5个需求 团队分成3个2~3人的小组,每个小组选一个需求进行讨论,写出需求的验收条件。20分钟一个时间段。此时,PO应随时帮助团队澄清疑问。 再10分钟每个小组分享一下各自的验收条件,其他人给出反馈 再做一轮20+10分钟的讨论,可以根据反馈来调整验收条件。如没有调整,可以拿下一个需求讨论。 如果需要,可以再做一轮。但通常2个星期的迭代,2个小时足够完成整个会议。 用具体的例子来描述验收条件来减少产生误解的空间。比如,买3本书包邮的例子 买一本《实例化需求》和一本《用户故事与敏捷方法》,快递费是12元 买一本《实例化需求》,一本《用户故事与敏捷方法》和一本《单元测试的艺术》,快递费是0元 用业务的语言描述。验收条件应当是业务人员都能看懂的,因此描述的语言应该是业务语言,不应包含技术或操作细节。这样更容易沟通,同时避免过多的讨论实现细节,关注于“需求是什么”而不是“如何实现” 通常来说帮助团队实现1到3比较容易,团队多练习几次就能习惯4和5的表达方式。至于是否一定要用“假如……当……那么……”的格式,如果只是帮助大家澄清需求,那重要的是大家理解这样的结构化表述,对需求规则理解的表述包含了“条件-行为-结果”。当然,我更倾向于使用这样的格式来帮助大家习惯结构化的表述,同时也能方便以后自动化。 经过这样的需求讨论会议后,团队将带着这些验收条件来进行开发,开发一开始写代码的时候就知道测试将怎么测,测试不用来来回回重复测之前已经讨论的情况,可以花更多的时间来发现之前没法预测到的问题。 如果想要有更进一步的效果,那就需要将验收条件自动化,并且不会为了自动化改变原本验收条件的描述,最终形成活文档。当然这需要的投入就比仅改变讨论方式要多很多了,也比较难完全掌握。用实例化需求来实现从外向内的开发——从PBR到Acceptance Test Driven Development(ATDD),再到Unit TDD。这将极大改善产品开发。这些将在以后的文章中讲解,或者来参加我们的培训。:D...
阅读更多