1.Kanban

目前，我使用的项目管理工具将当下的工作和日常维护或长时间更新的事项管理起来，通过一个个看板中不同卡片的状态了解项目的进展和下一步计划，帮助我时刻处于一个全局视角，避免深陷某个项目中的聚焦局部、个体事项，以此构建真正的最小可行产品（Minimum Viable Product，MVP）事项。这在我大量接收到突发临时紧急任务需要调整优先级时，整个看板中的用户故事卡片可以帮助我更好地选择迭代交付的范围，确定当下紧急项目能交付的最优价值。

每次新建故事卡片，我对于故事卡片的估算和每日给自己能完成的卡片数量有一个更精确的范围，这也是在不间断地迭代个人与团队的速率。当Kanban做得越来越自然和深入后，你会发现对于各类事项有了明确的阶段划分和准入准出标准，每个不同类型项目有了大概的交付周期，每日或每周大概能完成多少事项。最直观的是永远有一个发射源的灯在那亮着，光永远在传递，降低了很多重复无效性的沟通成本。

而Kanban实践在敏捷方法实践和技术导入过程中，给团队成员、干系人带来的透明、坦诚、自信等潜在意义更加让人幸福与信任。在每次的卡片优先级调整、新增加的风险阻碍的情况下，不同职责的同事对一张卡片的DoD定义所进行的积极讨论，产生的信任和透明是非常具有正向意义与冲击力的。或许某个项目的最终成果价值不会特别大，但是在做项目的过程中，团队成员所产生的意识、行为会一直保留并影响下去，而这也是对售前、咨询顾问或敏捷教练最大的认可。

2.Scrum

提及Scrum，大家很容易直接想到“3355”，即3个核心角色、5个关键事件、5个价值观和3个工件。而我将各个内容都做了一定的映射。
（1）3个核心角色：产品负责人（Product Owner，PO）变成了售前，敏捷教练（Scrum Master，SM）变成了销售，开发团队（Scrum Team，ST）变成了实施交付；
（2）3个工件：除了产品增量（Increment）映射成商机，其他没变；
（3）5个关键事件：Sprint直接映射成工作中的一个个项目；Sprint计划会自然演变成项目计划；每日站会则做了调整，变成了关键事项和核心时间点的同步与反馈；评审会则是每次给客户做产品介绍、服务方案、能力验证（Proof of Concept，POC）前和销售、商务、实施交付的一次拉通对齐；回顾会则相对较少，基本是比较大型的项目或较多经验与教训能吸取的则会一起复盘下。
（4）5个价值观：这并没有任何变化的，我们都需要开放、尊重、勇气、专注和承诺，而这些在Kanban的可视化过程中也是一样的要求。

Scrum框架让我与销售、商务、实施交付在和客户沟通、项目实施过程中，5至7人的小团队逐渐实践了迭代式增量软件开发过程，在这个小团队中我们通过各种方式来实现高度自治和产品增量（Increment）迭代交付，持续交付价值。尤其是产品演示过程中我们经常使用的电梯演讲，尝试着是否能在30秒内向客户介绍最容易打动他的方案，并且不断提炼和针对不同背景客户做产品增量（Increment）迭代。

Scrum是现在技术团队非常主流的敏捷模式了，但是它本身有较多的规范，比如一个Sprint多长时间规划，不同角色的定义和职责等，这些对于团队要求也是比较高，且要按照他的体系来落地。而Kanban并没有规定像一个Sprint多长时间，更加强调的是卡片（任务）的流动、跟踪、反馈，相对于团队来说入侵感不是太明显。目前，行业内也有结合Kanban和Scrum诞生出新的ScrumBan，在可视化模式中管理了冲刺任务和任务的进度监控，而这也是我目前在实践过程中的一个新突破。

来源：《敏捷之道》——敏捷思维：售前的制胜秘籍---文/王富

【每日一学 20260608】敏捷之道——敏捷思维：售前的制胜秘籍

1.Kanban

2.Scrum

联系我们

融实践库

微信公众号

微信视频号

社区微信群