敏捷是否会迫使开发人员花费更多的时间进行实际工作？

从常见的敏捷实践来看，在我看来，他们（有意还是无意？）迫使开发人员花更多的时间在实际工作上，而不是阅读博客/文章，聊天，喝咖啡休息时间和仅仅拖延时间。

特别是：

1）配对编程-最大的工作人员，只是因为当你们两个坐在一起时进行所有拖延操作很不方便。

2）短篇小说-当您必须在一个月之内完成大量工作时，通常很松懈的做法是在前三周松懈，然后在最后一周切换到OMG DEADLINE模式。

而只有很少的块（必须在一天或更短的时间内完成），情况恰恰相反-您觉得时间紧迫，没有机动的空间，您很快就要对任务负责，所以您开始立即工作。

3）团队沟通和凝聚力-当您在缓慢，遥远且安静的环境中表现不佳时，可能会感觉不错，但是当在Scrum会议结束时，每个人都夸耀了自己的成就，而您无话可说，您可能会真正感到自己羞愧。

4）测试和反馈-同样，它可以防止您保持任务“ 99％准备就绪”（实际上是20％左右），直到突然出现截止日期为止。

您是否觉得在敏捷下比在“常规”方法下工作更多？这种压力是否可以通过更舒适的环境和实际完成正确的事情的感觉来补偿？

敏捷方法背后的主要思想是在积极的方面帮助您提高生产力。如果您在截止日期前每天花一个小时上网，没人会在乎。如果您每天冲浪半小时，但错过了截止日期，每个人都会生气。解决方案：使您更轻松地完成截止日期。

如您所见，结对编程可确保您保持专注（在其他所有优点中，例如，提高技能/知识传播，更好的代码，更少的错误，统一的设计等）。

我发现纪律对我来说一直是一场斗争。如果我与某人配对，我们中的一个人很可能希望今天完成一些工作，而其他人则继续前进。因此，“一个月的工作”通常变成“一个星期的工作”，这让大量的工作最终解决，花了一天左右的时间恢复（重构，在代码中修复TODO，添加一个几次测试，以明显的良心冲浪），然后抓紧下个月的工作。

最终结果：我放松了很多（这是因为尽管有不断的监督，但团队凝聚力却要好得多，工作可以更快地完成，人们不会在几个小问题上闲逛几个小时甚至几天（因为其他人可以更快地发现问题）。

当您说“您可能实际上感到羞愧”时，这不是一件好事吗？这意味着您觉得自己做错了，应该这样做。您没有得到报酬，无法完成任何事情。没有做任何事情会使您感到无助，不快乐，不值得，痛苦。与其感到羞耻，不如站起来思考：“为什么我今天什么都没做？” 你需要帮助吗？有什么你不懂的吗？当前的任务太难了吗？你不喜欢吗 也许您可以与其他人切换任务。也许其他人可以帮助您度过难关。敏捷的意思是：承担责任，而不是像字符串中的木偶那样进行微观管理。您需要工具吗？去找你的老板问。学会争论。学会在必要时站起来大喊。

至于测试，当您的代码突然从“不错”崩溃为“完美”时，有一个最佳选择。那一刻，您发现需要实现功能X，并认为这将是一场噩梦，突然意识到代码几乎就在那里。在这里和那里只是一个小的重构。新的班级完成了。四个星期的工作突然变成了一天。胜利！胜利！

我同意。

配对编程

这是一种非常紧张和详尽的工作方式，除非有一些需要其他人指导的开发人员（例如，新手），否则我不会应用它。

短篇小说

团队沟通与凝聚力

测试与反馈

是的，敏捷，特别是Scrum可以极大地提高生产力。如果正确应用，则转换率可以高达20％（5个开发人员中的1个离开公司）。

原因很简单：Scrum不会提供更高的生产力it provides the whole company with much more visibility on what's going on（当然包括管理在内）。

• 对于开发人员而言，仅执行最低限度的工作就不可能了。最低限度现在是球队的平均水平！

• 这使得管理层无法正确协作。

这就是为什么我说（在其他类似问题中的回答），敏捷并不适用于每个组织（也不适用于每个人）。

例如，公共部门确实不适合敏捷。

敏捷被用作压力工具？当然，我已经看过很多次了。这只会使事情变得更糟。

您是否觉得在敏捷下比在“常规”方法下工作更多？这种压力是否可以通过更舒适的环境和实际完成正确的事情的感觉来补偿？

它使我工作更多，但最重要的是，它使我在正确的事情上工作。在任何给定的时刻我知道我该做些什么。

这是一种积极的压力。这与某些外部“您已经落后于进度，工作更多，代码超时！”完全不同。-种压力。

实际上，当我使用常规方法时，我的工作效率更高。使用常规方法，我可以在短短几个月内创建详细的需求分析，可行性研究，功能规范，技术规范以及许多会议协议。影响分析完成后，我什至可以创建一些代码行！

敏捷，我创造的只是一些可交付成果。

在我们公司

结对编程-当真正复杂的事情确实需要进行广泛的分析时，即使我们将两个出色的人聚集在一起，并在很短的时间内完成任务。在这里，任务的复杂性决定了结对编程的必要性。

短篇小说-然后放松了3个星期（每天大约5-6个小时），并在最后一刻（每天大约12到14个小时）匆忙作为开发人员，我不希望自己的工作负担出现波动。每天大约工作8个小时，保持时间表稳定，这看起来总是很酷。

团队沟通和凝聚力-在Scrum会议中，我们不仅共享任务状态，而且共享障碍。在这里，当某人确实需要帮助时，其他成员实际上会提出他们的想法来帮助他。但是，当然，您需要一支优秀的团队，我们是:)

测试和反馈-当然，作为开发人员，我不希望自己最终被Bug所困扰，在发现错误后的第二刻，便是要对其进行修复，然后再进行一次修改，这将使我对应该/应该做什么有一个好的预测接下来进行操作，并相应地重新安排截止日期（如果需要）。

因此，作为一名开发人员，我对自己承担的那种任务感到非常满意，并且可以肯定地说，我从未感到过截止日期的真正压力。

您是否觉得在敏捷下比在“常规”方法下工作更多？

• 如果您的意思是说在敏捷下我会觉得自己更有生产力，那我就说这取决于。
   
  _{我通常以法拉利（传统）和陆虎（Scrum）的角度来考虑。在高速公路上行驶时，法拉利击败了Landrover。
   
  当人们需要吉普车而不是跑车时，这是越野-我的意思是，如果您的需求不规律和/或团队工作和管理经验不是那么好，则您必须选择Scrum-仅仅因为尝试常规将获得你卡住了-就像法拉利会卡在越野车上一样。}

至于“更多工作”，我想一个期望这样的东西可能会低估程序员的智商和他们适应各种形式的管理痴呆症的能力。

到目前为止，我参加了两个Scrum团队，分别在不同的公司中进行不同的项目。在两个团队中，与瀑布/迭代相比，我的习惯都没有发现任何变化。

我很自豪地说这是因为我是如此特别和无敌，但是坦率地说，我也看到团队中其他所有人的习惯也无敌。

敏捷迫使程序员做更多有用的工作，因为各种敏捷开发技术可以清除繁忙的工作和不需要的工作。

当你们两个坐在一起时，拖延所有的拖延是不方便的。

我不同意。我曾与一群吸烟者一起工作，他们都设法延长了休息时间，因为“每个人都在这样做”。

前三周通常会松弛

无论采用哪种方法，这都表示管理不善。即使一个月内要交一大笔钱，我也希望在第一周结束时能看到一些东西。

您无话可说，您可能会感到羞愧。

如果您愿意推迟三周，那么您会想到一些废话。

4）测试和反馈-同样，它可以防止您保持任务“ 99％准备就绪”（实际上是20％左右），直到突然出现截止日期为止。

瀑布项目可以进行测试和日常构建。

就个人而言，我不想编写代码，而且一个月都没有做任何事情。我更喜欢代码上的较短反馈循环，无论是代码审查还是用户签收。让别人认可我的工作是有益的。就像猫在您家门口放下鼠标只是为了让您知道她正在工作。

敏捷并不会迫使开发人员做更多的工作，而是要提高工作效率

提出“迫使开发人员更多地工作”这个问题时，会遇到一些负面影响，但是，如果我们实际上能做得更多而减少拖延时间，那么肯定是积极的吗？

话虽如此，这是一个好点。今年我一直对敏捷感到不高兴，但这是我从未意识到的巨大的书面好处。

我同意敏捷可以使开发人员提高生产力。您关于可见性，问责制和减少拖延倾向的观点都是正确的。

但是敏捷可以并且也应该导致开发人员出于积极的原因而更加努力地工作-胡萝卜还是硬木。如果做得好，敏捷将为开发人员提供与用户更多的互动，减少用户的美度，更好地控制他们的工作，所有这些都可以使您的团队获得更多收益。

更多的工作在语义上仍然不正确或与敏捷无关，目标是提高生产力。它特别着重于减少对错误事物的处理，而更多地关注对正确事物的正常处理；这并不意味着更多的工作，而是更有效率。

副作用是，它确实会使松弛者和效率低下或不称职的松弛者很快暴露出来。听起来更像是您正在得到什么。

方法论与开发人员是否不工作无关。流程是，即使在瀑布式管理中，管理评审和代码评审也可以揭露它们无所作为，只是不像大多数敏捷方法那样透明。

“枪不杀人。人杀人！” 敏捷也是如此。敏捷并不能使人们更多地工作，管理者可以使人们更多地工作。