Scrum管理中的几个会议与我们的实践

根据Scrum in Action一书第一章，可以看到有如下几个会议。

Release planning

Product owner负责Release planning会议。该会议的目标是指定一个产品开发周期由几个release组成，每个release都要指定交付日程表。
举例，该会议结束时，应该有一个类似下表一样的发布计划：



如何得到上面的表，是需要一些过程和方法的，这里暂时不表。

Sprint planning

该会议分为两阶段：

第一阶段，确定需求是什么

Product owner向整个team介绍这个sprint要实现的story, 根据team的反馈来取舍，调整这些story. Product owner对backlog的优先级进行排序，然后挑选出合适的story.
story的描述模板可以参考下面的，来在redmine backlog社区的一个建议：
The user story template.

Proposals:

* As a [type of user], I want [some goal] so that [some reason].
* [type of user] should be able to [some action].
* [some feature name].
* [some action] should lead to [some result].
story必须清晰定义，以便Product owner进行Acceptance test. 只有通过Acceptance test, Product owner才能将story状态标记为done.

第二阶段，决定怎么实现需求

Development team主导这个会议，从第一阶段的story中，分解task. 共同评估每个task，比如task的完成的定义，涉及的技术细节，交付的结果，需要的工作小时。然后再决定谁来take这个task，谁是reviewer.
这里有一个我常用的task的模板，举个例子
task name：register account
detail: user can register account himself, front-end page validates the input, back-end(REST API) save the new account into storage(MongoDB replica-set), send email to user if operation succeeds (we can write more words to define it very clear, it's just one simple example)
result: codes, test codes(over 70% coverage), in CI
working hours: 24
owner: Mark
reviewer: Dean Chen
可以使用软件系统来支持，比如我们采用IceScrum，GitLab也能起到重要的辅助作用。
这里定下了reviewer，也就意味着不要等到开会，当task owner认为完成了task，就可通知reviewer进行检查。好的系统可以将reviewer的comments记录下来。

Daily Scrum

Development team 举行站立式的每日会议，目标是简短有效的交流。每天查看burn up 或者burn down图来检查项目的整体进展。实践中我们也可以交流遇到的技术难点和意料之外的情况。这是对Sprint planning会议结果执行的每日考评。严格来说，不能修改/增加/减少已经定下的story和task。如果要修改，必须要product owner和team一致同意，但是要非常慎重。如果经常这样干，就无任何计划可言，成了中国公司常见的加班加点应付需求变化。

Sprint Review

Product owner和development team一起参加Sprint结束前的review会议。会议流程如下：
1. 先讨论那些story和task已经完成，侧重于story层面
2. 想product owner演示已经完成的story
3. product owner可以介绍产品需求和市场是否有变化，从而为下阶段的sprint做好准备
下面的观点来自我的老板Moxie:
1. 每个sprint review都是一次内部的产品发布，因此介绍和演示团队在产品上取得的进展是主要内容，而不要变成具体每个task的讨论。更不需要每个developer来轮流演示自己的task.
2. 没有完成的story和task需要仔细讨论原因，寻找经验和教训。
是否因为目标定的太多没有给团队留下余量，通常我们都会对目标工作量打8折作为实际工作量，
是否高估或者低估了技术问题。比如一个没有想到的用户体验问题引入了一连串的技术解决方案，一个maven的升级引发了plugin的不兼容。

Sprint Retrospective

Development team在Sprint review会议之后和下一个sprint planning会议之前，召开这个会议的目的是：
总结经验教训，提出在后面的sprint 需要改进的地方。
这个阶段每个developer可以轮流阐述自己的观点，遵照下面的流程：
1. what have you done in last sprint?
这部分内容可以简单快速，因为实践中每个task都会被review后才视为结束。
2. what unsolved problems have you found?
这部分有效的内容将加入到backlog中。
3. give you suggestions about process, technique.
这部分有效的内容也将加入到backlog中。

仔细理了一下书中的知识，同时找到了对应的英文术语，因为在我们这个倡导英文的办公环境里面，最终大家都要一起用英文开scrum会议的，术语不用英文不行啊。书写的很好，翻译的不错，就是少了英文术语。
同时也加了自己不少的实践体会，感谢CSDN的这次读书活动。对我很有帮助。