无论作为产品用户还是管理咨询顾问，都非常非常喜欢微信。自认感情比较克制属于“高冷”挂，但从很多方面都太佩服太崇拜张小龙了（新书里微信也会是最喜欢的案例之一，真的不只是一个产品而已，很多方面都太牛了）。不知道大家是否有注意到，在疫情爆发后，微信的响应大概最快速也相对最到位的了，看一看立马有了“疫情专区...

需求是整个软件项目当中最重要一项输入。软件开发和传统生产行业最大的区别在于，需求总是模糊的、主观的和随时变化的。相对于电子产品、汽车等制造行业有形的硬件需求，软件开发的需求的描述和验收是个难以解决的问题。

敏捷估算，就是在敏捷开发中，对即将开始的工作进行工作量、复杂度和持续时间的相对估算。通常情况下，软件开发过程中有很多未知数：技术更新，需求变更，系统之间的依赖关系等，它们都会影响估算结果，所以说估算是一项费时费力的工作，并且得到的结果也是不精确的。既然如此，我们为什么还需要进行敏捷估算呢？

无论你在小型创业公司工作还是在大公司的新产品线工作，当团队人数越来越多时总会达到一个临界点。尽早识别这个临界点可以让您的团队避免进入低效阶段。每个产品都是不同的，团队合作也是如此。因此，拆分团队也需要做一些反映团队情况的决定。在做决定时有以下几点需要考虑：

Velocity用于衡量scrum团队持续提供业务价值的速度，可以采用历史估算的方法，衡量一个又一个sprint的速度。团队通过跟踪完成达到自己团队完成标准的故事点的数量，就可以基于相对点值对未来需要完成的新的用户故事需要花费多长时间有一个比较可靠的预测。

估算并非易事。对软件开发人员来说，估算堪称是最难的工作之一。估算必须考虑所有能帮助产品负责人做出影响整个团队和业务决策的因素。因此，从开发到高管都为它焦头烂额也不足为奇，但这种做法是错误的。敏捷估算并不是什么性命攸关的大事，就只是估算而已，事实就这么简单。

你听过柏林新建机场的故事吗？机场原定2006年开工，2007年启用，但由于机场建设过程中到处出现施工和安全问题，补东墙漏西墙，导致工期一拖再拖，预算一涨再涨，以至于2019年了还没开张，预计开业时间已经被拖到了2020年10月。

官方《Scrum指南》中定义：Scrum Master在Scrum团队中属于服务型领导，负责践行和支持《Scrum指南》中定义的Scrum，要帮团队的每个人理解Scrum理论、实践、规则以及价值观。

一旦涉及版本控制系统，Git实际上代表敏捷开发的水平。Git作为一款强大的开源系统，有较强的灵活性，可以按需匹配任何开发团队的工作流程。而这种分布式相比较集中式来说，自然赋予系统更好的性能特征，且允许开发人员在本地自由实验，在他们修改到自己认为没有问题时再发布到团队。

作为敏捷开发基本构成部分，每日站会往往是最容易被误解的。事实是：每日站会本身并不会让团队变得敏捷。每日站会的目的不是自吹自擂，也不是为了验证工作成果；更不是计划时间，Sprint规划会议的目的才是这个。每日站会也不是只用来讨论开发阻碍而设置的会议，因为在遇到阻碍的时候，应该第一时间寻求帮助。

Sprint Review不是回顾，其目标是演示这个Sprint中自己的工作成果，参会人员包括设计师、开发人员和Product Owner。在Worktile，我们尽量保持Sprint评审会的轻松随意氛围。团队成员们会聚集在桌子周围进行非正式的演示，讲述自己在本次迭代中完成的工作。在这期间团队成员可以相互提问、尝试新的功能并提供反馈。成功的...

健康的Product Backlog就像一个健康的人那样：整洁有序、组织合理、公开透明。一个按照优先级顺序排好的敏捷Backlog不仅能够简化发版和迭代计划，还能够对团队计划去做的所有工作进行细致规划——包括客户根本不会关注的内部工作。尤其是当利益相关者和其他团队对团队提出额外的工作需求时，Backlog能够帮助他们设定期望指...

一个产品有需求的提出、评审、确定，以及实际的开发测试和交付这几个阶段。从2001年敏捷被提出开始到现在已经有越来越多的项目在使用敏捷。现在的敏捷已经变成一种常态，这个时候讨论敏捷实践中被大家的忽略点就变得非常有意义。

王明兰 --原华为、微软创新与转型教练、华为云SaaS产品总监，著名精益&敏捷转型专家 VUCA最早来源于冷战时期，在现代世界意指商业世界越来越不确定性，越来越易变，越来越不可预测，我们已经进入到了VUCA时代。 我们再也不能用原来的那种传统的、计划驱动的方式来工作，因为时代的不确定性，所以大家要拥抱变化。敏...

Sprint规划是scrum中用来启动Sprint的事件。迭代规划的目标是定义Sprint可以交付的内容，以及如何完成各项工作。迭代规划需要整个scrum团队合作完成。

Sprint指Scrum团队完成一定数量工作所需的短暂、固定的周期。Sprint是Scrum和敏捷的核心，找到正确的Sprint周期将帮助您的敏捷团队交付更高质量的产品。

在印度有这么一个神奇的团队，他们有5000名左右的员工，每天要运送20多万份餐，一份盒饭要经过3-4个人的手才能抵达目的地，交通工具只有火车，自行车，板车和双腿，没有任何单据，甚至都不需要客户填写地址。

我们现在接触的很多所谓的敏捷理念，让很多人认为这只是一个理念而已，但实际上你可以看到国内所有的敏捷流派都有来源，西方国家所有的研究都是基于科学理念的，所以如果我们对敏捷有深入认识，会知道敏捷是一种经过验证、真实有效果的一种实践。

一般我们想到产品创新，会觉得这个是产品经理的事，是产品经理应该关心的，我们研发团队好像一般关注比较少。根据我自己的经验我发现在创新上面非常强的团队，通常研发团队有非常深的参与度，而且对整个创新过程的支撑是非常强。

很多时候，我们感觉什么都没干一天就过去了，但对领导者来说，事情最好已经提前做完了，而且是越快越好。聪明的管理者知道，“时间”是需要花大功夫去把控的限制因素，只有掌握了更多关于时间和工作的数据，我们才能更好地执行计划，在预算范围内按时完成项目。

敏捷是一个很流行的一个词语，但是在敏捷里面，包括很多团队也是刚开始用Scrum，怎么让质量成为敏捷的一个助力而不是拖累，这个是我主要想谈的。

对从事项目管理的人员来说，敏捷已经成为一场席卷全国的风潮。但敏捷并不是什么新事物，它已经有20多年的历史。正如社交媒体圈子所说的那样，敏捷的声势与流行程度正在逐年见长。但敏捷是不是真的如坊间传闻的那样，是一个可以解决所有项目困境的万能药？当然不是！但敏捷的确是一种比较好的项目管理方法。敏捷为项目负...

当前，似乎每个人都在践行敏捷。这主要归功于敏捷能够适应变化并整合客户反馈的特质。现代社会这两者是非常重要的，因为技术在不断地革新，且人们获取信息的方式越来越容易——包括公开的客户反馈。

敏捷是理想型指标和原则，看板和Scrum是帮助团队坚持敏捷原则并完成工作的基本框架。本文详细介绍了在Scrum和看板之间做出选择时要考虑的关键因素，以及如果我们无法做出决定时该怎么办。

您是否在开发对组织来说有价值的产品？如何判断产品是否有价值？ 如果没有经常提出这两个问题，那么您可能忽略了产品价值方面的问题。 产品是目前工作所要达成的目的，是组建团队的原因。产品也是你选择Scrum的原因，所以，你必须要集中精力理解并提高产品价值。 优化产品价值的4个步骤 第1步：培养产品思维而非项目思维...

团队如何最大限度地发挥Scrum和敏捷的优势？ 回想一下，Scrum团队在Scrum的框架内定义了自己的流程。这其中包括方法、工具和互动以及如何履行Scrum角色的职责、如何使用工件和事件等。如何确定团队做什么以及怎么做？ 从产品管理方法到研发及质量管理方法。从团队的沟通协作方式到团队成员如何有效利用团队知识提升自己...

组织以什么样的方式能最大限度的发挥Scrum的优势？ 组织在哪些方面阻碍了个人的发展？ Scrum是一种能使业务变得敏捷的框架。而组织恰恰需要变得敏捷。只是，组织本身有时候并没有足够的能力来帮助Scrum团队的成长，甚至还会阻碍Scrum团队的成长。组织本身所具备的公司架构和企业文化，将影响内部的团队和产品。所以组织...

OKR与敏捷开发的原理有着相似之处，但已经使用敏捷的团队再用OKR感觉会显得多余。这种误解的根源就在于对这两种模式不够了解，运用得当的情况下，OKR和敏捷可以形成强强联合的效果，他们可以创造出以价值为驱动的团队，改变团队的工作方式。

OKR与敏捷开发的原理有着相似之处，但已经使用敏捷的团队再用OKR感觉会显得多余。这种误解的根源就在于对这两种模式不够了解，运用得当的情况下，OKR和敏捷可以形成强强联合的效果，他们可以创造出以价值为驱动的团队，改变团队的工作方式。

OKR与敏捷开发的原理有着相似之处，但已经使用敏捷的团队再用OKR感觉会显得多余。这种误解的根源就在于对这两种模式不够了解，运用得当的情况下，OKR和敏捷可以形成强强联合的效果，他们可以创造出以价值为驱动的团队，改变团队的工作方式。