Scope-Question-Assumption需求讨论会

关于需求的讨论

最近在辅导敏捷团队和教授Scrum课程中,发现团队提出的很多的问题现象可以归结为迭代前讨论不充分所导致。
根据自己多年亲身实践的敏捷经验,如果在迭代的计划会议上,团队并没有澄清和理解需求,而是在迭代过程中再进行需求澄清,那么往往导致“迭代紧张、测试不充分、估算不准确、精神面貌不良”等表面现象。
因此,对需求的充分理解应该是迭代的入口条件,应该成为Defenition of Ready的一部分,来确保迭代能够健康地开始。
然后,更深入的根源则是团队不了解如何进行一场充分的讨论

敏捷是一种辅助实现交付价值的手段,不应该过于繁重。下面就根据@申导 早年在诺基亚西门子通信工作时所学到的一种简易讨论法:Scope-Question-Assumption(简称SQA)讨论会。

继续阅读 More

在敏捷回顾会议中运用ORID引导技术

作为一个合格的敏捷教练,既要理解领域知识,又要懂得过程的重要性,是各种综合能力的体现。

对于《敏捷回顾》这本书,大家一定不陌生了,很多敏捷教练都会到其中的5步法来引导回顾会议。

最近学习了杰拉德老师讲的ToP的引导技术,发现ORID可以作为一种新的引导方式,而且问题的设计更加结构化。那么究竟如何来设计这个过程呢?

继续阅读 More

需求梳理工作坊引导技术

个人经常在辅导客户团队时,引导召开需求梳理工作坊。这里是一些自己的心得。

参加的人员一般有产品负责人(PO),团队所有人,包括开发职能和测试职能。这里我故意淡化开发人员和测试人员的概念,因为scrum团队追求的是跨职能的组合,职能可以有分工,但职位没有分别。
一般需求梳理工作坊发生的时间是提前1~2个迭代(sprint) 之前滚动式进行,目的是留出足够的时间来准备。越长的sprint就需要越早做准备。需求梳理活动占用整个sprint时间的5%~10%。
PO与团队代表可以随时沟通,而全体人员参加的工作坊则代价较高,但好处是每个成员都有机会了解整个团队的状况,有助于知识和经验的传播,及跨职能的培养。另外,每个人也都有机会面对面与PO互动和发挥创造性,结果是提高沟通效率并且集思广益。

继续阅读 More