问题标签 [agile]

我们刚刚开始一个包含许多子项目的非常大的项目。我们目前不使用任何类型的命名流程，但我希望通过后门获得某种敏捷/类似 scrum 的流程。

我将最关注的领域是整个项目的积压工作，至少在我的脑海中，迭代的想法是从积压工作中提取一些东西，更详细地研究并开发到合理的截止日期.

我想知道人们使用什么技术将项目分解为待办事项，以及一旦创建了待办事项，它是如何维护和排序的。以及如何维护元素之间的关系（即必须在可以这样做之前完成，或者这是一个故事现在是五个故事）

我不确定我期望这个问题的答案是什么样的。我认为最有帮助的是，如果有一个开源项目以某种方式保持其积压在线，以便我可以看到其他人是如何做到的。

其他可以从我那里得到+1的东西是来自真实项目的真实用户故事的例子（“用户可以登录”的故事并不能帮助我描绘我的项目中的事物。

谢谢。

大多数 Scrum 团队都有某种白板或其他白板，可以在上面可视化当前 sprint 的故事/任务。

我很好奇人们是如何组织这个董事会的？你使用便利贴吗？它们是彩色编码的吗？你如何对任务进行分组？你如何区分任务的状态？ETC...

我最近听说过 BDD，发现它与 TDD 非常相似。

您使用这两个中的哪一个（如果有）？

各自的优缺点是什么？

我一直使用敏捷的功能驱动开发流程来开发软件。其他人都用什么，你为什么喜欢它？我更喜欢 FDD，因为那是我刚从大学毕业时开始的。在大学里，一切都非常自由，我的“客户”通常是我的教授，除了为大学做研究之外，他可能没有太多的行业经验。

现在，我的客户不那么宽容了，我在医疗领域做了很多工作。敏捷和高质量是必须的！

We attempt to do agile development at my current job and we succeed for the most part. The main problem seems to be that the developers on the project are always waiting for requirements at the beginning of the sprint and rushing to get get things down by the end. The business analysts who are delivering the requirements are always working non-stop to get the requirements done.

EDIT: Additional Information: We are customizing a COTS application for our internal use. Our 'user stories' just consist of what part of the application we will be customizing in the specific sprint and also what systems we will integrate with internally. The integration with different systems normally works pretty well because we can start working on that right away. The 'customize x screen' are the main problems areas because the developers can't do anything from that. We have to wait until we get the requirements from the BAs before we can really do anything.

EDIT: More insight/confusion perhaps: I wonder if part of the problem is that the screen that are being customized are already there as this is a COTS product that is being heavily customized. People suggest that the user stories should be along the lines of 'make a screen that does X'. That's already done. Maybe there isn't a good way to do user stories for these requirements... maybe this need to be a whole new question.

我有两个关于 Scrum 的相关问题。

我们公司正在努力实施它，并确保我们跳过了篮球。

这两个问题都是关于“完成意味着完成！”

1) 为已经/有的任务定义“完成”真的很容易 - 明确的测试验收标准 - 完全独立 - 最后由测试人员测试

应该如何处理以下任务： - 架构设计 - 重构 - 一些实用程序类开发

它的主要问题是它几乎完全是内部实体，无法从外部检查/测试它。

作为示例功能实现是一种二进制 - 它已完成（并通过所有测试用例）或未完成（不通过某些测试用例）。

我想到的最好的事情是请另一个开发人员审查该任务。但是，任何方式都没有提供明确的方法来确定它是否完全完成。

那么，问题是您如何为此类内部任务定义“完成”？

2) 调试/错误修复任务

我知道敏捷方法不建议执行大任务。至少如果任务很大，应该将其划分为较小的任务。

假设我们有一些相当大的问题 - 一些大的模块重新设计（用新的架构替换新的过时架构）。当然，这个任务分为几十个小任务。但是，我知道最后我们将进行相当长的调试/修复会话。

我知道这通常是瀑布模型的问题。但是，我认为很难摆脱它（尤其是对于相当大的变化）。

我应该为调试/修复/系统集成等分配特殊任务吗？

在这种情况下，如果我这样做，通常这个任务与其他所有任务相比都是巨大的，而且很难将它划分为较小的任务。

我不喜欢这种方式，因为这个庞大的单体任务。

还有另一种方法。我可以创建较小的任务（与错误相关），将它们放在积压中，确定优先级并将它们添加到活动结束时的迭代中，当我知道错误是什么时。

我不喜欢这种方式，因为在这种情况下，整个估计都会变成假的。我们估计任务，随时将其标记为完成。我们将使用新的估计打开新的错误任务。所以，我们最终会得到实际时间 = 估计时间，这绝对是不好的。

你怎么解决这个问题？

问候，维克多

显然我们使用 Scrum 开发方法。一般是这样的：

开发人员为了完成他们的任务而苦苦挣扎。通常，这些任务需要大部分 sprint 才能完成。QA 缠着 Dev 发布他们可以测试的东西，Dev 最终在 sprint 结束前一两天向 QA 抛出了一些错误的代码，剩下的时间用来修复 QA 发现的错误。QA 永远无法按时完成任务，sprint 很少能按时发布，Dev 和 QA 在 sprint 结束时的日子过得很痛苦。

当可发布的开发任务占据了 sprint 的大部分时间时，scrum 应该如何工作？

感谢大家参与讨论。由于这是一个非常开放的问题，似乎没有一个“答案”——下面有很多很好的建议。我将尝试总结我的一些“带回家”的观点并做出一些澄清。

（顺便说一句 - 这是放置这个的最佳位置还是我应该把它放在“答案”中？）

思考/行动的要点：

• 需要确保开发人员的任务尽可能小（细化）。
• Sprint 长度应根据平均任务长度适当调整（例如，1 周任务的 sprint 应至少为 4 周）
• 团队（包括 QA）需要努力提高估算的准确性。
• 考虑并行进行单独的 QA 冲刺，但如果这对团队最有效，则可以抵消
• 单元测试！

如今，Scrum 是相当流行的 dev.process 并且经常项目经理突然获得新头衔（Scrum Master）。然而，它不应该只是一个新的标题，而是新的习惯和新的范式。你的 Scrum master 有哪些坏习惯？

在规划新系统开发的最初阶段，遵循哪种开发模式似乎至关重要。我一直坚信经典瀑布（或混合瀑布/迭代原型）是大中型项目的最佳方法。似乎一旦项目达到一定规模，敏捷/XP/Scrum 范式就无法解决复杂的需求、大型团队、多个子系统之间的复杂性、文档需求、人员变动等，等等

这种敏捷方法在系统规模、团队规模、LOC 等方面的限制是什么？

我听说很多公司表现得好像他们很敏捷，但他们所做的唯一敏捷的事情就是 Scrum 流程。这足以被认为是敏捷的吗？单独使用 Scrum 似乎是一个糟糕的经理更频繁地召开更多会议的完美借口。我应该厌倦这样的公司吗？