敏捷工程方法

作者背景：从1981年左右到2014年退休，我一直从事软件工程或相关学科的研究。从1984年到2014年，我的所有研究都涉及与英国和整个欧洲的工业界合作。我有幸与来自不同行业和国家的许多人一起工作，我从这些经历中学到了很多东西。

敏捷是一种自下而上的运动，而如今，当在大型组织中实施敏捷时，往往是以从上而下的推动方式而不是拉动方式来实现的。 自下而上是让人们自愿参与变革，而不是自上而下的领导者选择。如果人们对他们施加敏捷推力，这会产生不利影响。当人们参与并想要做出贡献时，他们

我真的希望我们可以作为一个团队做更多的工程，创建、设计、研究和构建出色的软件。但相反，任何在2-4 天内无法完成的事情都会被取消优先级并放入积压工作中。其他讨厌点：会议超负荷。我觉得我是产品团队的仆人。作为一名工程师，我无法进行创新。

锚定偏差（第一印象偏见：anchoring bias）是一种认知偏见，它导致我们过于依赖我们获得的关于某个主题的第一条信息。当我们制定计划或对某事进行估计时，我们会从锚点的参考点解释新的情况，而不是客观地看待情况。这可能会扭曲我们的判断，并阻止我们尽可能频繁地更新我们的计划或

PO（产品负责人） 和 PM（产品经理） 是同一个组织，不同级别： 产品负责人：构建能解决问题的解决方案 产品经理：提出要解决的问题 集团产品经理：发现要解决的问题 主管：从组织中找到合适的人来解决已识别的问题 VP/CPO/Head of p

模糊效应（歧义效应：ambiguity effect）是一种认知偏差，描述了我们如何倾向于避免我们认为模棱两可或缺少信息的选项。我们不喜欢不确定性，因此更倾向于选择实现某个有利结果的概率已知的选项。（买涨不买跌） 想象一下，您正在注

作者在智能能源平台Kaluza担任设计师。为多个市场、用户和用例构建一个平台。所有这些都是为了节省消费者的支

阶段性工作、回顾、完善和类似的工作所花费的时间是疯狂的。如果我假设每天有15分钟的停顿，两个小时左右的完善和回顾（我曾在一个地方有四个小时的完善），那简直就是把一天的冲刺时间浪费在了会议上。 如果团队中的人只是在电子邮件中告诉经理/主管 "我被这个

最近，我的团队决定为我们的冲刺尝试斐波那契（Fibonacci，简称fib ）点。 在这之前，我们用点来表示时间（1点=1天），并且通常有一个我们称之为置信度的第二个值（在估计的准确性方面）。低置信度意味着它可能会有很大的变化。高置信度是为你以前做

2021年初，在Snapcommerce，我们有25名工程师在班组工作。每个小组都有一个工程经理（EM）作为所有项目的负责人和技术负责人（TL），一个产品经理（PM），一个设计师，一个QA团队成员，以及最多七个个人贡献者（IC）工程师。对于工程师来说，从一个IC成长为TL可能是一条具有挑战性

写这篇文章主要有两个原因： 首先，我对软件开发行业的总体状况不甚满意。 其次，我想写下我认为 "现代 "敏捷的失败之处（也就是说，它甚至不是宣言中所描述的敏捷），特别是对估算的痴迷，在现实世界中很少有效果。 我相信#NoEstimate（无估算）是一条前进的

首先什么是敏捷？它来自哪里？ 我第一次遇到敏捷是在图书馆的工作中。我被雇来帮助一个新的数字学术中心落地，有时与图书馆的软件开发团队合作，建立工具来支持我们的项目。这个团队大约有六名成员，我马上注意到他们做事的方式与非技术人员不同。在会议上，他们不谈

OKR（目标与主要结果法）中最重要的是设立“目标”，但是现在的我怎么知道未来成功是什么样？设立的这个目标又如何具体到足以有启发性，又要不能太具体以致太详细，没有足够开放来激发创造力？ 以时间旅行做比喻：首先，我设定了一个目标：我想在未来的某个时间点实现的东西。

Shubhro Saha 是 Facebook 的工程经理。他写了一篇很棒的博客文章，介绍了如何更好地估计一个项目需要多长时间才能完成。一个很好的提示是始终清楚地将估计与目标与计划分开。目标可能是最乐观的，而计划是最悲观的（它解释了可能遇到的任何问题）。

我在软件开发领域已经工作了10年了。大约8年前，我的公司开始了将所有项目转向采用Scrum框架的历程。作为一个年轻的开发人员，我们的管理层告诉我，Scrum可以让我们更好地管理自己的任务。一开始，我对这个想法很兴奋，因为我认为这意味着我们可以更好地平衡工作和生活，但是，天哪，我错了。这些是我

在“Inspired”中，Marty Cagan认为：一个好的产品团队能够在一周内测试 50 个假设。 就像许多关于思想领导力的书一样，这是不是简直是天方夜谭？不太可能成为现实。如果一个团队每周真的有 50 个假设要测试（并且有开发和设计合作伙伴来