当我们说到Scrum的时候，首先想到的可能是每日站会，ScrumMaster。其实Scrum包含的角色和实践活动还有很多，为了便于记忆，我们一般将它们总结为“3355”，即：
3个角色（产品负责人Product Owner 简称PO；ScrumMaster 简称SM；Scrum团队）
3个工件 （产品列表 Product Backlog；迭代列表 Sprint Backlog；潜在可交付产品增量 Product Increment）
5个活动（迭代规划 Planning Meeting；站会 Standup Meeting；迭代评审 Sprint Review；迭代回顾 Sprint Retro； 迭代执行 Sprint）
5个价值观（专注 Focus；勇气 Courage；透明 Openness；承诺 Commitment；尊重 Respect ）
我们是一个组建了一年多的敏捷团队，期间项目目标几经修改，团队成员也几经更迭，最近才刚刚走入平稳期。参照团队状态变化的5个阶段，现在的团队应该处于从Norming向Performing转变的过程中。
加入团队之后，我发现团队中的敏捷实践跟我之前经历的敏捷团队不太一样，在渐渐熟悉这些敏捷实践，并慢慢的习以为常。但是在读过《Scrum精髓》之后，这才慕然发现其实我们的敏捷实践并不是完全照搬Scrum的方式，接下来详细对比一下与《Scrum精髓》相比，我们的中华田园式敏捷到底有哪些“发明创造”。
角色
PO：我们的产品负责人（PO）是一个刚刚承担这个角色不久的新人PO，老本行是一个专业的UX（用户体验设计师）。在项目组中先后担任过UX，BA，PM和PO的角色。拥有深厚的客户项目经验和产品意识。
ScrumMaster：我们团队其实并没有一个专职的ScrumMaster，每日站会等敏捷活动大多是团队成员轮流组织。
敏捷团队： 一个PM，一个QA，一个Dev转的Tech BA（因为我们做的平台产品技术要求比较高），五个开发（Dev）。
问题：前文提到过我们的产品比较偏技术，所以UX出身的PO在面对业务干系人提出的一些比较技术化的用户需求时，会显得比较乏力。因此产品列表的工作其实是我们的Tech BA在做。因为团队没有一个ScrumMaster，很多敏捷实践的裁剪和修改都是团队成员在一次次的迭代回顾中总结和归纳出来的，一股浓郁的中华田园风。
工件
产品列表（Product Backlog）：产品列表之前大部分的内容是Tech BA拟定的，并与PO最终确认。
迭代列表（Sprint Backlog）：迭代列表是由Tech BA初步拟定，并在一个称为Pre-IPM的会议中，由PO，PM，BA，QA和TechLead（TL，senior Dev）来审定通过的。
潜在可交付产品增量（Product Increment）：根据迭代列表的范围完成的产品特性。
问题：由上面三个工件的描述可见，在最前面的两个工件中，Tech BA都起着决定性的作用。目前可以看到的情况是因为涉及到跨时区跨语言的业务干系人沟通，刚刚切换角色不久的Tech BA没能很好的代替PO完成业务干系人需求收集和优先级排序的工作，导致产品的交付无法让业务干系人完全满意，由此产生的拉扯给团队和业务干系人都带了非常糟糕的体验。
活动
迭代规划（Sprint Planning Meeting）：在我们的项目敏捷实践中，对应迭代规划，我们有三个会议与之对应，分别是Pre-IPM，Technical Discussion 和 IPM（Iteration Planning Meeting）。三个会议的参与者和主要目标如下：
Pre-IPM（PO+PM+BA+QA+TL），目的是为了划定下个迭代的范围，排定迭代内部优先级。
Technical Discussion（TL+Dev+BA+QA），目的是为了澄清下个迭代每张卡的范围，Dev沟通每张卡可能的技术解决方案。这个会议里是开发人员第一次接触到下个迭代的故事卡。
IPM（PO+开发团队），目的是为了团队和PO一起确认下个迭代的可用人天数，估算下个迭代所有卡的复杂度，根据复杂度和依赖关系检查下个迭代的关键路径是否会超过最大可用人天数。
之前团队只有一个IPM会议，但是在实际执行的时候会发现每一次的IPM时间都会拖得特别的长，开发人员针对每一张卡的技术实现细节进行讨论，此时PO的参与度会非常的低，当PO和BA一起讨论排定业务优先级的时候，开发人员的参与感也会非常的差。因此后来根据会议的目的将IPM拆分成三个会议，一个用来排优先级（Pre-IPM），一个用来讨论技术实现方案（TechnicalDiscussion），一个用来估算故事卡点数。到目前为止实行得还算比较有效。
站会（Daily Standup Meeting）：每天上午PO和开发团队一起拉通上一个工作日的任务完成情况以及当天的工作计划，以及完成当前工作的阻碍。在每日站会之后还会有一个代码审查的环节，dev们会将前一天完成的代码展示给其他的团队成员，这个环节对于团队成员之间了解彼此的任务进度和实现方式非常重要，而且对于统一团队内部的编码结构和编码风格非常有帮助。
此前我们曾经尝试在每天下班之前进行代码审查，但是因为弹性工作制的原因，每个同事下班的时间不太一致，因此任务完成程度也不太一致，因此有些同事在代码审查的时候还沉浸在自己写到一半的中，代码审查的参与度和效果也不是特别理想。因此我们将代码审查的环节放到每日站会之后，一方面可以让大家更加专注在代码审查上，也能保证大家每天都能将可以执行的代码提交到集成环境之中。
迭代评审 （Sprint Review）：迭代评审是我认为到目前为止开得最拧巴的一个会议，在这个会议中QA会总结呈现出过去一个迭代中团队在开发和敏捷实践上发生的各种问题。由于此前全体dev们参加的时候，认为自己受到了来自于团队其他角色的challenge，会议开得一度非常的尴尬。之后就变成了只有PO，TL，BA和QA参加的一个小范围会议，后面随着团队融合度的提升，又开始引入了所有团队成员参加。但是因为主题关注在延期完成的故事卡，做的不太好的敏捷实践等内容等，使得迭代评审会议变成了迭代回顾会议的热身前奏。
根据《Scrum精髓》对于迭代评审的定义，迭代评审会议的目的在于使每个可以对产品开发工作提出建议的人有机会检视和调整当前构建的产品。说到底是大家一起看看经过这个迭代之后我们的产品变成什么样子了。通过这个会议使平时分散在各个产品特性上的团队成员对于产品现状都有一个清晰的认识。
很显然我们的迭代评审偏离了这个会议的初衷。此外因为迭代评审发生在下一个迭代的第一天，这使得当前迭代的结束节点非常的不清晰，缺乏基本的仪式感。
迭代回顾（Sprint Retro）：我们的迭代回顾会议也往往发生在下一个迭代的第一天下午，紧跟迭代评审之后。全体团队成员一起针对此前的一个迭代中团队表现得好的地方鼓掌，从各自的角度提出团队敏捷实践中可以持续改进的地方，并一起给出解决方案。
但是目前迭代回顾过程中还是存在一些问题，例如回顾过程中产生的一些改进行动过于模糊，无法衡量完成程度，或是执行周期过长，无法在下次迭代回顾中取得明显的改进。而且团队成员回顾会议中领取的Action的完成情况也不太好，往往会出现到回顾会议的时候，上一次迭代回顾定义的Action还没有完成的情况。
迭代执行（Sprint）：迭代执行过程中包含我们每天的工作：PO收集业务干系人的需求；BA写故事卡细化需求；Dev们Kickoff卡、desk check卡、挪卡、写代码；QA写test scenario、测卡、挪卡。随着团队协作日趋默契，日常工作的敏捷实践问题不大，但是故事卡的质量还需进一步提高，Desk check的时候还是偶尔出现漏掉AC的情况。
敏捷之路，道阻且长。