问题标签 [agile]

我在一个 10 人的团队中，正在处理一个不太理想的产品所有者的大型遗留代码库。我们的积压工作非常糟糕，大型史诗经常打破我们的冲刺。该团队还为完成的定义而苦苦挣扎——一些成员虔诚地编写单元测试，而另一些成员则没有，有时取决于可用的时间。

所以，我看到了一些有趣的燃尽模式，我想知道其他人看到了哪些模式以及它们的含义。

模式一：

• 正面解释：“一切都好。”
• 负面解释：“好得令人难以置信。到底发生了什么？”

模式二：

• 正面解释：“这比我们想象的要容易得多，让我们引入更多故事。”
• 否定解释：??

模式3：

• 正面解释：“起初不确定这项工作，后来发现比我们想象的要容易。”
• 负面解释：“进展不够，我们停止编写单元测试以按时‘完成’。”

是否有人将 Scrum 和 Sprint 用于基础设施。

我正在为永远不会完成的 Sprint 的概念而苦苦挣扎，即网络增强项目。

还有关于如何将项目时间建立到产品待办列表的任何建议，以便我可以理智地检查资源在 sprint 中是否被过度使用。

这是最好的教程、书籍、软件和实践，可以在没有经验的情况下以敏捷的方式启动和管理一个基于 .net 的新开发项目。哪种方法更容易采用 XP|Scrum？

似乎 Scrum 和敏捷测试/断言在今年变得流行起来。例如，诺基亚测试 Scrum。我认为进行这样的测试根本不是一个好主意。你怎么看？

我想在一个新项目中实现用户故事，我在哪里可以找到一个好的模板或敏捷开发中使用的其他模板？

在传统的 Waterfall 中，需求是按照深奥的模板收集的——通常是在 MS-Word 文档中。在“严格”的瀑布模型中，该文档在需求阶段之后被冻结，变更控制/变更管理流程负责引入受控变更。(**) [通常情况下，文件会变成“活文件”，最终变成“活生生的噩梦”]

目前，我要领导一个项目，该项目是将现有桌面应用程序重写为 Web（从 VB 6.0 到 ASP.Net）。客户有一个他想要重写的应用程序的基线版本。[所以需求被冻结......没有范围蔓延]。要按原样重用的数据模型。只迁移前端/业务规则。看应用程序，我觉得它最多只有 3/4 个主要屏幕，仅此而已。

一些团队成员想要在开始新开发之前记录（在我看来是老派的思想）整个事情。我和其他一些人认为，将 UI 转换为 Web 应该相对容易，查找旧代码，编写业务逻辑，进行自动化单元测试，进行集成测试并逐屏交付（或逐个业务功能）

我的问题是：在敏捷开发中，如果我不对其进行优化，我该如何保持“敏捷”。我的观点是写详细的文档是反敏捷的。你怎么看？敏捷大师将如何解决上述问题（将现有的 VB 6.0 应用程序重写为 ASP.Net）？

免责声明： 创建 1000 页的功能规范可能是为了履行合同义务、政治上的必要性，系统可能真的很复杂（现在，“复杂性”的定义是通往黑暗之地的旅程）。

If so, how do you deal with things that just don't "feel" right such as:

• not writing unit tests
• not having a continuous build
• not refactoring
• not having a team coding standard
• not pair programming
• not doing iterations
• no daily standups
• no retrospectives

Now, some agile organizations do leave out some of these practices, but most successful ones incorporate most of them.

What do you do to deal with the seeming chaos of the traditional development processes?

我们应该首先实施敏捷开发的哪个方面来改进我们的开发过程，为什么？

我的处境需要我“调整”我的流程，而不是重新设计它，而“敏捷”似乎是当今的口头禅。如果我们只能做出一项改变来改善某些东西——质量、上市时间、文档、透明度等，那么什么会产生最明显、最积极的影响？

如果我们选择正确，我们将能够做出第二选择。:-)

更新： 您当前的 SDLC 是什么？
环境：本质上是“重启”。少数开发人员；具有 10^5-10^6 LOC 并在全球部署数万个的遗留产品；产品具有很强的相互依存性；多年来添加的重要功能，包括许多一次性的，没有重构；时间紧迫；表面质量保证；没有验尸或“过程大师”。

典型流程：

1. 创建设计/规范。所有利益相关者的审查。
2. 编码一个或多个功能/修复。
3. 修改设计/规格以解决意外情况。
4. 测试功能，记录缺陷。
5. 优先处理新的和剩余的任务。
6. 修改设计/规格/时间表。
7. 必要时返回步骤 2。
8. 发布测试版，记录反馈。
9. 必要时返回步骤 2。
10. 正式发布。

感谢您提供这么多有用的建议和见解！

我们使用Trac作为我们的错误跟踪/开发/wiki 系统，我想知道是否有人有经验并使用了一些 Trac Agile/Scrum 插件或功能？你有什么推荐的吗？

或者将 Trac 票证复制为死树用户故事索引卡和手绘燃尽图会更好吗？

请注意，我在这里发现了一个类似的问题。尽管它专门针对 Scrum。他们推荐Agilo。有人试过Agilo吗？

我在 MVCStoreFront 应用程序上观看 Rob Connerys 的网络广播，我注意到他正在对最平凡的事情进行单元测试，例如：

会有一个像这样的测试：

虽然，我完全支持单元测试，但我有时想知道这种形式的测试优先开发是否真的有益，例如，在实际流程中，您的代码上方有 3-4 层（业务请求、需求文档、架构文档） ，其中实际定义的业务规则（折扣价格是价格 - 折扣）可能被错误定义。

如果是这种情况，那么您的单元测试对您来说毫无意义。

此外，您的单元测试是另一个失败点：

现在测试有缺陷。显然在一个简单的测试中，这没什么大不了的，但是假设我们正在测试一个复杂的业务规则。我们在这里得到什么？

快进两年应用程序的生命，维护开发人员正在维护它。现在业务改变了它的规则，测试又中断了，一些新手开发人员错误地修复了测试……我们现在又遇到了一个故障点。

我看到的只是更多可能的失败点，没有真正的收益回报，如果折扣价格错误，测试团队仍然会发现问题，单元测试如何节省任何工作？

我在这里想念什么？请教我热爱 TDD，因为到目前为止我很难接受它是有用的。我也想，因为我想保持进步，但这对我来说没有意义。

编辑：有几个人一直提到测试有助于执行规范。根据我的经验，规范也经常出错，但也许我注定要在一个规范是由不应该编写规范的人编写的组织中工作。