需求又要改？
项目上线时间又提前了？
老板还嫌增长不够？
团队都开始灰心丧气了？
来看看京东内部是如何解决这些让人焦头烂额的棘手问题。
两次失败之后成功支持双11活动
京东每年两次大的的促销活动中都会邀请第三方商家来加入京东的促销活动。在没有新系统之前，执行的方式简直是惨不忍睹啊。全部人工线下组织并手动要求第三方来报名，一个运营人员面对几百个商家通过电话确认商家是否参与本次促销，有怎样的商品参加促销，并要求对方商家发送一份Excel表格给京东再做统计。
于是就产生了一个很自然的需求，所有的商家如想要参加京东的活动，只需要在这套系统上提交一下自己的信息和商品就可完成——即活动管理系统。
你以为就这么一番风顺的投入研发，上线产品，成功支持双11活动了？
Too Young！Naive！
一波三折
为了配合促销活动，项目从开发到上线被要求在两个月内完成，于是研发们开始了疯狂的加班之旅。但运营人员在使用系统进行活动发布的时候，发现只能解决一半的问题，剩下的很多工作还是需要手动去完成，甚至根本没法使用（连续两次出现）。而研发团队也在反思为什么自己做的系统，无法达到运营人员的要求呢？这该怎么办？
盲人摸象的教训
团队第一步首先要做的就是分析一下这个系统——到底是谁在用。而解决这个问题的前提是：需要了解你的用户是怎样操作，怎么使用，怎么工作的。经过研究之后，会发现前两次的研发都是接到用户需求之后，就开始着手进行了。虽然辛苦工作，但是没有了解业务场景，没有了解用户怎么使用软件。
痛苦蜕变后的成长
得到了敏捷开发的指点之后，团队开始听痛点，分析谁在用，了解使用场景。并采用小版本迭代，边做边调整，提高和促成团队的高度合作，并且还想了一个对策：把具体操作人员（如运营人员，业务人员）聚在一起，并找了其中几个代表，让研发人员坐到他们旁边，看他们一天是如何进行手动操作的，如何收集第三方的活动，如何和第三方联系等等。
成功支持双11大促
为了杜绝类似的失败再次重演，我们又劝说运营人员派出一个代表来到研发部门，坐到研发人员当中去。这样的好处是能实时定位问题，比如，商家是需要提交这些字段或者数据的，并且研发刚一开发完的功能，马上就可以让运营部门的代表当即操作测试，检测看看是否是运营人员想要的。后来项目圆满完成，极大促进了促销活动的效率。
秀一张刘老板的邮件来证明一下哈哈。
90天内两个上市公司顺利融合，业务同步增长10倍
今年5月份，京东发布了一条重磅消息：战略入股途牛。因为途牛在OTA这块拿的代理折扣都很低并且服务完善，所以用户在购买这方面东西的时候，都愿意在他们的网站上进行。合作的结果就是大家在京东上搜索度假或者旅游产品，大部分都来自于途牛。
三步迭代，快速开发
因为开发时间只有两个月，团队开始尝试增量开发的方式。时间上划分成3个迭代加上1-2周的回归测试，我们将需求划分为三个等级，在第一个迭代阶段重点解决重要紧急的需求；第二迭代处理或优化一些功能上的需求；而其他需求摆放在第三迭代里。
具体来说第一个迭代我们只完成了商品详情，下单和支付功能，而第二个迭代里，我们加入了列表页功能，价格日历功能；而在第三个迭代里，我们加入了搜索功能。团队协作上引入了Scrum的模式：每天几个团队的leader或者项目负责人就当天出现的问题进行过滤，进行到什么阶段，该项目或内容谁应该跟进，出现的问题什么时候给出反馈等等。这使得团队的状态十分的透明化。
美剧《硅谷》中也提到了Scrum敏捷开发
上线时间被提前？当机立断砍需求
在第二次迭代进行的时候，出于配合大促销活动的考虑，上线日期被提前了，项目开发周期被缩短两周左右时间。因为第二阶段的迭代已经开始，且无法进行变更了，于是团队开始迅速调整，看第三个迭代的事情有哪些是可以拿掉的。最后砍掉了一些不太重要的需求（如一些优化、一些操作方便性的东西），从而保障了促销活动顺利进行。90天里完成了多项业务分支的融合，并且GMV（商品交易总额）同步增长超过10倍！
根据上面亲身经历的两个例子，我总结出一套转型模型来分享给大家：
转型模型：一个核心价值，四个基本点
讲模型之前需要提醒大家的是：不管做什么都会有一个模型，模型就是我们从实践中总结出来的，可能是有效的但也可能是无效的套路，且需要不断的去验证不同的场景下的可行性。
如何定位最关键最有价值的事情？
软件开发中最关键的地方在于【要解决最核心的问题】，而找对用户最核心的问题是什么就是最有价值的事情。这里提供给大家一个非常方便的方法——产品待办列表。
教你使用一份好的产品待办列表
唯一排序（ Ordered）
还在使用传统的方式（根据重要和紧急程度划分）搞需求的优先级？一旦出现异常情况，就会立马完蛋。分来分去其实仍旧不知道该【先】做哪个！因此记住一个重要的原则！即【唯一排序】，一定要排列出唯一的先后顺序。而遵循的排列准则第一个就是：价值。按照价值高低来排序，这样就会使得优先完成的一定是价值最高。
详略得当（Detailed Rightly）
需求也要分详略。对于开发成本只有两三天的需求，应该拆分到比较小而详细，对于需要一个月或者更长时间的需求，则不需要那么详细。不要求把所有需求都写入需求文档中——这样的做法是无用的，快速迭代的当下，很多东西是在变化的，因此需要详略得当。
动态可变（Dynamic）
突然又要加需求了怎么办？很简单，直接加入当前的代办列表中。由于后面的代办事宜还没开始制作，加入一个新需求并不会有任何影响，后续的需求排序是可以随时调整，哪个价值更高，可以调整前置。简而言之，内容方面发生的变化，要对其进行估算；验收条件发生变化，要对其进行更新。除了当前正在执行的需求是不能改变的之外，往后的需求都是可以改变的。
大小可估算（Estimated）
需求怎么估算大小？根据实现成本和价值两个维度来估算，相同价值的需求当然先去消耗人月少的需求，如果很难估算的话就要考虑是不是需求没有想清楚，没有进行拆分，拿出你想清楚的部分，再将其拿到前置位置。 成本也很重要，如果没有将核心和需求处理好，后期的敏捷实践很可能仅仅是皮毛。
牢记四个基本点
透明——暴露团队的所有细节
软件开发很多东西不是透明的，举个例子：你问程序猿任务完成了多少？假设他自己计划这个任务需要2天时间。今天是第一天，当晚你问他这个任务完成的如何，他告诉你他现在完成了90%，你一定很兴奋，心想才两天时间，第一天就完成了90%，十分的不错。然而，第二天下班的时候，你再去问程序猿做完了么？他告诉你他完成了95%，这说明什么问题？完成的百分比根本不可靠！甚至毫无用处，很多细节藏于其中是你无法察觉和发现的。
所以，我们希望要透明。透明怎么去实践呢？很简单：任务板
用任务板把所有团队认为应该展现出来的信息都展示出来，都暴露出来。将所有需求及拆分出来的任务（开发的，测试的，待上线的等等），根据自己团队的实际情况，做一个任务板。
假如自己有一个便签贴在一个位置，三天都不动，那么团队其他人看见了，自然而然会来问你什么情况，你在做什么，三天你的任务都没有进展。用这种形式将团队进度都透明化。
迭代——盲目重复不可取
敏捷开发最重要的特点应该是：【迭代增量式软件开发】。迭代的字面意思就是重复，但同时要警惕盲目的重复，给大家提供一个盒子理论作为指导：
一个是时间盒：重复一件事情，要在时间限定的范围内，比如建议为2周的迭代形式进行，2周后就结束，并进行回顾和反思，并要拿出潜在可交付的软件。
另一个就是资源盒，即限定资源，相当于不要把所有的鸡蛋都一次性全部放在一个篮子里，小成本试错，快速迭代。
反馈——三个实践方法教你如何正确的反馈
在案例1中我们为什么把运营人员放到开发团队当中去？就是要实时的反馈。 Scrum之父Ken Schwaber说：Scrum就像你的丈母娘，不断指出你的问题在哪，错在哪，Scrum只是不断的暴露你的问题。反馈在敏捷中可以有三个实践方法：
（1）每日站会——每日站会中，每个成员都应该回答三个问题：昨天我完成了什么，今天我打算完成什么，工作中是否遇到什么问题并且不超过15分钟。
（2）评审会议——评审会议最重要的是有人给你反馈而不是无聊的演示demo然后鼓掌散会。产品经理在观察和获取到用户在使用自己产品的过程中的反馈才是有意义的，才是值得评审的。
（3）回顾会议——要定期开回顾会议，且还要在会后产生一个行动计划。建议是每周二、每周四展开产品负责人和团队有30分钟的碰头会，这就是在解决问题和分歧的会议。
教练——团队里需要懂敏捷的成员
如果想做一个成功的敏捷开发转型，不管是内部教练还是外部教练，一定要有一个人需要知道：什么样叫真正的敏捷软件开发？什么样是形式的？什么样的算是对付对付？——要能够真正理解这些东西，需要有一个教练来理解。
来源：PMCAFF社区
作者： 姜信宝
