本文讲述了改变Scrum每日站会的一个小故事。我们从典型的以人为中心转变到以Sprint Backlog里的故事为中心。这个想法来自于Jeff Sutherland的一篇论文。

本文的目的是简要描述我们为什么和怎样进行每日站会的变化，它的优缺点，以及我们得到的反馈。在开始之前，先介绍一下背景。

背景

团队已经采用Scrum和每日站会，也有Product Owner（PO）角色。

何时何地出现了改变每日站会的需求？

改变的需求来自于团队的回顾会议。

在改变之前，每日站会按照标准的方式进行。每个团队成员将回答3个经典问题：_1）昨天我完成了什么？2）有什么障碍？3）今天我将要完成什么？_当一个人完成后，下一个人继续。这种方式关注正在说话的每个团队成员。

几个月（许多迭代）之后，许多人抱怨每日站会效率低。基于大家对于这种效率低的原因的反思，团队达成结论，每日站会本身的这种方式可能导致了效率低。

提出什么行动计划？

我们读过Jeff Sutherland的论文https://jeffsutherland.com/ScrumMetricsHICSS2013BWSubmissionFinal.pdf 并且非常喜欢关于改变每日站会的提议。Jeff提议在每日站会上检查Sprint Backlog中每个故事的功能，而不是每个团队成员的。作为教练，我留意到这篇论文，或许团队有兴趣学习一下。事实上，团队很高兴有这个提议，于是团队落实了行动计划，以在下一个迭代来验证这个变化。

这个改变是如何执行的？

在接下来的迭代中，团队在相同的地方开始每日站会，但是这次是基于Sprint Backlog中的每个故事回答3个经典问题。也就是说一个以上的团队成员（取决于几个人参与这个故事）都会说围绕着具体的故事他们完成了什么，将要完成什么，是否存在障碍，以及完成这个故事还需要什么。直到手上这个故事所有相关的问题都解决了，团队才会继续进行下一个。这个流程持续到Sprint Backlog中最后一个故事讨论完。需要注意的是，建议从最重要的故事开始，按照重要性的降序继续讨论。

这个改变带来什么好处？

假设PO参与每一次的每日站会，这个方法可以让PO听到团队关于产品开发的进展——比如，这个方法面向的是产品，而不是谁完成了什么。重要的是正在开发的产品，以及在Scrum中，团队整体执行开发工作。从概念上，我们说团队工作是一组有共同目标（愿景）的人在高度协作的环境中工作。

改变的结果是，团队的效率几乎马上得到提升。假设这是由于这样的事实导致的，当讨论故事的时候参与的每个人都发言，从而提高了专注力。相比之下，传统的每日站会经常有干扰。比如，如果两个开发人员做同一个故事，团队不得不等到两个人在不同的回合中都说完了，才能充分地理解这个故事过去和将来的行动。

更重要的是，对故事专注力的改变，需要整个团队强化正在构建产品的知识，因此现在团队专心在产品上，而不是开发人员的任务。

每个开发人员说话不做限制的事实，允许其他团队成员（他们可能在自己的故事中受阻，或只是完成了一个故事）尝试一起合作关掉正在讨论的故事，而不是去认领一个新的故事。

这个改变的缺点是什么？

大家都知道，在接下来的回顾会议中我们分析了这样的流程改变，为了识别出优缺点。在这个案例中，观察到的主要缺点是，它很难检测到团队成员是否在工作。现在的每个站会中，讨论围绕着故事，而不是每个人在做什么。因此，团队成员必须更积极主动处理这种“闲置”的状态。

同样的，当团队成员非常忙碌的时候，可能也不是那么明显。

作为教练，假设这迫使团队需要更多更好地自组织的话，我的观点是这个缺点可以转化为机会。每个人负责有效地利用自己的时间。每个人负责查看开发流程是否停滞。而且每个人负责决定为了前行而如何一起工作。事实上，参加改变的团队发现一个方法来减轻这个缺点。比如，团队修改仪表盘，因此，查看流程中的每个团队成员的情况更容易。

关于这个改变有数据吗？

通过调查我们收集到一些数字和指标：

• 团队A1有3个成员，团队A2有4个团队成员，两个团队共用一个ScrumMaster
• 团队B1有7个成员和1个ScrumMaster
• 团队C1有4个成员和1个ScrumMaster

根据上述数据，我们可以分析有多少人直接参与。总有有26个人：4个PO，18个团队成员和3个ScrumMasters。每个人的问题是：假定每日站会的这个改变，最符合下面哪条Scrum价值：专注，勇气，或者承诺？调查结果如下图：

我的反思

基于上面给出的数字，我想突出观察到的第一手资料，这种方式工作的团队使Scrum里面关于“团队”的概念更具体。也就是说，每个人都被真正地激励并以可持续的方式工作。每个人都认识到“集体的力量大于个人”。Scrum的目标就是尽可能早的交付高质量的产品增量。

尝试改变，观察结果，从结果中获得认知，再次改变！如果有些事搞砸了，尽早的失败比以后的失败要更重要！

原文链接：https://www.scrumalliance.org/community/articles/2013/november/change-your-daily-scrum-meeting

在写完产品Backlog与用户故事的一些原则之后，Daniel Teng同学建议补充

产品Backlog需要是ODDE的，以及user story的5C原则。

ODDE

• Ordered(排序的)

产品Backlog里面的条目需要是排序好的，并且每一条都是唯一序号。即代表着在产品Backlog中靠上的条目一定是比下面的条目优先级高，并值得优先开始做。

• Detailed Appropriated(详略得当的)

参考前一篇中Mike Cohn提到的DEEP原则

• Dynamic(动态的)

产品Backlog中的条目是动态变化的，随着项目、产品的进展，了解的深入，需要也在实时发生变化。比如说增加、删除和更新条目，或者改变条目的顺序（即优先级）。

• Estimated(做过估算的)

参考前一篇中Mike Cohn提到的DEEP原则

5C

参考前一篇中Jeffries的3C，在此基础上补充2个C。并且总结为user story的生命周期。

card->conversation->confirmation->construction->consequence->card…

• Construction(构建)

开始构建、实现用户故事。

• Consequence(结果)

实现用户故事后，可以展示的结果。

产品Backlog

首先在Mike Cohn《Succeeding with Agile》中提到，关于产品Backlog的DEEP原则

• 详略得当（Detailed Appropriately）

接下来的Sprint中要完成的用户故事，需要足够的详细。而不着急开发的，则不必太详细。

• 做过估算的（Estimated）

产品Backlog中靠后（下）（优先级低）的事项没有充分理解（也不必），因此其估算也不如靠前（上）（优先级高）的用户故事估算精确。

• 涌现的（Emergent）

产品Backlog不是静止的。随着了解的深入，产品Backlog中的用户故事会增加、减少或重新排优先级。

• 排列优先级的（Prioritized）

产品Backlog应该根据由上至下按照条目的价值从高到低排序。团队应从中根据优先级进行开发，从而使正在开发的产品或系统价值实现最大化。

什么是用户故事？

用户故事是一个方便的格式用来表达多种类型的产品Backlog条目，特别是特性的期望业务价值。制作用户故事的方式是让业务人员与技术人员都能理解需求。用户故事结构很简单，并且为会话提供一个很好的占位符。此外，用户故事可以在不同程度的粒度上编写以及很容易逐步细化。

3C

下面说说PB里面的形式之一，user story（Jeffries 2001），最早是Ron Jeffries在2001年提出user story需要满足3C原则： Card(卡片), Conversation(会话), Confirmation(确认).

1. 卡片：

我们并不打算用卡片去捕获组成需求的所有信息。实际上，我们故意使用有限地方的小卡片来促进用户故事简洁。卡片上应该只有几句话来捕获需求的精髓或目的。它也用作占位符以便在利益相关人、产品负责人及开发团队之间进行更细化地讨论。

2. 会话：

需求的细节是在开发团队、产品负责人及利益相关人之间的会话中暴露和沟通的。用户故事仅仅为有这个会话的一个承诺。

3. 确认：

用户故事还要包含满意条件形式的确认信息。这些是澄清期望行为的验收标准。开发团队用验收标准来更好地理解构建和测试什么，产品负责人用它来确认实现的用户故事达到他的满意。

INVEST

后来Bill Wake在2003年又总结了关于user story的INVEST原则：Independent(独立的), Negotiable(可协商的), Valuable(有价值的), Estimable(可估算的), Sized Appropriately or Small(大小合适的), Testable(可测试的).

1. 独立的：

当采用_独立_标准时，目的不是消除所有的依赖，而是用最少依赖的方式编写故事。

2. 可协商的：

故事不是预先的需求文档形式的书面合同。相反，故事是会话的占位符，在会话中细节是可协商的。

3. 有价值的：

故事需要对客户、用户或者两者都是_有价值的_。客户（或者选择者）选择并支付产品。用户实际使用产品。如果故事对他们没有价值，这个故事不应纳入产品Backlog。

_有价值的_标准的关键是从产品负责人的角度看在Backlog中所有的故事必须是有价值的（值得投资），它代表客户与用户的角度。不是所有的故事都是独立的，也不是所有的故事是完全可协商的，但所有的故事必须是有价值的。

4. 可估算的：

故事应该对设计、构建及测试它的团队可估计的。估算说明了故事的大小，因此也就说明了工作量和成本。（更大的故事比开发小的故事需要更多的努力与成本、更多的钱）。

5. 大小合适的：

当我们计划开始做故事的时候它们应该是_大小合适的_。在Spint中要工作的故事应该是_足够小的_。如果我们执行一个几周时间的Sprint，我们想要工作的几个故事，每个都是几天大小的。如果我们有一个两周的Sprint，我们不想有一个两周大小的故事，因为完不成这个故事的风险太高了。

6. 可测试的：

_可测试_的故事指的是一种非此即彼的方式—相关联的测试要么通过，要么失败。可测试的意味着有和故事关联的良好的验收标准（与满意条件有关），即我早先讨论过的故事“确认”的方面。

 

补充一个“用户故事的ODDE与5C”

通常有人会问，在编写产品backlog的时候产品负责人（或者团队）如何确保他们想到每件事情。这个问题对于采用合同制开发的团队尤其常见，这种开发仍然需要前期需求规范。但是我也从有些组织的团队中得到一些问题，他们喜欢不必预先锁定所有的事情。

关于这个问题我想了很多，最后我终于弄清楚了答案。当编写产品backlog的时候如何确保想到每件事情，答案就是：

等待。（题外话——等，等，还是等）

是的，一直等到项目做完。保证想清楚每件事情的唯一方法就是投入到项目中并做完，直到项目结束，随着时间准确地认识到客户想要的内容。

每个不平凡的项目都包含一些涌现的需求。这种需求提前是不知道的，但在项目中某个时间客户会想出来。不论客户或者产品负责人多么努力的去思考，项目过程中总是会有一些新的需求冒出来。这些需求是由于查看、甚至是触及正在构建的系统而造成的。看到已经开发的内容会让用户产生新想法。“现在我看到系统了，那么我想加一些新东西。”

客户和产品负责人不应把涌现需求的存在当做卑劣想法的借口。开发团队也有权利让客户和产品负责人尽力认识到他们到底想要什么。但是，就像产品负责人和客户不可能预先知道每件事一样，开发团队也需要希望他们这么做。

完全确定性是不可能的。应该避免寻求或者期待完美的确定性。

这段翻译自Mike Cohn的博客，英文版请点击

“The unexamined life is not worth living.” Socrates said. It is true as individual, however, for a team it is also applied. If a team has no inspection, they could not know where they are, and how to achieve great success.

Recently I read a book named , written by Esther Derby and Diana Larsen. In this book they mention a specific structure for a team’s reflection and adaptation:

1. 最想问不同的企业文化和价值观，以及商业定位对于敏捷的适用性有什么具体的影响？

What’s challenge for adopting agile with different company culture, core value and business?

There is no one way or template to adopt Agile. No one can lead you down a predefined path that will guarantee success. Instead, you must learn, inspect, and adapt your way forward based on your organization’s own unique goals and culture and the ever-changing complex environment in which you must operate. Regardless of your adoption path, the people within the organization must have the courage to address impediments when the see them. It is easy to change core Scrum values and principles when they conflict with the way the organization operates today. To be successful, you must be willing to face these impediments and take the difficult (and often unpopular steps) to address them.

最近看了一下ORID，有所感悟，是否可以把ORID应用到平时Scrum的回顾会议（Retrospective）呢？答案是肯定的。

先来说明一下什么是ORID。ORID指的是提问的4个步骤，如下：

[如果套用Agile Retrospective的5个过程的话, ORID缺少一个开场和收尾]

_注明：[]_里面代表Agile Retrospective__的过程。

[Set the Stage]

• Objective questions  – 客观的问题[Gather Data]
• Reflective questions – 反应的问题[Generate Insights]
• [修订版]Reflective questions – 反应的问题[这个过程相当于Gather Data, 收集的是心情等主观数据 – 多谢吕毅提出宝贵意见。]
• Interpretive questions – 解释的问题[Generate Insights]
• Decisive questions – 决定的问题[Decide What to Do]

[Close the Retrospective]

 

那么如何应用ORID到回顾会议中呢？对应以上四类问题，下面是我的一些建议：

• Objective questions  – 客观的问题
  • 这个Sprint我看到……
  • 我听到……
  • 发生了……事情
• Reflective questions – 反应的问题
  • 这个Sprint让我高兴/兴奋的是……
  • 让我吃惊的是……
  • 让我愤怒的是……
  • 让我沮丧的是……
• Interpretive questions – 解释的问题
  • 我学到了……
  • 我意识到了……
  • 这些数据告诉我们……；基于此，你的观点或洞察是……
  • 从中我们得到……启示
• Decisive questions – 决定的问题
  • 下个Sprint我们应该做……
  • 据此我们可以做……决定

最后非常感谢张树金同学做的一个关于ORID打油诗总结：

Linda给我的触动非常大，71岁的老太太还可以从千里之外飞过来演讲。

并且她的演讲中small success, reflection regularly都再次打动我。

从与她的聊天中得知，2011年日本刚刚地震后的一个月，Linda就去日本做了Keynote演讲，令人敬佩！

随后她去某日本大学请教关于日本人长寿的秘诀，分享了两条给我们：

1. No word for retirement – 活到老，干到老。退休后为兴趣而工作。
2. 80% for every meal – 每顿饭只吃八成饱。

以下我一些流水账，以及我听的演讲中的要点：

Overall:

Reflect & Get inspired – Lean and Agile Conference总结

Actively contribute – sharing what I learned

Network & have fun

Fearless Change:

Evangelist

It’s about passion and learning

• Test the water
• Step by step
• Time for reflection
• Small successes

What people like

• Feed them (do food)
• See things from their points of view (personal touch)

Build grass roots (bottom up)

**敏捷之旅（Agile Tour）**是每年一度的非营利性系列会议，旨在把敏捷社区联系起来，系列会议分别在全球众多城市召开，从10月份开始到12月份结束前后历时数月。

敏捷之旅的主要目标是：

• 针对敏捷的大规模交流：我们在10月份的主要任务是，开展以开发实践为主题的“大众传播”。我们希望把这些内容传递到每一个有听众的地方，从而引起人们对我们新式专业方法的大量关注。
• **分享我们的敏捷愿景：**既然敏捷是与时俱进的，那么我们在为敏捷社区贡献我们的认识、阐释及理念的同时，要对各种新视野保持开放。
• **本地化增长：**促进敏捷领域在世界各地的领导力。
• **支持：**协助我们的同行及当地企业采用敏捷。

2013年，敏捷之旅已经步入第六个年头，北京的敏捷之旅活动也即将举办第四届。

敏捷之旅往届情况，请移步敏捷之旅中国官方网站。

应募条件（门槛很低的）：

• 身在北京
• 热心公益和社区活动，乐于为大家服务
• 具备团队精神，能够抽时间参加敏捷之旅组织者或志愿者的筹备活动，能够按时完成自己选定的任务

需要付出的：

• 时间
• 精力
• 金钱（这个不需要）！

你将获得的：

• 活动之前和期间免费培训的机会（敏捷相关或演讲技巧）
• 和志同道合的朋友们一起以敏捷的方式做事，从而深刻体会敏捷理念的机会
• 扩展自己的人脉
• 扩大自己在敏捷社区中的影响力
• 活动当天与讲师共进晚餐，一起讨论的机会
• 工资（我们是公益活动，好像真没有这个）！

组织者和志愿者的区别：

• 组织者需要一定的组织能力，最好能够在程序员的圈子中具备一定影响力
• 组织者需要平时付出更多时间和精力完成相关任务，志愿者需要付出的少一些，主要工作在现场协助组织者
• 组织者需要一起多多沟通，发表自己的想法和建议
• 其他的我还没有想到，:)

如果你对此感兴趣，很简单，发封邮件告诉我吧，我的邮箱是jiangxb@gmail.com，邮件主题为“<你的姓名> + <应募组织者或志愿者>”，正文中请包括以下内容：

• 姓名
• 公司
• 电话
• 想告诉我的话（为什么想参与到活动中啊，对敏捷之旅有什么期望啊，有什么好的建议和意见啊等等）

期待大家踊跃报名啊~~

《驱动力》 丹尼尔 平克

作者简介： 全球50位最具影响力商业思想家之一 TED大会演讲人，美国前副总统戈尔及白宫行政部门演讲稿撰写人 《纽约时报》《哈佛商业评论》《快公司》和《连线》等知名杂志撰稿人

本书一共分为两大部分：

1. 第一部分介绍驱动力3.0
2. 第二部分介绍驱动力3.0的三大要素，也是本书的一个核心：自主（autonomy），专精（mastery）和目的（purpose）

本书也引用了许多试验，案例，非常推荐的一本好书。

开篇：哈利哈洛与恒河猴实验 德西与索玛立方块（Soma puzzle cube） 机械劳动（推算型工作） 创造性劳动（探索型工作）

第一章： 微软百科与维基百科的对比 驱动力1.0假设人类是生物体，挣扎求生 驱动力2.0假设人类同样会对环境中的奖励与惩罚做出回应 驱动力3.0假设人类同样有第三种驱动力——去学习，去创造，去让世界更美好的动力

第二章： 汤姆索亚效应（Sawyer Effect） 蜡烛难题（Candle Problem） 惩罚负效应实验（以色列某托儿所接孩子迟到罚款的实验）

“如果-那么”型奖励 作为条件提供的奖励，比如“如果你做这个，就能得到那个”。对于重复性工作（机械劳动）来说，“如果-那么”型奖励有时会有效；对于需要创造力的脑力劳动来说，它们必定弊大于利

“既然-那么”型奖励 在任务完成后提供的奖励，比如“既然你把工作做得这么出色，我们来表示表示吧”。“既然-那么”型奖励尽管使用起来需要技巧，但它对非重复性工作（创造性劳动）的危害没有“如果-那么”型奖励大。

1. 确保内部公平和外部公平

2. 报酬要高于平均水平

3. 考核标准衡量因素要广

第三章： A型人中日摇旗呐喊，手舞足蹈，像是得了“匆忙症”，而B型人在生活中似乎很少匆匆忙忙，也不会因为自己的愿望而显得有敌意。 道格拉斯 麦格雷戈的XY理论：X型理论假设，人类会逃避努力，只为金钱和安全感工作，因此他们需要被控制。而Y型理论假设，对人类来说工作与游戏和休息一样自然，主动和创造随处可见，如果人们投身于某个目标，他们就会寻求责任。

唤醒积极性的9大策略：

1. 给自己来个心流测试

2. 首先问个大问题：“你的那句话是什么”（人生使命，愿景之类）比如亚伯拉罕林肯（他维护了统一，解放了奴隶）

3. 再问个小问题：“今天的我比昨天更优秀吗”

4. 来次施德明吧

5. 给自己做一次绩效评估

6. 不想被卡住？读张卡片吧

7. 5个步骤离专精更进一步（刻意练习，deliberate practice——为了改善在某个特定领域的成绩而进行的长达一生的努力）佛罗里达州立大学心理学教授安德斯 埃里克森提出的这一概念 1. 记住，刻意练习的目标是提高成绩 2. 重复重复再重复 3. 想方设法获得批评性意见 4. 严加关注自己的弱项 5. 为身心俱疲做好准备