交付还是交代

了解过Scrum的同学，或拿到 Certified Scrum Master (CSM) 认证的同学，应该都知道Scrum是一个框架，3-3-5-5，分别是：

• 3个角色
• 3个工件
• 5个事件
• 5个价值观

然而这里面有很多重点，或可能被人忽略的地方。

今天要反思的一个点是我最近1年的感悟，即交付。

什么是交付

交付不仅仅是交出答案，而更应该是有“响”，即付出有对应的回报（最直观的回报，可以用金钱衡量，或可以和金钱挂钩的度量）。

举个简单的例子：比如我们要开发软件中的一个特性（feature）。

如果只是完成了开发和对应的测试工作，（或甚至有的只完成了需求分析或设计文档工作）那么这个时候的特性，无法使用，也不能为团队带来直观的回报。
可能团队会很辛苦，996，天天加班。但作为没有办法度量结果的团队，只能说他们有了交代，而不是交付。

什么是真正的交付呢？

交付指的是，特性真正完成，可以交付给客户使用。由此，客户（以及用户）的问题得到真正的解决，并且变得很高兴。然后团队也变得很兴奋。（当然，客户变得高兴之后，从长远看，收入也会变得顺畅）。

我们要选择交付还是交代

答案毋庸置疑，但往往我们会局限于自己的视角，以为我们选择的是交付，而实际是交代。

我们可以尝试通过如下的问题，来检验是否是交付：

• 这个工作对于客户的价值是什么？
• 这个工作是否解决了客户的某个问题？
• 这个工作是否节省了客户的时间或金钱？
• 这个工作是否帮客户带来了更多的用户？
• 还有更多的问题吗？欢迎一起来探讨

赶快扔下那些交代，一起来专注于交付吧！

想要学习 CSM敏捷认证，一起来报名吧！

关于Bob Jiang

BoB Jiang

• HiBlock区块链社区（hiblock.net）发起人
• 中国北方的第一位CST（Certified Scrum Trainer）
• 国内的敏捷（Agile）大咖
• 敏捷变革中心（Center for Agile Transformation）合伙人
• 敏捷一千零一夜社区合伙人
• 敏捷之旅核心组织者
• 《Scrum精髓》译者

最近听到有人说，敏捷就是快 - 快速发布，快速完成任务，甚至有人会问，这样快了以后质量有保障吗？那么我们先来看一下什么是敏捷。敏捷，英文是Agile，指的是敏捷软件开发。这里要特别感谢Alistair Cockburn博士给出的定义：

Agile is to deliver business value early and frequently.

敏捷是尽早频繁地交付商业价值。

这里，我们没有看到“快”这样的描述。

所以说，敏捷（Agile）本来就没有说要快速交付。那么敏捷到底是什么，为什么总有人说敏捷快呢？

我们一起来分析一下，假设有一个项目（比如说3个月的项目周期），分别由两个一样的团队（这里是假设，因为不存在两个完全一样的团队）来完成，（假设是A团队和B团队）A团队用传统的软件开发方法，B团队采用敏捷软件开发方法。那么由A团队来完成该项目，可能是3个月；B团队来完成该项目可能是3个月，或者更长。（这里忽略需求变更，人员变动等各种变数）这样看来敏捷软件开发并没有加速软件开发过程。那为什么那么多人说敏捷就是快，到底快在哪儿了？

敏捷的本质是反馈快！

我们还用上述的例子，如果是采用了传统软件开发方式，最终用户什么时间第一次看到我们开发出来的软件呢，基本上就是3个月后。而如果是采用了敏捷软件开发方法，最终用户最早可能是2周后（假设迭代周期是2周）就看到了软件。在用户看到软件并真正使用之后，他极有可能提出更多的反馈意见，也可能在使用过程中暴露出不同的问题。这些都是非常好的反馈，为后续迭代提供了方向（将会放入到产品待办列表中）。

除了反馈快，敏捷还有另外一个非常大的好处就是拥抱变化。在传统软件开发中，需求变化是非常难的（这里就不展开，想要了解的同学可以自行百度查询）。而在敏捷软件开发中，如果有需求变化了，直接就可以体现在产品待办列表中。唯一一点要求是不能改变当前迭代正在进行的工作！

如果您对本文有不同观点，欢迎和我微信交流：

如果您想要了解Scrum入门资料，可以点这里；如果您需要敏捷培训，可以参考这里。

Here I would like to talk about product backlog refinement meeting, including what activities should be in this meeting, who should join this meeting and why we need refinement meeting.

Why to have product backlog refinement meeting

As the figure above, it occurs during sprint for product backlog refinement meeting, and normally no more than 5% total time of sprint. E.g during sprint 1, Product Owner (PO) will conduct refinement meeting for sprint 2 and sprint 3. So refinement is like beam of a car, normally we should choose low-beam model, otherwise we would like to watch something far away ahead, we need to switch the headlights to high-beam model. Refinement is the high-beam model for team. (Thank Daniel Teng for above metaphor)

话题介绍- 商业模式探索工作坊：

当我们说敏捷，我们希望把事情做对；当我们说用户体验，我们希望产品能够得到用户的喜爱；而一个产品的成功，往往还需要第三个维度，它是否能够挣到钱？商业可行性对初创企业尤其重要。对商业模式的分析正是为了解决这类问题。这是一个风靡的名词，商业模式画布，帮团队在产品诞生初期可视化设计商业模式，再根据市场变化去调整。商业模式是否仅仅只是商业模式画布？不！真实的初始化过程，饱含假设，纠结，岔路，抉择。

意启部落小伙伴们来了，让我们来一起体验一个商业模式如何诞生。

工作坊中会涵盖：

- 产品网络图分析

- 画布分析

- 价值主张探索

- 画布迭代

- 商业模式假设验证

---

意启工作坊介绍：

    如果您还在用老的方式在创业、创新，寄希望有一个“好”点子砸到你的头上，然后一举成功，那你还没有开始就已经Out了。意启致力于帮助传统行业的创业团队利用颠覆性方法和流程加速孵化。目前意启正在帮助甜甜圈和会把奶牛帮两个传统行业的初创企业加速成长。同时，意启还学到的和体验到的总结并推出系列课程。意启目前关注的颠覆性方法和流程包括：Growth Hacking、病毒性传播、傆型(Pretotyping)、增长引擎、精益创业、引导技术、设计思维(Design Thinking)等。

12月20日，我们不见不散：报名地址