今天是周一了，我们今天是开会模式。
上午是Sprint Review，也就是Demo, Retrospective meeting。下午是grooming meeting。
在Demo之前，托尼先打开wiki page，wiki上有我们这个Sprint的所有任务，明确地标注出了这个Sprint一定要完成的有哪些，这种是需要Commit的，哪些是没有完成也不会影响的，这种是nice to have的。然后一个个看我们是否达成了这个Sprint的Commit。
会议开始后，托尼说：“……这个Sprint我们的Task有xxxx……，我们需要Commit 的有……，我们的Commit完成了，还有一个nice to have的没有完成。今天要Demo的Task有3个，接下来史蒂文开始Demo。”
“大家好，我是史蒂文……”
今天我也做了一个小Demo，Demo之前我已经把旧版本和新版本分别装在不同的机子上，试过了一遍确认是好的。然后我再打开对应的wiki page，找到这个Story所在的页面。连上我的电脑之后，我就开始Demo。我是这样来演示的，先把这个Story的背景，功能，设计，UI这些给大家讲一下，然后演示旧版本，再演示新版本。演示完了看看大家有没有问题。如果谁有问题，商议过后确认要改动，我们就会马上创建一个Jira Task，并且在新的Sprint中做。
Demo结束后，外国的同事离开会议，我们自己开Retrospective meeting。
托尼说：“现在我们开始做Retrospective，我们先看看上个Sprint的记录。”
托尼打开上个Sprint的Retrospective的wiki page。因为这上面记录着上个Sprint Team做得好的，以及做得不好的地方，看这个页面的目的是回顾上个Sprint我们遇到的问题，在这个Sprint中是否有出现，出现了的话有没有按照之前提的解决方案去解决；解决的效果怎么样，是不是一种好的方案，下个Sprint中是否还可以继续用。如果这个Sprint中用到了这个解决方案完美的解决了类似的问题，那么这个问题对应的Action 就可以关闭，这个方案就可以在以后的工作中继续使用。如果在这个Sprint中没有遇到类似的问题，那这个Action就要移到新的Sprint中。如果这个解决方案根本不能解决问题的话，那说明这个Spring中还是有这个问题出现，所以接下来就看新的Sprint的Retrospective的页面了。
“在上个Sprint中我们有一个需要改进的地方，就是UI上的单词拼写有好几处错误，对应的Action Item是说开发人员应该注意单词的拼写，认真比对UI设计上的单词。史蒂文，这个Action Item做了吗？”
“做了，这个已经做到了。"
"好，那我们就看看这个Sprint吧！”托尼一边说一边打开新的页面。
之前我们有说过，在一个Sprint开始的时候我们就会有一个Sprint xxx Retrospective页面创建出来，之后在Sprint进行中，每个人都可以在这个页面上填写自己认为做得好的，做得不好的地方。
如果这个Sprint中出现了跟上个Sprint一样的问题，之前提出的解决方案不行，那么在这次会议中，我们应该再针对这个问题进行讨论。这个问题是怎么发生的？为什么会发生？要通过大家一起问为什么找到问题的根源，只有找到了根源才能找到真的解决方案。所以要记下这个问题的根源是什么，新的解决方案又是什么，这个解决方案要怎样执行，一步步都要清楚地列出来。把这些谈清楚，也写清楚了，后面再建一个对应的Action，指定一个跟这个问题最相关的同事去跟进，比如开发人员容易遇到的问题，由开发跟进，测试人员容易遇到的问题由测试人员跟进。
在这次的Sprint Retrospective中，做得好的，我看到新同事写了：同事之间互相帮助。爱米莉写了：开发人员的代码质量比以前有所提高。做得不好的，史蒂文写了一个，发生了什么：任务BXX-xxx没有按时完成，为什么：因为在做这个任务之前有一个场景没有想到，是测试人员测试之后才发现的。
“那我们先看看这个Sprint做得好的有哪些？爱米莉，你先说你的！”
爱米莉：“我在这个Sprint中测试了4个Task，我发现我在这次的Task中找到的bug很少，比如以前一些UI拼写上的问题现在都没有了，所以我就写了这个代码质量有所提高。“
“好，看来之前的Action都做到了！简，你来说说你写的！“
”好的，我和路易斯都是新来的嘛，这两天就是遇到的很多问题，都是大家帮我们解决的！“
”很好，其它还有什么做得好的吗？“
“我想的跟简说的一样。”路易斯说。
“我觉得做得好的就是我们终于把新来的网页版产品的流程走了一遍，从做一个Story到发布。”我说。
“你的意思就是Team掌握了新产品的流程？”托尼问。
“是的。”
“那我也说一个，Team做到了拥抱变化。史蒂文，你呢？“
”我没有想到。“
”好的，那接下来，我们再看史蒂文提的这个可以改进的。“
”我这个Task呢就是一开始做的时候，在research和grooming的时候我们都没有注意到还有一个那样的用户场景，所以做的时候就没有考虑到这个问题。后来爱米莉测试的时候她说到那个用户场景不行，我才开始改，所以这个Task没有按时完成。“
”这个Task的功能是……，这个用户场景是……“
“没关系，那我们来讨论一下怎么避免这种问题吧！”
“爱米莉，你是什么时候想到这个用户场景的？还有，现在我们的Story在Research完后，测试人员不是会做一个大概的测试设计吗？那我们上次的测试设计中有写到这个场景吗？”
“没有，我们那种测试设计只是一个很high level的设计，我是在准备测试用例的时候想到的。”
“哦，那你准备测试用例时开发开始做这个Task了吗？”
“应该在做吧，我当时是看到他这个Task在In Progress，然后我就开始准备测试用例了。”
“如果你提前准备好测试用例，然后让开发人员一起Review过测试用例后再开始开发呢？”
“我觉得这样应该可以避免这个问题，因为有时候，开发人员想问题的角度不一样。”
“是的，有时候，开发想到了测试也可能没想到，有时候是测试想到了开发没想到，这样正好可以综合互补一下。”
“爱米莉，那你准备这个Task的测试用例花了多长时间？”
“大概4小时吧！我是先学习wiki page里Story上写的东西，之后把Jira里的Acceptance Criteria先整理成一个验收测试的页面，然后把那个测试设计进行细化，完了就变成了一个个做探索式测试的Charter。”
“那个场景是在某个Charter里面？”
“是的。”
“那我们下个Sprint要不要试试先Review完测试人员设计的测试用例之后再开发，你们觉得呢？”
“可以，但是是一个Task在Open的时候先让测试人员做测试用例还是说在grooming之前就让测试人员做这个测试用例呢？”
“我觉得应该就在grooming之前做，因为在grooming的时候整个Team可以一起Review。”
“那我们的Acceptance Criteria呢？以前我们都是在grooming的时候一起写的。”
“这个也可以是测试人员提前写，在Grooming Review的时候再看看要不要增加或者删除。这样在Grooming之前就做好了准备，那Planning之后就可以开始做了。”
“如果这样的话，那我们下个Sprint的Task就还不能用这种方法，因为今天下午就要Grooming了。”
“没事，我们可以把下下个Sprint的Task在这个Sprint中加上测试用例。好，那我们就创建一个Action，谁来负责跟这个Action？”
“我来吧！”
“好，爱米莉来跟！那在下个Sprint中，测试人员应该先根据Task的优先级准备测试用例，再把这个Task的Acceptance Criteria也写上。这样一来，测试人员的工作时间就要做些调整了。“
“其实还是一样的，可以在我们Research的Task里加一个测试人员的Task。”
“好！一会儿测试人员可以先去创建几个Research的Task，下午我们就要Grooming了。关于需要改进的，大家有没有想到什么其它的？”
“没有了。”
……
292
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
