敏捷的概念在互联网公司越来越流行开来，一些传统的大型公司也逐步地向敏捷转型，甚至在产品经理面试的时候，面试官最常询问的就是你参与过敏捷开发团队么？
作为一个产品经理，如果你现在还不了解敏捷是什么，可能几乎无法融入团队的工作。
但是当我们打算阅读一些敏捷相关的材料时，却总是被一些拗口的翻译词汇搞得很不明所以。
本文以一个产品经理的角度，以多年主导敏捷团队的经验，深入浅出的带你掌握主导团队敏捷开发的方法。
今时今地，为何需要敏捷开发？
让大象跳舞，是所有大公司追求的目标。
迅速的响应市场变化，用最低的管理成本创造最好的产品，源源不断的创新能力——多少管理学家和实战领袖都在追索这三个问题的终极解法。
对于产品研发团队，敏捷方法也许给这三个问题找到了答案。
简单介绍敏捷开发
你可能已经阅读了一些关于敏捷的资料，接触到例如“宣言”、“价值观”这些大词儿，还会看到“迭代”、“看板”、“User Story” 这些方法论。但是没有经历过实操，觉得迷迷糊糊的。
没关系，我们来重新梳理一下：
“敏捷”（Agile）一词，来源于“敏捷软件开发宣言”（Manifesto for agile software development）： 个体和互动：高于流程和工具。 工作的软件：高于详尽的文档。 客户合作：高于合同谈判。 响应变化：高于遵循计划。
这个宣言所表达的是：自驱力、协作力、应对变化的能力，相较于工业时代的流程、制度、规范而言，更适合互联网研发团队。
我们拿麦当劳和海底捞举个例子，麦当劳是典型的大工业标准化管理方式，你在全世界每一个门店尝到的味道和感受的服务都是一样的；海底捞是一种以人为本的管理方式，最大限度的发挥服务员的主观能动性，不断给你惊喜。
理解到这一层我们就会知道，所谓敏捷，是一种团队竞争力，这种竞争力能迅速的响应变化，激发创造力潜能。
但是理想很丰满，现实很骨感可是不行的。产品经理或项目经理如果只会带着团队喊口号，画大饼，研发小哥哥也只能给你个白眼自行体会。
所以，掌握一些能驱动团队的方法和关键节点非常重要。
敏捷本土化变迁
敏捷的发源于美国，也因为一些硅谷公司在中国的大力推动而生根发芽。但是中美文化有巨大的差异，导致我们在理解和执行敏捷开发方法的时候，会觉得无法执行下去。这就造成了书本上和“别人家”的敏捷方法，与中国公司实际可落地的敏捷方法有很大的不同：
变化一：产品经理面对的需求来源更多，话语权更强，不确定性更大（没错我说的是大佬们）。团队的资源情况，任务优先级和进度透明化展示变得非常重要。我们常看到国外用便利贴的方式管理进度，然而更符合中国国情的方案是：线上看板工具。
变化二：迭代一旦开始就不要安排新的工作，这一点几乎没有办法做到。如果代码管理和自动化运维能力不足，研发团队会为上线问题耗费惊人的时间成本。而很多公司对此重视严重不够。
变化三：激情和自驱的工程师是珍贵而且稀缺的，所以里程碑和工时管理在本土企业中变得非常重要。
以上只是说了我在项目中常见的一些变化，相信每个公司都有自身的痛点。而敏捷的核心就是以人为本，拥抱变化。所以我们在执行的时候也不要固守书本里的方法论，那样只会纸上谈兵，无法真正为团队赋能。
产品经理的敏捷方法论
所以对于产品经理而言，什么是敏捷的核心方法，我们一定要贯彻、推动跟执行的呢？
我认为有以下三点：
对团队和用户的即时反馈
换言之，就是唯快不破。虽然每个产品经理心中都有大大的梦想，但是你一定得想办法把他们拆到最小尺度上。让开发团队在很短的时间内就可以交付，看到成果，也能让用户不断地感受的产品的升级和变化，并做出反应和调整。
从目标到代码的拆解
产品经理设想的功能，到开发实现的功能，失之千里是太常见的事情。产品经理必须能自始至终掌控交付质量，而不是仅仅在上线前进行验收。产品经理必须要通过不断地磨合，和研发团队建立一种有效的将需求精准明确的转化为代码的机制。
代码逆向可控性
光从目标拆解到代码是不够的，还需要能反向的知道一段代码究竟关联着什么样的需求。当团队成员变化频率较高，或者是系统变得复杂以后，你会发现知道这至关重要。可以节约大量的阅读代码、熟悉业务、整理文档的时间。
主导敏捷开发的关键节点
接下来，我将介绍一个完整的迭代流程中的关键节点。这些关键节点是我在长期的工作中总结出来的百试不爽的方案。希望能对你有所帮助。
我们拿一个常见的电商网站来举例，在实战中掌握方法。
第一步，确定一个大目标（产品长期目标）
如果你是一个初级产品经理或是产品助理，不要求你能够独立的设定产品战略，但是必须能够理解和传达目标。
制定战略目标又是一个大学问，此处就不展开了。
案例：传统的水果公司成立了软件开发部门，希望以此扩大收益，降低成本。通过调研和分析，确定了本年度目标是建立线上商城，并将供应链进行数据化管理。线上商城目标覆盖北上广深4个一线城市，达到年销售额 100 万；提升供应链团队 40% 的人效。
第二步，拆分多个小目标（产品短期目标）
面对不具有可实施性的年度目标，需要拆解成具体的季度、月度目标。包括制定产品路线图，组建团队，立项。
当团队规模比较大时，按照项目划分团队是个好习惯。当一个研发团队的成员超过一定规模时，协同成本就会急剧上升，很有必要进行项目划分。
项目团队是一个为了某个特定目的而组成的临时组织。我们可以利用项目管理工具便捷的创建项目、管理团队。让多线程的项目管理变得轻松。
案例：细化年度目标，拆解 3 个项目组：供应链基础版、商城 H5 版、管理后台基础版。
第三步，用户故事（UserStory）
我见过一些团队，强行的要求用户故事按照以下的格式进行：
“作为一个『角色』，我需要一个『功能』，以实现一个『目的』”。
无可厚非的是，设计每个功能时都需要定义清楚它的用户角色、功能详情以及目的。但一定要照本宣科的照搬格式，我认为也没有太大必要。
产品经理按照自己和团队都能接受的最高效的方式，通过原型、标注、流程等形式将所需要的功能描述清楚即可。
我们一定要将用户故事拆成能独立上线，实现一个完整功能的最小单位，并给他们清楚地定义好优先级（可能需要多方意见的综合）。保证在一堆用户故事中，最高优先级的不超过三个。
只要产品经理做到这三点（清晰明白的原型和标注、最小独立功能、公认的优先级），就可以为迭代开一个好头。
案例：对于商城 H5 这个项目，我们可以建一些用户故事，并不断地大胆的向里面增加新的用户故事：
第四步，设定迭代目标
迭代是敏捷开发最核心的概念之一。
一个迭代即为团队所约定一个交付时间，通常在2周，可以更长也可以更短。这个看上去有点不合情理的要求其实非常有益：通过交付时间的明确规定，使得产品经理在规划功能时尽可能的做到最小功能，研发团队在持续的交付过程中，能越来越熟悉自己的能力，培养按期交付的习惯。
实际操作时，需要在迭代开始前，组织核心开发人员按照优先级的从高到低了解用户故事，并评估所需要的时间，决定下一个迭代完成掉哪些用户故事。
案例：经过评审，团队决定将两个最关键的独立功能作为下一次迭代的交付内容。在2周后达成上线，建立一个里程碑，作为一个承诺。
这样的承诺对于产品上线宣传和运营非常有帮助，能很好地计划推广素材准备时间。
第五步，交给研发
接下来，研发负责人要将产品需求转换为开发设计文档，将用户故事拆解为具体执行的任务卡片。拆解的标准也是以最细粒度为佳，单张任务卡片的开发工作量不要大于一天。并落实到人上。
这样，我们就可以建立一套『目标-任务-用户故事-研发卡片』的完整链条，不论是正向还是逆向，都可以追溯，找到每一个代码的源头需求，也能为每个需求关联完整的代码。
这个从用户故事到研发卡片的过程，最好能抽一个全员都能参加的时间，认真的开会评审讨论。产品经理营造轻松自由的氛围，让大家把能想到的问题都抛出来，并得到最佳解法。
在开始开发前，尽可能的将需求讨论清楚，才能避免后面的遗漏、信息不对称。
研发需要每天及时的变更任务状态，这样团队所有成员都可以一目了然的利用任务看板了解迭代进度。
案例：将刚刚的商品列表拆分为更细粒度的研发任务，指派到开发，并及时更改进度。
第六步，上线观测与目标调整
不少产品经理会觉得，功能上线后的用户反馈和运营数据与敏捷研发团队关系不大了。其实恰恰相反，因为敏捷的核心要素就是即时反馈，对于研发团队而言，上线后的效果就是最重要的反馈，可以激励、鞭策、凝聚团队更好的发展。
通常，上线后，我们需要去做这两件事：
上帝说，要有数据：
如果上线的功能会直接产生可观察数据，那么一定要利用监测工具将他们记录下来，并有效的传递给研发团队。例如停留时长、下单转化率等。
聆听核心用户：
数据不是万能的，有时你掌握不了准确的数据，有时数据会迷惑你。所以需要建立与核心用户的反馈通道。收集他们对新上线功能的评价。
通过以上两点，我们不断地去调整用户故事的优先级、建立新的用户故事、淘汰不合时宜的故事、改变小目标，使得产品可以永远符合市场的需求。
欲善其事，必利其器
经过短暂的阅读，你大概对于一个产品经理如何主导团队敏捷开发建立了认知。
接下来，你需要实践、宣导，与你的团队一起磨合出最适合你们的迭代流程。
这时候，你需要一个项目管理的工具。
用工具推动执行力
一个优秀的工具，自己就会宣导和贯彻高效的方法论，也能驱动成员去执行。这就像我们学习时利用笔记类工具；提升效率时用时间管理类工具。
如果团队没有一个称心的项目管理工具，敏捷开发的推动也只能事倍功半。
推荐几款敏捷开发工具
在不同的团队里，我尝试过几款不错的项目管理工具。例如，
JIRA：可用于文档管理、进度管理、测试 bug 管理。适合于大型公司进行本地化部署，功能很强大。不过由于是国外软件，在交互方式、界面、语言上都稍微有些适应和学习门槛，感觉用了半年还是用不顺手。
TOWER：国内众多一流团队协作与项目管理工具之一。交互流畅，界面漂亮，在 PC 、移动和微信中都有不错的表现。美中不足的是对研发团队在代码管理上的需求无法满足。只能用来管理任务和文档。
CODING：最近才发现的一款神器。完美的将需求、任务管理与代码托管，持续集成整合在一套系统里，覆盖了敏捷团队的全生命周期。曾经非常令人头大的分支管理、版本管理、上线管理，都可以覆盖到，并且与需求管理和 wiki 打通。推荐。
好了，文章就到这里。希望能帮助大家。
热门跟贴