共事。人的好奇心、想象力、创造力、可能性皆是无穷的，而人的情绪和情感也是无法被剥夺和割舍的。至少在「发疯」和「玩梗」这两件事情上，我看到的是无法被替代的人的价值和创造力。同样的，LigaAI

时间管理：通过合理的时间管理方法，提高工作效率。研发效能的提升需要团队和个人共同努力，团队和个人都需要不断学习和提高，才能实现最优的（P.S.：这里最后三个字就是「最优的」，真的不是小编漏了

分钟☕「人工智能+团队协作」还能有多少种打开方式？致力于打造新一代智能研发协作平台，LigaAI在不断强化自身智能化能力的同时，也持续关注着整个「AI+协作」领域的发展。Gartner在《

Group举办，聚焦云原生开发技术，探索云原生技术下的测试、交付、安全等话题的全新思维碰撞。未来，LigaAI将持续为开发者社区提供高质量技术分享，与更多开发者和团队一起探索高效益的研发管理之道。·

发布规划和MVP通过对产品发布进行分割和切片，用户故事地图还能定义每个发布版本应该为目标用户提供哪些价值主张。这进一步加强了我们的产品战略。对用户需求进行切片时，正确地切分价值主张非常重要。Dan

「对企业而言，不可缺少的是效能，而非效率。」著名管理大师彼得·德鲁克的这句管理真言，将「研发效能」送上了话题之巅。随着互联网环境不确定性的增强，更多的研发团队开始重视效能管理，诸多企业也纷纷投身于「效能革命」中。当一些企业埋头攻克「效能提升」难题时，另一些声音则指出，我们现在对研发效能所做的所有尝试，都是在努力奔跑，以尽可能地停留在原地。根据熵增定律，由于软件复杂度增加、团队规模扩大等诸多原因，组织内的研发效能必然会越来越差，而企业能做的只是尽量减缓其恶化。研发效能真的不能被提高吗？效能提升应该怎么做？为了探讨研发效能的更多可能性，LigaAI与两位创始人展开了一次长谈。从概念到度量，从目的到指标，我们来聊聊研发效能的「道与术」。妙谈嘉宾

总结一个好的场域能够激发参与者的表达欲，建立成员间的和谐关系。而基于安全场域开展的迭代回顾会可以赋予所有成员坦诚表达的勇气，成就更紧密、更顺畅的协作，并成为敏捷团队前进的核心动力。·

企业效能目标确定愿景后，定义阶段性目标。LigaAI聚焦研发协作，当前阶段最主要的目标就是企业效能提升，那么「企业效能提升」就是数据驱动的目标。以下是一些推荐的效能目标。03

关注LigaAI，成就更好的敏捷研发任务重，手动同步状态和信息，分身乏术；信息不透明，跨职能成员协调难、沟通成本高；负责人到任，项目细节和代码信息却无从了解；……传统研发流程中，机械重复和信息孤岛或成为阻碍高效协作的头号因子。数字化与信息化的浪潮袭来，基于系统和工具优化管理方式，构建数据闭环和流程自动化是研发提效的主旋律。本文将从需求痛点解析和解决方案建议两个方面，对研发效能优化展开解读，帮助企业更好地打造坚固、可持续发展的研发生态。研发流程管理中，企业的关键需求和痛点是什么？01

👆关注LigaAI，成就更好的敏捷我最喜欢的一张激励海报上印着吉萨金字塔，标题处写着「Achievement」；它底下的解释有些讽刺，但非常有说服力：当你有远见、决心和无穷无尽的可消耗劳动力供应时，你可以做任何你想做的事情。不幸的是，于我们而言——作为产品经理的我们——我们或许有远见和决心，但却很可能缺乏无穷无尽的可消耗的劳动力（和时间）。这就是为什么我们要对团队的工作进行优先级排序。我们必须确定哪些成果唾手可得：相较预期的成果而言，这些工作可以轻而易举、不费吹灰之力地完成。几年前，我编译了这个优先级排序框架的早期版本，并将它投入Voice123，Bunny

敏捷四会之如何提升远程团队的站会效率？请点击《分布式团队的高效站立会说明书》2.

每日会议每个工作日都要举行一次会议。为了最大限度地提高工作效率（避免多任务并行），每日会议应该尽可能早地举行。如果需要进行远程会议，选一个最顺手的远程工具即可。会议议程大致如下：👓

而言，他们的硬实力主要来自对业务的充分理解：综合考量外部环境、市场环境、竞争分析、内部协作等等，理顺整个产品的商业逻辑。对技术管理者而言，业务理解力是不可或缺的硬实力之一。03技术管理的软实力广度

分钟举办内部短会，用于同步项目进展，识别和解决进度障碍。但是在许多团队中，本应该解决障碍的站立会却变成了障碍本身：会议充斥着机械的工作汇报，对协作提升没有任何帮助；或者会议内容发散拖沓，15

团队的研发容量（Capacity）是团队当前研发能力的直观体现，是衡量团队在迭代期间能够完成多少工作的重要指标，常以过去迭代周期已经交付的平均工作量估算，通过「速度-时间」公式即可算出：研发速率

：如何消减协同合作中的认知偏差？在敏捷开发中，想要评估一个故事是否达到客户对需求的期待，就要让它去接受「验收标准」的考验：用户故事必须「通过」所有的验收标准，才算是真正地产生价值。DoD

在敏捷开发中，让所有成员保持目标统一、步调和节奏一致非常重要，但是在团队协作中，认知偏差却在所难免。需求在不同环节中流转，是否存在某种途径能保证所有成员的理解一致，将偏差最小化？今天跟大家介绍敏捷开发中共识建立的两大神器：DoR

按不同的数据类型切分根据不同的数据类型或数据来源，拆分大型需求，是处理输入/输出操作的常用手段。敏捷团队可以根据不同数据子集的优先顺序，先在一个迭代内专注一种数据类型的实现，以快速交付故事价值。05

数据依据不同的数据类型或者数据来源，拆分大型需求；通过专注于数据子集的功能实现，实现更简单的用户故事交付，是非常有效的方式。敏捷团队可以在一个迭代周期内只专注于一种数据类型的实现，交付价值。05

可估算开发团队通过估算用户故事的重要性和工作量，以确定故事的优先顺序。当你发现无法估算一个故事的完成成本，要么你缺乏足够支撑估算的信息，要么故事需要被进一步地分解。05

字的采访精华一定能帮助你更好地理解和实践「团队自组织」。敏捷和自组织能更好更快地响应变化Liga：目前在国内，有些团队不太看好敏捷开发，为什么

人之间，宜少不宜多。开发团队必须熟练掌握完成一个项目所需的全部技能，才能顺利推进项目完成。敏捷开发团队需要专业精湛且多功能的成员，换句话说，兼具深度专业和跨职能的「T型人才

Metrics：各类财务指标、生产与物流的效率指标、服务流程的漏斗转换率，通常以「优化绩效」为目标。关注这些指标的主角，大概九成以上是公司本身、或团队成员、或股东的金融分析师。用户成功指标

Outcome」，并且还会跟大家说明该如何串连这三个工具，以及如何和原有的工具一起相辅相成。想在第一时间获得最新的需求描述相关内容，别忘了点击下方卡片关注我们，并将我们设为「星标」关注哦~本文作者:

在产品开发团队的我们，是否都遇过以下状况？每天面对超多产品反馈、需求申请，花很多时间厘清、沟通？参加无数的会议，冒出各种需求，发散的无边无际？终于提出产品路线图，面对各方质疑，结果改到四不像？...这些收集、整理、协商需求的过程，是不是很令人头痛，又消耗我们宝贵的时间？不仅难取得共识，我们最怕的更是产出无法推动成效？为什么需求描述这么难？究竟卡在哪里？归纳出以下这几种状况：状况一：描述需求时语意不清，没有厘清的过程，产生误会状况二：针对相同的功能、接口、流程，因为每人代表不同用户，或遇到不同情境，提出互相独立的需求，产生冲突状况三：针对相同需求，因为负责不同目标，或站在不同的解读角度，产生僵局因为以上三种状况，导致我们必须反复沟通，消耗很多时间，也难以确立目标、推动成效。举例运营电商网站的团队讨论：如何优化商品详情页市场

）是最受欢迎的优先级模型之一，因为该模型能够真实有效地引入用户满意度作为评估指标。产品负责人和研发团队需要在产品的设计、开发、管理等各个阶段，时刻考虑到客户的诉求，卡诺模型（Kano

精确估计：精确性对于大型决策来说更为重要，此时需要与你的产品团队充分合作。数据科学家、工程师、营销团队、战略顾问或任何其他角色，他们都可以帮助团队正确估计每个领域的规模。▶

写在前面：在决定要衡量什么时，首先要有一个目标。其次是用什么来衡量这个目标的完成情况，这里就要谈到「指标」。就敏捷开发而言，客户和团队内部对敏捷开发的「可预测性」尤为重视。因为没有稳定的可预测性的团队就不可能有可预测的项目，特别是当团队之间存在多种依赖关系时。在每个冲刺

在《敏捷开发中的「史诗」到底是什么？》这篇文章中我们详细解释了如何写好一个大型用户故事「史诗」的方法，本期文章，我们从「写好“小”的用户故事」视角着手，更深入、准确的理解敏捷开发~开卷有益，我们先来聊一聊「用户故事」。01用户故事敏捷是一种基于产出价值的开发方法，「以客户为中心」要求其所有产品功能在得到客户需求、认可后，优先开发。找出谁是用户，尤为重要。一旦所有的用户被识别出来，为他们产出和增加价值的需求就会被记录下来，这样的需求被叫做「用户故事」。层序分明。编写「用户故事」背后的逻辑与规则是什么？它们是如何被执行的？02规则写好「用户故事」，其结果影响自不必说。通常来说，便于开发者创建、跟踪和测试用户需求的格式应该是以下这种：作为，我需要以便获得这里的用户指的是角色，如经理、文员、开发人员、图书管理员、业主等等。好处，指用户将获得的价值，如：经理只需单击一下即可查看审计报告，好处—节省他的时间；店员可以搜索报告，好处—节省时间；图书管理员可以按类别搜索书籍，好处—他可以彻底改善客户服务；业主可以订购设备，好处—省去很多麻烦。这里有24个用户故事示例，它们描述出不同平台/系统下每个需求对标的用户价值：作为管理员，我希望我能在需要时为团队创建新用户作为一名律师，我希望在主屏幕上看到我所有活跃的案件作为一名学生，我想在黑板上看到我的历史成绩和当前成绩的汇总作为司机，我希望我的GPS语音被激活作为一名研究人员，我想看到我所做的最近几次搜索作为用户，我希望能够恢复我的密码作为收银员，我希望看到收银机中显示的总金额作为一名飞行员，我想知道在当前条件下的最佳飞行高度作为一名警察，我想看看由我开具的历史罚单作为一名邮递员，我想知道今天投递邮件的估计时间作为一名吉他手，我想知道我的手指在琴弦上的速度作为割草机，我希望它能避免将刀片撞到坚硬的东西作为一名跑步者，我希望心跳不规则时能被警告作为一个盲人，我希望在路上遇到障碍的时候能被提示作为信用卡用户，我希望当花费超过设定金额的时候会被提醒作为一个孩子，我想把不活跃的玩具店都关掉作为一名司机，我希望得到轮胎压力最大值时的报警作为一名学生，我希望每天早上都能提醒我的课程表作为一名经理，我想在计划时进行假设分析作为测试人员，我希望看到分配给我的所有错误状态作为机票预订者，我希望在飞机满载的第一时间就能收到通知作为一名作家，我希望我的作品每隔几秒钟就能自动保存作为读者，我希望看到过去2周内最畅销的书籍列表作为一名厨师，我想看看访问量最大的食谱以上这种编写用户故事的方式能让大家更直观的看到彼此的工作效益，然后根据用户故事的大小、需求内容、价值排序等预先排期，安排工作量。掌握清楚这些，团队小组才能顺利开展接下来的工作。细心的小伙伴已经发现，用户故事在编写和传递信息的过程中遵循着

当我们开始了解和采用「敏捷开发」的时候，时常会看到一个略显陌生的概念「史诗」。或许因为翻译的问题，这个概念在中文语境里有些难懂，在实际应用中，理解更是五花八门。为此，小编找到了这篇详细介绍“何为「史诗」”的文章，推荐给大家。开始之前，我们先看看「史诗」的定义。首先，「史诗」是与「用户故事/需求」密切相关的。简单地说，「史诗」是一个更大的「用户故事」，或者说是一个「需求集」。它们通常表示了与产出物相关的原始想法。「用户故事」，或称为需求，代表着需要交付的解决方案的具体工作项。而「史诗」则是用于跟踪、管理这些待办事项中，工作量较大的事务的一种「工具」。一个「史诗」通常包含多个「用户故事/需求」。在实际工作中，如何编写用户故事，并将其拆分为有意义的「史诗」？第一步，可能是先写好「用户故事」。Good

最近一段时间，伴随着「工时登记」功能上线LigaAI，越来越多的小伙伴在问：工时和点数，到底有何异同，各自又应该如何使用？在很长时间里，工时（或者人天/人时）是研发团队中更常用的概念。这个简单粗暴的指标，能直接反映出：完成某项工作需要几个人做多长的时间。这一指标确实让许多研发团队获得了评估项目人力成本的基础数据。

我们将其称为激进愿景工作表。01创建产品愿景激进愿景工作表会引导您完成几个基本步骤，以实现清晰、简洁的愿景。无论你是初创公司创始人还是产品负责人，Dutt、Aggarwal

当我们的产品准备支持Kanban项目时，我的小伙伴在工作文档里同时看到了“Kanban”和“看板”并露出疑惑的神情，“Kanban”难道不是“看板”的拼音吗？这两者有什么区别吗？今天我们就来聊一聊~Kanban

改变，对任何人来说都很难，对团队来说更是难上加难。同理，敏捷转型带来的重大变革也会很艰难。甚至，有时候敏捷转型反而会带来短时间的产能下降。为了帮助更多研发团队顺利过渡到敏捷，我们以十余年的管理实践，整理了这份：敏捷转型之路的

你才能够回答以下问题：构成你产品的不同技术栈是什么？这些系统中的运行逻辑是什么？与各系统相关的主要风险有哪些，怎么规避？哪个系统是由哪个团队管理的？这些系统之间是如何关联的？(例如:

你是不是也为冗长耗时的评审会困扰，光是提起来就脑子隐隐作痛，昏昏欲睡的下午，连篇累牍的会议，简单的需求也需要层层确认...来把敏捷牌局迅速打开新世界大门kai开shi始da打pai牌整个牌局分为两部分①价值评估

为何不再经常使用点数。他认为「故事点数」存在许多弊端，如：导致恶性竞争和团队工作的失焦。同时他也给出了弱化点数后的敏捷开发建议。对正在采用敏捷工作法的团队来说，本文将带来新的思考和视角。本文总计