Scrum承诺要解放开发者：它是对定义许多瀑布项目的命令和控制做法的彻底转变。Scrum是关于自我管理的团队和可持续的步伐。它应该是一种 "高贵的体验"（Agile Software Developm.

阶段性工作、回顾、完善和类似的工作所花费的时间是疯狂的。如果我假设每天有15分钟的停顿，两个小时左右的完善和回顾（我曾在一个地方有四个小时的完善），那简直就是把一天的冲刺时间浪费在了会议上。如果团队中.

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

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

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

我在软件开发领域已经工作了10年了。大约8年前，我的公司开始了将所有项目转向采用Scrum框架的历程。作为一个年轻的开发人员，我们的管理层告诉我，Scrum可以让我们更好地管理自己的任务。一开始，我对.

在与 Facebook、Whatsapp、Google、Netflix 和类似组织的工程师交谈时，他们中的大多数人从未使用过 Scrum。为什么？这是因为以下几点： 有能力、自主的人需要较少的结构来产.

我们中的许多人都去过健身房，最初取得了良好的效果。一旦你的身体适应了，同样的程序可能会帮助你保持，但你不会看到任何进一步的进步，你甚至可能开始倒退。我觉得 Scrum 作为交付软件项目的方法也遇到了同.

在当今瞬息万变的市场中开发现代SaaS产品，需要克服各种极端不确定性，需要比Scrum还要敏捷得多的东西！让我们面对现实吧！ Scrum真的不是那么敏捷：我已经拥有20多年的Scrum，足够长了！当时.

敏捷方法为团队提供了在收集业务需求时同时开始创建软件的能力。因此，通常被称为“分析建模瘫痪”的现象不太可能阻碍团队前进。事实上，敏捷方法论以其使项目能够创建“正确”产品的能力而广受赞誉。它使团队具有竞.

在许多敏捷项目中，需求通常不是以正式需求文档的形式编写的。取而代之的是，通常使用一组简洁而有效的方法来描述必须构建的内容，即用户故事。用户故事从客户的角度描述了系统的行为，性能或界面。一个典型的用户故.

我们的一些团队成员是Allen Holub的追随者。他是noEstimates方法的坚定倡导者。我们决定尝试一下。我们想测试一下，如果我们跳过故事的评估估算，而完全依赖我们的直觉判断将发生什么。我们还.

几天前，我读完Melissa Perri的Escaping Build Trap，并且像往常一样，我想与社区分享一篇评论。我拿起这本书是因为作者是爱尔兰一个活动的发言人。我住在爱尔兰，最后我通过我的一.

最近，马丁·福勒( Martin Fowler)2018年在澳大利亚敏捷论坛发表主题演讲，其中阐述了2018年的敏捷状态.提出干净架构的马丁鲍勃大叔发表文章表示赞同，并总结了该演讲的主要观点:小心敏捷.