京东内部的敏捷项目管理模型

       对现在的互联网产品设计来说，尤其是对创业公司，是一个快速开发、快速验证的时代。团队工作方式如何应付快速开发和调整的节奏？敏捷开发（Scrum）给了答案。我们可以看看京东内部是如何进行敏捷开发的（内容根据pmcaff公开课整理而来）。

       价值为核心，透明、迭代、反馈和教练为基本点

       京东的Scrum模型中，有一个核心、四个基本点。分别是坚持以为用户提供价值为最核心、保持研发团队的状态和进度透明、控制对每个迭代周期的时间/资源限制、快速获取反馈、在敏捷转型初期，必须要有敏捷教练辅导。

      核心：价值--用户的问题是什么？

      时时刻刻思考用户的问题是什么？我为什么要做这个功能。目的就是在工作中一定要做有价值的事情。

      在实践时，为了保证这个问题，产品必须使用好产品待办列表的工具，好的产品待办列表有以下4个特征：

      排序的（Orderd）

      这里不同于日常工作中常规优先级排序，常规的优先级排序有个弊端就是对需求的先后定义比较模糊。比如有三个需求都定义为P0级重要需求，这三个需求哪个在前，哪个在后？

       但是在Scrum中，要求产品经理对每个需求根据价值进行排序，每一个需求都有一个唯一顺序。若是两者价值差不多，就以实现难度参考，越简单的越靠前。

       详略得当的（Detailed rightly）

       当前的迭代和下个版本的迭代需求必须很详细，再之后的迭代可以相对颗粒粗一些，最往后，颗粒可以越粗。

       每个需求的大小要得当，有个标准值是：一个需求一般是一个团队2-3天的量。

       动态的（Dynamic）

       待办列表内，除了当前正在迭代的需求外，其他所有需求都是可变的

       估算过的（Estimated）

       代办列表内所有需求都是团队一起估算过的。

       基本点一：研发团队的透明

       必须保证对研发团队的状态和进度透明，为此任务板是个很好的工具，尤其推荐物理的任务板。优点是所有人时时刻刻都能看到，成本低，操作起来灵活简单

       基本点二：对迭代时间和资源的控制

       对资源进行限制，达到低成本的进行产品验证。同时对每个迭代周期的时间也进行严格限制，一般以两周为一个迭代。两周后不管完成与否，迭代结束，结束后大家一起回顾和总结。

       对迭代周期的限制好处是每个周期内团队可以拿出真正的成果。

       基本点三：快速获得反馈

       在Scrum中，反馈是至关重要，因此推荐三个会议：

       每日站会：
       每日开始工作前，花出不超过15分钟的时间大家站一起开个小会。要点是：昨日完成了什么？今天做什么？工作中有什么问题？

      目的是让团队的所有人都了解其他人的进展，及时发现问题并解决。

      评审会议：
      迭代结束后，把所有利益相关人员聚在一起，让其他人体验并指出问题。可以的话，可以邀请最终用户，让用户操作，产品一旁拿纸笔记录细节。比如：用户操作时，在哪不顺畅，在哪用户表情有变化等

      回顾会议：
      定期团队开一次回顾会议，整顿工作，反思工作流程能否优化，最终产出可操作性的行动计划。

      注意行动计划必须是定义清晰，可操作性强的。不能抽象，比如出现类似“改善”之类的。

      基本点四：Scrum初期必须要有教练指导

      Scrum初期从内部或者外部寻找教练，指出日常工作中，哪些是敏捷、哪些是非敏捷、哪些才是正确做法等