如上图，开始之前我们假设产品backlog做过第一次梳理，并且总的故事点为127.  0. 在迭代开始之前，需要有一个产品backlog，并且其中顶部的一些故事是相对更详细的。  1. 产品backlog需要符合INVEST标准（参见我的一篇博客）。为了达到这个标准，需要产品负责人（PO）和团队一起（早期有可能是团队代表或核心人）对产品backlog进行优先级排序，估算（有故事点估算、团队估算、三角估算等方法）等梳理工作。  2. 假设我们有一个产品backlog如附件所示，每个sprint为3周，第一个sprint团队计划完成21个故事点，基于以上假设，这个项目需要6个sprint完成，即6x3=18周时间  3. 当第一个sprint结束的时候，很不幸，团队只完成了14个故事点。那么需要基于这个事实，对于发布计划进行调整。需要10个sprint完成，即10x3=30周时间  4. 如果第二个sprint完成了18个故事点，则基于第一个和第二个sprint的数据，发布计划调整为8个sprint，即8x3=24周。此时，由于有了2个sprint的数据，我们可以对发布计划的承诺是在24周（最好的情况下）~30周（最差的情况下）之间。  5. 如果第三个sprint完成了20个故事点，则基于前三个sprint数据，发布计划调整为7个sprint，即7x3=21周。此时，由于有了3个sprint的数据，我们可以对发布计划的承诺是在21周（最好的情况下）~30周（最差的情况下）之间。  以此类推，一般来说，我们都是在3个迭代之后，对项目的发布计划做出承诺的。  \================================================================ 欢迎大家提出其他不同的版本规划方法，或者建议。谢谢！ -———————————————————————- 微信公众号: 敏捷那些事儿（agileplus） Agile1001公开课，每月一次，旨在推广和传播敏捷开发思想和Scrum，希望更多的开发者受益。欢迎关注。课程信息会定期发布，敬请关注。公开课汇总链接。

主管领导经常宣扬敏捷，但他们真正了解什么是敏捷吗？当然，敏捷增加了协作，提高了透明度和响应变化的能力。谁不喜欢呢？主管们所了解的是，敏捷转型只影响Scrum团队。下面让我们看看对于组织而言敏捷是什么： CIO - Chief Information Officer 传统的资源模式受到冲击。Scrum需要团队奉献精神，构建高效能团队和可靠的开发节奏（速率）。为了支持这个观点，你需要确保有价值的工作稳定产出。这需要真正的协作。 基础架构需要支持持续集成和频繁发布。开发、运维模式（dev ops），这是一种很好的方式。 敏捷转型可能需要几年时间，因此Scrum团队最大的挑战是瀑布式接口。Scrum团队快速前进并交付需求中更大程度上的不确定性，对瀑布式组织而言这意味着不熟悉的领域。接口协调就应运而生。 HR - Human Resources 需要定义新的角色和职业生涯：ScrumMasters，产品负责人，教练，和敏捷推动者。 _绩效评审_流程也受到冲击，奖励的是团队成功而不是个人成就。 有些组织通过重组或者管理层的扁平化，来引发文化的变革和授权团队。HR也不要是敏捷转型的一份子。 CFO - Chief Financial Officer 开始敏捷之后，经费从项目转变到团队经费。这个例子中预算就简化了。财务领导需要知道的是_范围不确定性_的尺度。这需要相信，团队和产品负责人会做出正确的决策。 组织开始关注业务价值而不是节约成本。从没听过Google吹嘘在员工身上省了多少钱；但听到的都是他们的创新和优秀的精英。 下一步，不要忘记为敏捷的开销留出预算：培训，教练，工具。 对财务领导还有一点是：需要为研发类型或创新实验室类型工作留出预算，团队需要寻找经费来验证一个想法。这不是对每个团队都适合的，但肯定适合新兴产品。财务的敏捷性会帮助整个敏捷转型。 COO/CMO/CEO - Chief Operating Officer/Chief Marketing Officer/Chief Executive Officer 敏捷之后业务人员的参与水平显著提高了。产品负责人不仅需要是专职的，还需要知识渊博以及授权他们做出产品决策。换句话说，业务的角色从项目经理层面转变为真正的产品所有权。企业需要一个清晰的愿景和创新推动力来支持产品负责人。成功的产品负责人真正只需做好2件事：向组织看起和权衡。设定“正确的”产品负责人会让项目获得极大成功。 项目管理办公室会发生文化改变，授权团队，或影响现有的审核流程。跟踪敏捷项目的指标是不同的，更关注于价值而不是生产效率或成本。新的标准和组织结构会慢慢浮现，比如Scrum of Scrums。PMO通常在开始大规模敏捷后才收到冲击。 物业也会被团队坐一起的需求所影响。如果没有足够的协作空间，Scrum团队就会占用会议室。 原文链接：https://www.scrumalliance.org/community/articles/2014/january/is-your-leadership-ready-for-agile

Agile1001第三期公开课，再次迅速降临北京！感兴趣的同学请于后台回复报名 报名格式： 中文姓名、手机、公司 题目：【实战工作坊】敏捷需求捕获By用户故事 地点：望京附近，近地铁15号线出站口，为防止空降，具体地址另行通知。 内容：据Standish Group分析，在项目失败的原因中，有近7成是跟需求相关的。如何在敏捷的背景下有效的分析、捕获需求，是实施敏捷软件开发的第一要素。本工作坊试图通过理论讲解加上实战演练，让听众掌握如何通过用户故事(User Story)来分析、描述、估算一个需求，进而管理多个需求。 本工作坊同时覆盖如何区分用户角色，如何描述一个用户角色，如何做敏捷估算，如何划分需求优先级，如何做发布规划等进阶内容。 时间：2014年1月19日下午2:00 - 5:30 讲师：王立杰，因著有《敏捷无敌》，江湖人称“无敌哥”，多年软件研发与敏捷实施经验，曾为阿朗、爱立信、诺基亚、VMWare、E人E本、百度等多家公司做过各种敏捷培训或咨询；曾经在“2011 Scrum Gathering，“2011 AgileChina敏捷中国”等大会做过多次演讲；曾在《程序员》杂志上发表多篇敏捷相关文章，是敏捷之旅的志愿组织者，Agile1001公开的发起者。

_译者注：回顾会议是敏捷的核心，在敏捷原则最后一条中提到“团队定期地反思如何能提高成效，并依此调整自身的举止表现。” 对于团队如此，个人何尝不是呢。作为一个上进的人，需要时刻反思如何改进自己，调整自己的行为，向着自己的目标前进_。 回顾会议变得很无聊，或者只产生几点改进意见、做的好的地方，这是很普遍的。下面介绍一个对我的团队很有效的方法。这个方法不是说比其他方法更好。只是为回顾会议提供一个新的尝试。 首先，先说明一下为什么我想改进回顾会议。全组人（除了PO，通常是代表客户的）坐在一起，比较随意的开始提出一些想法，在这个sprint中哪些事情做得好（正面的）以及哪些地方做得不好（负面的）。所有人说完后，我们开始为每个负面因素至少制定一个行动计划，并指定一个人负责。一旦行动定好了，会议就结束了。 这看起来就是一次普通的回顾会议。不好也不坏。但是，不难找出其中的一些缺点： 人们通常忘记了在sprint中哪里做的好，或哪里做的不好。让人们在2个小时内想起一个sprint内所有事情，这是不现实的。 有些人不愿意当面提出问题。因此回顾会议上他们压根不说话。 团队创建的行动计划，但是如何跟踪，以及团队如何能想起来这些行动？ 为了解决这3个问题，我们创建了一个回顾会议墙。墙上有3列：正面（Positive），负面（Negative）和行动（Actions）。如下图所示。 在正面（positive）一列，团队成员可以在任何时间粘贴他认为好的事情。不一定要署名。类似的，在负面（negative）一列，团队成员说明从他的角度看哪些做的不好。行动（actions）一列贴着所有未完成的行动。行动卡片包含描述、何时创建的、以及谁负责跟进。一旦行动完成了，负责人在卡片上写明完成日期。 除了这3列，还有2个格子记录了上2个sprint中的行动完成百分比（已完成数/总行动数）。因此团队可以很清楚的知道他们是否改进了。重要的是：任何指标，都需要中肯的分析，而不能简单的认为它好或不好。 几个sprint之后，我们发现正面和负面问题的数量和质量都得到改善。如果你决定采用这个方法，请记住以下要点： 板（或者墙）是每个人都很容易看到的地方，这样团队每天很容易就会看到进展。 一开始，要告诉每个人我们的目的是什么。比如，在回顾会议之前，每人必须提出至少一个正面和负面的意见。这好像有点强迫，但这样可以告诉团队如何形成习惯。 树立榜样。一旦你发现团队中有好的或不好的地方，立刻在墙上贴一个便签。发现了问题之后，马上贴上去，这很重要。 https://www.scrumalliance.org/community/articles/2014/january/retrospective-wall-board

感谢Shining的美图。非常感谢各位热衷于敏捷开发的朋友参加公开课。 大家的反馈： huiminer 18:06 感谢Bob，王老师以及大家的分享哈～ 范x 18:07 感恩大家 闫x 18:25 今天收获还是很大的，非常感谢立杰老师百忙之中为大家联系的场地以及Bob精彩的讲课。看到大家非常投入的讨论敏捷，感觉很象个大家庭，个人有个小提议，我们以后时机成熟时可以成立个敏捷之家的论坛，这样大家也可以平时把问题提出来，共同探讨交流，再定期组织面对面会议，因为北京太大了，毕竟大家东南西北聚一起一次也很不容易。 闫x 18:26 今天收获还是很大的，非常感谢立杰老师百忙之中为大家联系的场地以及Bob精彩的讲课。看到大家非常投入的讨论敏捷，感觉很象个大家庭，个人有个小提议，我们以后时机成熟时可以成立个敏捷之家的论坛，这样大家也可以平时把问题提出来，共同探讨交流，再定期组织面对面会议，因为北京太大了，毕竟大家东南西北聚一起一次也很不容易。 一米阳光 20:51 感谢大家的分享！ 兔子 20:57 今天Bob和王老师辛苦啦![抱拳] 黄x 21:47 感谢bob和王老师给我们提供了这么好的公益课，希望以后能继续组织下去。感觉大家今天讨论的意犹未尽，希望以后可以组织一些专题的分享和讨论，深入某些焦点话题，希望大家碰撞出集体智慧的火花。 春儿 21:49 很获益，谢谢王立杰和Bob给大家创造的机会，也感谢热爱公益的敏捷爱好者们。 Light Cavalry 21:50 谢谢王老师，bob和小伙伴们，引发很多思考和讨论，加油[表情] ppt可以从以下途径下载 https://www.slideshare.net/bob_jiang/agile1001-open-course-1 （需要翻墙） https://www.360doc.com/showWeb/0/0/344800686.aspx https://www.docin.com/p-754177054.html 合影 -———————————————————————- 微信公众号: 敏捷那些事儿（agileplus） Agile1001公开课，每月一次，旨在推广和传播敏捷开发思想和Scrum，希望更多的开发者受益。欢迎关注。课程信息会定期发布，敬请关注。公开课汇总链接。

译者注：本文虽然是在辩解“sprint评审会议”和“sprint演示会议”的字面含义，但需要更深入了解其背后的原因，这其实才是作者的初衷。 （sprint评审会议=sprint review；sprint演示会议=sprint demo） 几乎每周我都会拜访一到两家公司，在现场教Scrum课程或者进行敏捷指导。最近，在上课前参加敏捷培训的人很可能有一些Scrum经验或（通过书或视频）接触过——大多数情况下，这是件好事。 但我得吐吐槽。当人们把“sprint审查会议”实践当做“sprint演示会议”或只是“演示”的时候，我是有所担忧的。这看起来只是一个语法问题，然而把评审叫做演示的结果是，它破坏了sprint评审会议的真正目的。 尽管演示是sprint评审会议中很有用的一部分，但这不是评审会议的目的。sprint评审会议最重要的方面是深度交谈和参与者之间的协作，以及使产品知识浮现出来并开发。 已经构建好的内容演示，只是一种激发围绕具体事情交谈的、非常有效的方式。而忽略了关于产品是如何工作的交谈。 下图会澄清我是如何看待sprint评审会议活动。 在图的中间，你会看到sprint评审会议图标。这个活动的关键是检视与调整sprint过程中产出的产品增量。这个图标的下边你会注意到一种举办sprint评审会议的方法。 第1步是回顾sprint目标和承诺的特性集，并和实际完成的进行对比。第2步是演示和讨论完成的特性，并对产品backlog或者发布计划做出必要的调整，以反应讨论中新的认知，然后重复这个步骤。这个循环直到所有完成的特性讨论完才结束。 在这个方法中，演示只是sprint评审会议中的一个活动，它不是sprint评审的目的。这就是为什么我认为这个很重要，应该叫sprint评审会议，而不是sprint演示会议。 再次重申，sprint评审会议的目标是检视与调整构建的产品。成功的评审结果是双向的信息流动。不属于Scrum团队的人也可以得知开发的成果并帮忙指出方向。 同时，Scrum团队成员通过频繁的反馈而加深了对产品的业务和市场认识。所以，sprint评审会议是一个检视和调整产品的预定机会。 应该叫做sprint评审会议，而不是sprint演示会议，对于这个观点，您同意吗？请留下您的建议。 原文链接：You can view the original content here. 原文作者：Ken Rubin 译者：姜信宝Bob Jiang

本次回顾会议，采用的是焦点汇谈法（ORID），具体方法介绍参考链接。 下面是会议之前收到的一些反馈： 【在回顾会议时忘记和大家同步了:(】 1. 话题收集，可以考虑提前半年开始准备。 2. 场地有些窘迫。 3. 希望和演讲嘉宾有后续的交流 4. 海丁报名信息有点乱 5. 定期的微型实践活动，类似伍斌的代码操练，以此为大型活动提前预热 6. 主题分类、嫌弃通过咱们来组织，逐渐和企业联合，培养企业级用户 7. 采用互联网思维，免费、渠道、规模和自维护 8. 希望以后能有个固定的据点 9. 内容强度挺大，下午的分享形式上互动多一些 10. 整个活动中，对参与者的引导不够，大家都在尽力，但有些地方成为真空区域，尤其是洗手间的环节。 11. 收集参与者的反馈，我们需要反思为什么没人愿意来写下意见。 12. 结束的时候，三个会议室没有统一。有的会议信息只有主会场的参与者知道。（比如最后的分享途径） 下面是今天回顾会议的简单记录： 客观事实： 总结出几点为 1. 演讲嘉宾内容丰富，尤其以伍斌、王明兰和李忠利的分享突出。 2. 对创新工场的环境很满意。 3. 志愿者都很热心，积极。 下面是具体的： 演讲嘉宾选择 收尾匆忙（视频发布） 明兰的游戏 会场的安排，加强 第一次开会，很多道具，便签，海报纸。 谢钊对于关键时间点的把控 小泽的海报，很出彩。 黄喆很热心。 布航夜班后，直接参加开会。 伍斌的coding dojo粉丝很多 李东对自己的收获。 午饭后，座位上的垃圾盒，和小橘子 时间安排紧张； 会后ppt的总结，（宣传的不够啊）会上提前通知 演讲嘉宾分享水平和内容 热情高涨；预演排练不够充分 人比较坦率。 四惠太远了。 王立杰，Julie的话题很喜欢 程序员很喜欢编程操练（提前统计人数） 创新工场会议室、办公环境 黑板报，洗手池很震撼 百度的分享 明兰的分享 伍斌的分享 缺少一个整体进度，蓝图的东西。 需要一些延续性的内容。（微博，微信宣传） 第一次志愿者会议 分发午餐的时候，很忙 很高兴的事情，在工场布置圣诞氛围 晚上聚餐的时候，大家聊的很开心 伍斌和明兰的分享 应用PDCA；制定计划，及时反馈； 如何跟大牛学习；（不要事事去问，而是观察大牛是如何做的）（无政府和自组织）

提到产品管理，在Scrum中，首先就想到的角色是产品负责人。因此我们先来看看产品负责人（Product Owner），以及这个角色的特征： 预言家和实干家 领袖和团队成员 沟通者和协商者 授权和承诺 时间充足和胜任工作 然后对于大型产品而言，一个产品负责人是不够的，所以存在产品负责人扩展的问题。有以下几种： 首席产品负责人 产品负责人的层级结构： 对于产品负责人，常见的问题有： 产品负责人不给力 产品负责人的工作超负荷 产品负责人的角色被割裂 远距离的产品负责人 代理产品负责人 Kano model （卡诺模型）可以帮助我们选择合适的功能，开发出吸引人的产品。 产品Backlog梳理的步骤： 发掘并记述新的条目，根据真实情况改变或移除已有条目。 按优先级对产品baclog排序。将最重要的条目放在顶部。 为接下来的sprint计划会议准备好高优先级的需求条目，对其分解和细化。 团队估算产品backlog条目的规模，添加新条目到产品backlog中，改变现有条目，并修正必要的估算。 对产品backlog按优先级进行排序，如何排序？由于单个产品backlog条目可能非常小，难以按优先级进行排序，因此最好先对主题进行优先级排序。然后，我们再对主题内或跨主题的条目按优先级排序。排序所涉及的一些影响因素：价值；知识、不确定性和风险；可发布性；依赖性。 评估需求条目的方法有：故事点，可以使用的工具：计划扑克。 产品负责人的六大罪与责：

前几天听到一个故事，“把书包扔过栅栏”。意思是说，把你的书包扔过高高的栅栏后，你就会想尽一切办法翻过栅栏，去把书包找回来。 这个故事的隐喻是：如果对于做某事有想法，那么就把想法说出来，说给尽可能多的人听，这样你就会有动力去实现这个想法。（公众压力） 昨天，我也终于把书包扔过了栅栏，参见Agile1001敏捷公益课#1——敏捷和Scrum角色介绍。 今早在网络上查了一下，有关这个故事还有另外2个版本（但中心思想是一致的） 1. 在《演讲达人成长记》中，Alex Cheng提到的“把戒指扔过栅栏”。 2. 在褪墨的博客中，有一篇《学会把帽子扔过栅栏与风险控制》。以下是关于帽子的故事——“把帽子扔过栅栏”摘自《女子文摘》2006年04期： 一天，在教堂义卖翻找捐赠品时，偶然发现了一个盛着一套模型船元件的盒子。那是多年前一个朋友送给我的，到现在还没有打开过。由此我想起了一些我本该做而一直未做的事情。想我这样遇事不果断、办事拖拖拉拉的人终归难成大事。 我把盒子拿在手里翻来覆去的看，脑海里浮现出父亲年轻时所拥有的一只真船——“迪克西”号，我从未亲眼看见过他那只心爱的真船——但我们家的相册里有几张发黄了的照片：父亲站在他的船上，紧挨着船轮，神气十足。在过去很长时间里，我不知道这只漂亮的白色摩托艇究竟到哪里去了。但我长到10多岁时，有一天父亲极力劝导我做一件我一直逃避干的事情，他说：“把你的帽子扔过栅栏那边去。” “我不明白您的意思。” 他笑了起来：“当你面对一排难于翻越的栅栏时，先把你的帽子扔过去。然后你就不得不想出到达栅栏那边去的办法来。”他一边笑，一边回忆着往事，“我就是采取这样的方式来芝加哥的。” 父亲在威斯康星州的拉辛市长大。拉辛在芝加哥北面约60英里处。我曾感到疑惑的是，他是如何离开家庭和亲友，置身移居到这个大城市的。 “当时我刚刚20岁。”他说，“除了那只船外，我一无所有。一个夏天的早晨，我包了几件自己的衣服，驾起‘迪克西’向南开去，一直驶进芝加哥的贝尔蒙特港。”第二天，我就进城去找工作。工作很难找。我差一点放弃梦想，调转船头家去。但我‘帽子扔过了栅栏。’“他叹了口气，接着说：“我卖掉了‘迪克西’。我要想在芝加哥扎下根，总得有一笔钱。没有了船，我也就没有了退路。” 后来的事我都知道了：他在爱迪生集团谋到了一份工作；在一个舞会上认识了我母亲;终于在芝加哥发了迹，过上了富裕的生活。但我尤其不能忘怀的是父亲的经历所给予我的启示：投入才能成功。 父亲卖了“迪克西”后，他没有了别的选择，只能把全部能力倾注在为自己创造新生活上。这个道理也为我们生活中无数其他类似的情形所证实。当你做出某种果断的举动后，就已把自己置于一种成败未卜的境地，这时你不得不想尽一切办法“翻越栅栏。” 例如，我妻子贝蒂和我早就想把我们的起居室油漆一下，可就是老拖着不动工。终于贝蒂“把帽子扔过了栅栏，”她说：“我已经邀请了一些朋友星期日晚上来我们家吃茶点并参观我们的起居室。”于是家里很快买来油漆，两天后屋子就焕然一新了。 我们房子的前主人为了把卧室的一个窗户改成壁橱，就从外面把窗户封堵了。贝蒂和我念叨了好几年，说要把那假墙拆除，以改善室内的光线。但这“工程”对我们来说似乎太艰巨了。后来我弟弟赫布，这个热心而又会干活的小伙子，来我家拜访时听到了关于窗户的事。他先在假墙上钻了个窟窿以示马上动工的决心。“小菜。”他肯定地说。使我惊讶的是，他说着就麻利地从窟窿处撤下一块墙板来。我和小儿子基特也动手和他一起干。天黑以前，一个雅致而又明亮的窗户再次出现在我们卧室的墙上。完工了，我们才知道这活儿的确很简单。我们原先想象得太复杂了。但如果不是我弟弟替我们把帽子扔过来了栅栏，这工程不知还要拖到何年何月呢。 今后当你碰到似乎很困难甚至看上去不能办到的事情时，不妨也把你的帽子扔过栅栏去，哦，你问我在我家阁楼上发现的那盒模型船元件怎末样了？当时我儿子彼得一家打算过几个月就搬家，我把帽子扔过了栅栏，答应儿子马上把模型船组装起来，然后把它作为乔迁的礼物送给他。 我组装好了那只船，我儿子一家非常喜欢它。

自从2001年敏捷宣言以来，全球各地都在传播和推广敏捷。但为什么使用敏捷，具体在什么场景下可以使用敏捷，以及敏捷到底能解决什么问题，诸如此类的各种问题仍然在困扰着很多开发人员。而Scrum又是什么，它能否解决软件开发中的问题，也同样令人头疼。 2014年1月12日下午2:00-5:00在这次敏捷公益分享中，将包含以下内容： 为什么使用敏捷 什么是敏捷 敏捷能解决哪些问题 爱立信的敏捷之路 什么是Scrum Scrum中的角色有哪些 …… 我是姜信宝 （Bob Jiang），我的博客https://bobjiang.com 我喜欢新鲜事物，喜欢读书，喜欢分享。愿意和大家共同进步。 正在翻译Kenneth S. Rubin的《Essential Scrum》 联系我：jiangxb@gmail.com 新浪微博: @姜信宝Bob 微信公众号: 敏捷那些事儿 敏捷公益课，每月一次，旨在推广和传播敏捷开发思想，希望更多的开发者受益。欢迎报名。课程信息会定期发布，敬请关注。