Tony

Jen，文章写得太棒了！
我还经常听到另一种说法：“如果敏捷对你不起作用，那一定是你的做法有问题”。 这句话太不真实了...

我曾在一些公司工作过，他们的冲刺计划时长都是固定的，无论他们正在进行什么项目。

我见过用户故事被纳入冲刺，但没有进行详细分析，例如定义以下内容：
1_ 故事所需的数据库模式数据
2_ 实现用户故事目标所需的活动
3_ 需要应用的业务规则
4_ 是否需要设计会议
5_ 可重用性分析

如果以上用户故事细节没有实践，那么失败的风险很高。
如果我们等到冲刺中期才发现这些细节，那么由于开发人员必须等到细节从含糊不清变得清晰，因此在本次冲刺期间无法完成的风险也很高。

敏捷框架并没有帮助团队了解如何在执行分析和设计时变得敏捷。
它只是一个很棒的框架，适用于
1_ 更好的沟通
2_ 产品演示
3_ 冲刺任务计划
4_ 流程改进

我会继续使用你的格言并补充它...
“做正确的事
为了你的团队
为了你的项目
为了你的产品待办事项”

SDLC 框架或流程不会构建软件。
遵循软件工程最佳实践进行分析、设计、编码和测试，将帮助你构建健壮的软件，并最大限度地降低你在选择遵循任何 SDLC 框架时失败的可能性。

嗨，Mladen

我同意你的观点，敏捷的唯一受益者是那些颁发证书和销售书籍的人，他们的新流行语让软件工程师感到困惑。

我将实话实说，并敢于其他 IT 专业人士也实话实说。

我从事软件工程师工作超过 30 年，并获得了 Scrum Master 证书，发现了以下内容

1_ 需求被重命名为用户故事。
2_ 开发任务计划被重命名为冲刺计划。
3_ 改进会议被重命名为回顾会议。
4_ 团队负责人被重命名为 Scrum Master。
5_ 团队沟通被重命名为站立会议。
6_ 2 到 4 周的计划被重命名为冲刺。
7_ 业务干系人被重命名为产品负责人。
8_ 干系人评审被重命名为冲刺演示。
9_ SDLC 阶段被两极分化为瀑布模型，这是非常不真实的

以下关键角色已从团队中移除
A_ 项目经理
B_ 业务系统分析师

坦率地说，敏捷给 IT 行业带来了混乱，迟早会被取代或调整，以帮助 IT 专业人士更有效地执行 SDLC 的所有阶段，包括计划、需求分析、设计、编码、测试和部署。

我不喜欢流行语，我遵循良好的高效软件工程原则来构建可靠的软件解决方案。

遵循敏捷并不能构建可靠的解决方案，而是需要软件工程工作来应对 SDLC 的每个阶段，具体取决于项目规模和团队对构建可靠软件所需的工件以及良好的项目交付计划的需求。

让我们不要仅仅因为它是趋势或酷炫的流行语而遵循流程，请确保你的团队遵循良好的软件工程实践，无论你想采用什么框架。

非常感谢您对我的回复的评论。