scrum

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

敏捷方法为团队提供了在收集业务需求时同时开始创建软件的能力。因此，通常被称为“分析建模瘫痪”的现象不太可能阻碍团队前进。事实上，敏捷方法论以其使项目能够创建“正确”产品的能力而广受赞誉。它使团队具有竞争力，并通过不断的重新计划，有助于保持产品与市场的相关性，并确保团队的努力得到认可并及时发布

在许多敏捷项目中，需求通常不是以正式需求文档的形式编写的。取而代之的是，通常使用一组简洁而有效的方法来描述必须构建的内容，即用户故事。用户故事从客户的角度描述了系统的行为，性能或界面。一个典型的用户故事可能看起来像这样：作为潜在的客户，我希望能够根据输入的搜索条件查看书籍。</

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

我们的一些团队成员是Allen Holub的追随者。他是noEstimates方法的

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

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

在当今瞬息万变的市场中开发现代SaaS产品，需要克服各种极端不确定性，需要比Scrum还要敏捷得多的东西！让我们面对现实吧！ Scrum真的不是那么敏捷：我已经拥有20多年的Scrum，足够长了！当时转向使用Scrum无疑是在敏捷阶梯上的进步，但是因为在我整个职业生涯中都一直再使用S

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

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

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

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