重读后的反思
这本书的实用不用我来废话了。我的team已经使用scrum有段时间了,今天我又重读了部分章节,现在是一个根据我的个人经验,反思我所在team的scrum实践所存在的不足。
1. 我们混淆了backlog的真正意义,他是产品负责人提出的,从业务角度出发的,可以demo的故事;但是我们的往往是开发人员根据项目需要所列举的要做的事情。我们需要进一步区分故事和任务。
2. 我们的sprint planning meeting并不规范,并不排每个故事的priority,而且花了太多时间在讨论how to design and how to implement,因此常常超时。
3. 每日例会对于昨天干了什么更看重,但更应侧重今天打算干什么。
但也有他没有很好解决的问题,比如“技术故事”,举个例子,“重构现有代码”,这些东西没法demo或者交付,而且优先级比项目的进度看起来更低,如何把他添加到backlog列表中,这是个值得思考的问题。
我很关心的测试问题,还需要再重读一下,看看作者是怎么做的。
1. 我们混淆了backlog的真正意义,他是产品负责人提出的,从业务角度出发的,可以demo的故事;但是我们的往往是开发人员根据项目需要所列举的要做的事情。我们需要进一步区分故事和任务。
2. 我们的sprint planning meeting并不规范,并不排每个故事的priority,而且花了太多时间在讨论how to design and how to implement,因此常常超时。
3. 每日例会对于昨天干了什么更看重,但更应侧重今天打算干什么。
但也有他没有很好解决的问题,比如“技术故事”,举个例子,“重构现有代码”,这些东西没法demo或者交付,而且优先级比项目的进度看起来更低,如何把他添加到backlog列表中,这是个值得思考的问题。
我很关心的测试问题,还需要再重读一下,看看作者是怎么做的。
有关键情节透露