在写完产品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. 大小合适的：

通常有人会问，在编写产品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.

最近看了一下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演讲，令人敬佩！ 随后她去某日本大学请教关于日本人长寿的秘诀，分享了两条给我们： No word for retirement – 活到老，干到老。退休后为兴趣而工作。 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大会演讲人，美国前副总统戈尔及白宫行政部门演讲稿撰写人 《纽约时报》《哈佛商业评论》《快公司》和《连线》等知名杂志撰稿人 本书一共分为两大部分： 第一部分介绍驱动力3.0 第二部分介绍驱动力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.

整体印象：2012年目标完成的比较差，如下图： 我的2012总结分为以下几个方面： 健康 工作 家庭 社交 读书 其他几个方面在2012年初没有做计划，就不一一总结 健康 这一项只能打4分，2012年初体重77kg，到了现在超过80kg了。即没有达到年初的计划减肥5kg，还继续增重这么多，不可原谅啊。 分析：自从孩子回家后，体重呈现直线上升趋势。 2013： 增大运动量，尤其跑步和快走为主。 工作 工作当中主要有两大块，项目和推广敏捷。项目只能是完成预期目标，部门内推广敏捷花了比较大的力气，获得一些成果。但仍然有提高的地方。例如，工作成果没有可视化或者很好的宣传。 分析：更多的时间花在推广敏捷上，项目开发受到影响。 2013：在项目上花更多的时间。敏捷推广上要注意方式方法。 家庭 2013年是值得纪念的，可爱的宝宝今年来到我们身边。尤其是极低体重的早产儿，我的爱人和家人都付出了非常大的时间和努力。 分析：宝宝非常可爱，每天都有新变化。让我的生活丰富多彩。 2013：除了和宝宝的爱，还要更多和爱人及家庭多沟通，多一些时间相处。 社交 社交方面，今年认识了更多做敏捷的朋友，在敏捷社区也认识了更多各地的敏捷之旅组织者。 Toastmaster方面，2012投入的精力比较少，在2013需要更多的参与活动。 分析：敏捷之旅北京站的组织，给我一个非常好的锻炼机会。 2013：更积极的参与到敏捷社区活动，敏捷中国和ScrumGathering分别投稿。 读书 未能达到目标，读书20本，只读了12本。 分析：宝宝的到来，占了不少的休闲时间。使读书、学习时间也变少。 2013：新的一年，计划读书12本，集中于心理学、时间管理和敏捷相关