标签：
来源：https://www.scrumalliance.org/community/articles/2015/february/team-agreements
为何需要团队决策？
Scrum团队是自组织、跨功能的。自组织团队内部决定如何来完成工作，而不接受上级指派。要能达到自组织水平，团队应经历团队发展的不同阶段。
Tuckman的团队发展阶段
Tuckman在1965年第一次提出了团队发展的“形成期、风暴期、规范期、执行期”模型，他认为：这些阶段对团队能够成长、面对困难、解决问题、计划、交付成果等工作来说是必不可少的。
Scrum团队要确保在第一轮Sprint就能交付正确，故没有太多时间为团队发展做工作。所以在早期阶段团队应对如何决策达成共识。Sprint0是一个理想的时机来帮助团队快速完成这些阶段。Scrum是迭代和增量开发，所以团队再每一轮sprint中都会经历Tuckman阶段并不断改进。
团队应明白哪些团队决策方法对他们更适用，从而避免冲突。在Sprint0时建立团队决策的方法，可避免中后期临时抱佛脚。
应在ScrumMaster协助召开的会议中来定义团队决策的方法。会议步骤可包括：准备，头脑风暴、排序、分类、达成一致、精化。
Scrum团队的决策
团队自己决定如何达成一致。ScrumMaster可以协助这些讨论会议，但应由团队成员来决定如何决策，并在各个阶段的回顾会上不断改进。
召开会议的最好时机
Sprint0是最好的时机来决定团队决策方法。回顾会可帮助不断改进决策的方法。
团队决策——Backlog提炼会议
Backlog提炼的目的是为了不断改进产品backlog。Backlog提炼应在当前sprint开发用户故事之前完成。通常，提前1~2个sprint，团队就应坐下来讨论下一步工作内容。
活动召开的合适时机和持续时间
Backlog提炼在Scrum中并没有明确的时间安排。最难的是：团队必须在sprint中抽出时间来召开这类会议，就像每个月存工资的10%以备后用。ScrumMaster必须尽力协调团队和产品负责人时间，有时在sprint中间召开。这些可帮助团队策划当前sprint的工作。
谁应参加？
理想中，整个Scrum团队都应参加backlog提炼会。如果不能全体参加，应考量大家的工作量和任务安排，然后选择合适的参加人。
产品负责人与团队之间就用户故事、线框图、原型图等达成一致
团队应与产品负责人就用户故事的细节达成一致，并可考虑将其作为用户故事质量的度量指标。
用户故事应写多长？
当提炼backlog时，用户故事的长度很重要。团队应该慎重选择其长度。理想中，用户故事应在sprint中25%的时间内完成。
选择基线中用户故事和故事点的基线
用户故事应该基线化并获得故事点的估计。所有团队成员应对基线用户故事有一致的理解。
哪些估算技术可用？
团队应对选择哪种估算方法达成一致。专家意见、类比和分解（disaggregation）是可选的方法，也可结合多种估算方法获得更好的结果。对敏捷团队而言，最好的估算方法是用扑克牌。扑克牌结合了专家意见、类比和分解，并用大家喜闻乐见的方式快速获得相对可靠的估算结果。
如何定义“准备就绪(DOR)”？
准备就绪的用户故事可在sprint计划会议中讨论并用于下一个sprint。
产品负责人和团队应该对用户故事的DOR的准则达成一致。以下是重要的准则：
团队决策——sprint计划会议
每个sprint开始，团队和产品负责人召开sprint计划会议，讨论产品backlog中哪些应在本轮sprint交付。会议结束前，团队把选择的条目分解为sprint task，并达成一致。
Sprint计划会的时间
对于30天的sprint而言，最大的sprint计划会议长度是8个小时。团队可根据实际情况商量来减少时间。团队成员应都在sprint的第一天前来参加计划会，产品负责人也应确保能参会。
若会议时间较长，团队应赞同将会议分成两部分。一部分，产品负责人将用户故事展示给团队，基于capacity/velocity，同时团队一致赞同sprint backlog并定义sprint goal。在第二部分，团队成员把用户故事分解为任务。
产品负责人应承诺可以演示用户故事，之后最好能参加任务分解活动，并提供相对的解答和排序建议。团队可在20~30%功能完成后短暂休息。
Sprint计划会议的输入准则
一般来说，在各项目的sprint计划会议中，总有一些团队成员没有阅读或理解用户故事。所有参加sprint计划会的人都应该至少阅读或理解高优先级的产品backlog中的故事，以此作为sprint计划会输入的准则。产品负责人应确保提供这些内容。
选择本轮sprint中选择故事的数量
团队应了解自己的能力（capacity）和速率（velocity），并一致同意被选择的用户故事数量。
任务如何分解
任务分解的方法应提前被定义好，以免执行时相互冲突。任务分解一般在计划会议的第二部分来做。团队成员应一起来做任务分解，而不是每个人做自己负责的故事的任务分解。
如何处理大的用户故事？
产品负责人和团队应共同决定在sprint backlog中选择的用户故事的大小。如果用户故事规模不合适，应决定是把其继续分解然后在本轮sprint中交付，或以后sprint再处理。
什么是对完成的定义（DoD）？
DoD是产品负责人和团队之间最重要的准则。每个用户故事都可能有不同的DoD，一般来说团队和产品负责人应在sprint0中定义高层次的DoD准则，并在每轮sprint计划中增加特殊DoD的要求
团队决策----每日会议
每天，在相同的时间和地点，Scrum团队大概花费15分钟通报各自进展。每个成员陈述昨天完成了什么，今天做什么，遇到什么障碍。每日会议可摒除旧的陋习。团队成员应警惕陋习带来的信号。
每日例会地点
每日例会应在同一地点举行。分布式团队可用在线会议形式。
每日例会时间
对大概7人的团队，应不超过15分钟；团队可根据成员多少，地点和每日例会的方法，来决定每日例会时间的时间盒长度。
团队一致----sprint期间
Sprint期间，团队基于承诺交付用户故事的优先级来安排工作。产品负责人要解答所有的需求疑问和业务逻辑。团队遇到障碍应及时与ScrumMaster交流，ScrumMaster协助团队集中精力解决问题。
编码规范
在Sprint0时应明确编码规范。有时，少数团队成员可能没有阅读编码规范，整个团队应安排会议来讨论并理解编码规范。
结对编程
结对编程技术并不常见。通常要花费不少时间才能让团队成员看到结对编程的好处，但团队应实践结对编程。
障碍（Impediments），扩大（escalations）和风险处理
ScrumMaster和团队应共同建立一套过程来沟通和处理障碍、扩大和风险。
“软技能”一致
有各种不同的一致承诺其实并没有明确提出，但是团队应经常回顾。团队应确保进行中的工作最少化、应确保专注sprint backlog而不是其他非相关内容，应确保不断遵循敏捷的价值观和原则。
团队一致----sprint评审会
团队应向产品负责人和关心产品的人演示每轮迭代完成的产品特性。产品负责人验证sprint计划中的承诺，并决定是否完成。
谁负责演示demo？
理想中，demo中的功能谁实现谁演示。但也可以让业务分析师一个人演示demo，而不是每个人演示不同部分。
谁来搭建演示环境？
应确保评审会之前搭建好演示环境
谁记录干系人的反馈？
演示期间会得到用户反馈，团队应做好记录。团队中的人，或者每个人，都可以记录。产品backlog应根据记录及时更新。
团队一致----sprint回顾会
每一轮sprint结束时举行sprint回顾会。团队成员检查自己的方法，并采取适当的措施来改进。一个深入回顾需要团队建立一种心理安全的环境，这在多数组织中很难见到。
Sprint回顾的技术和方法
回顾有多种方法。团队应了解一些方法，如timelines, triple nickels, team radar, and force field analysis，这些能帮助团队成员进行回顾，并达成一致。
除了团队，哪些人被邀请参加？
有一些团队在召开回顾会时，因为ScrumMaster和产品负责人在场，而感觉不舒服。团队应决定选择哪些人参加回顾会，不同sprint可能不同。
计划改进活动
并不是所有sprint回顾会上讨论的改进项能在下一个sprint变成行动项。团队应按照优先级排列行动项，并决定哪些在下一个sprint被执行。
维护团队的承诺
达成一致的决策，可能并未文档化。一些决策，如编码规范，应该文档化，其他的，例如会议的时间控制和时间盒，可能不需要文档化。
一旦形成决策并记录下来，应定期回顾。可在每个sprint的结尾回顾，可在回顾会上回顾，或者在任何需要做的时候回顾。决策只有被团队执行的很好后，才能进行替换。
总结
有一些决策团队很轻易达成一致，有一些则不然。团队成员会有意见冲突。ScrumMaster在这起到了关键的作用。团队一旦达成一致决策，并按其执行，就可让工作环境更适应，并帮助团队建立自组织的文化。
标签：
原文地址：http://www.cnblogs.com/fffly/p/4280623.html
