问题标签 [agile-processes]

我正在制作一种将 Scrum 与 OpenUP 生命周期和可交付成果相结合的方法。我还想将 OpenUP 学科与“项目管理”分开。我可以“隐藏”它，这样它就不会在我生成的方法站点中立即显现出来。但是，当您然后导航到“风险列表”工件时，例如 PM 仍然被视为有贡献，如果您单击链接，您将被带到 PM 纪律页面。

如何从我的方法中完全删除它而不从我正在使用的 OpenUP 库中删除它？

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

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

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

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

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

我们使用 JIRA 进行错误跟踪和发布管理，我们已经开始使用 greenhopper 在 JIRA 内部进行项目管理，但它缺少的一件事是用户故事与这些用户故事中的任务的概念。有没有人推荐其他任务板，例如完全支持用户故事和任务以及对用户快速简单的敏捷项目管理工具。我开始研究 targetprocess，所以如果有人对此有特别的反馈，那也很好。

“持续实施”是软件开发方法的名称吗？如果是这样，它究竟是什么？

你有使用它的经验吗？

请注意，我知道什么是持续集成，但不知道持续实施。

背景：今天我了解到（二手）一家在其软件开发环境中使用“持续实施”的公司。它是正式定义的还是某些敏捷软件开发方法的一部分？

我能找到的最好的是欧洲信息系统杂志上的这篇论文：

通过场景开发和持续实施实现敏捷性

“……沃尔沃的一项业务和 IS/IT 计划……开发和实施灵活的售后市场供应链……创建一个平台、Web 服务和一个用于通过 Internet 销售备件的 Web 门户。”

在我看来，敏捷方法论鼓励我们保持简单、精简，而不是在需要时才增加复杂性和复杂性。但技术变革的速度和规模鼓励使用越来越抽象、复杂和复杂的工具和模式，以复杂的方式解决我们可能尚未（并且可能永远不会遇到）的问题，并具有显着的学习曲线和大量的努力投资。

在项目中实施敏捷需要进行重构的能力。这并不是必须的，但代码重构已被证明是一种很好的工程实践。

在 iSeries 平台上的敏捷 (Scrum) 项目中，需要在 RPG、RPG LE 中进行开发（新代码和对遗留代码的修改），是否可以实现重构？如果是这样，有什么技术可以做到这一点？

如果尝试过的人可以分享他们的经验或只是指出参考，我将不胜感激。

我很好奇其他人在他们的公司中将什么用于物理看板/Scrum 板。我很感激由于敏感的商业信息，您可能无法提供董事会的照片。我正在寻找您的董事会是什么样的，以及您如何组织用户故事和任务，因为他们通过一个典型的冲刺/迭代？

通常，我曾在一个组织董事会的地方工作过

所以总结一下：

• UC-001 的一项任务正在由团队的一名成员 (Bob) 进行。待办事项列中正在等待其他人完成的任务列表，但可以由与 Bob 协调完成工作的团队中的其他成员提取。
• 对于 UC-002，支付服务任务已完成，并为 QA 完成了自动化测试工具，允许他们在没有 UI 的情况下测试服务。如果测试失败，则会引发错误并与支付服务任务一起移回 QA 阶段
• UC-003 的所有任务都已完成并移至准备好进行 QA。
• UC-004 和 UC-005 的所有任务都已完成，因此用户故事已移至完成。

这就像一个有形的白板，涉及人们与每个任务/用户故事（表示为便笺）进行交互。电子版本在冲刺/迭代之前创建，并且仅在与当前情况相对应的冲刺/迭代结束时更新。欢迎评论和批评：）

我正在一个团队工作，该团队正在探索采用敏捷开发实践的可能性。

我们遇到的一个问题是决定何时完成迭代（冲刺）。

假设我们已经定义了我们的功能积压，并为它们生成了故事点估计，并且我们已经决定第一个 30 天的冲刺将包括功能 A、B、D 和 F。如果你遇到了你应该怎么做'再次到达 sprint 的终点，您已经完成了 A、D 和 F - 但 B 只完成了 80%。你应该：

1. 按时完成 sprint，但排除功能 B（将剩余工作推迟到未来的 sprint）

2. 将 sprint 延长到完成功能 B 所需的时间，但不要开始下一个 sprint。

3. 将 sprint 延长至完成功能 B 并开始进行下一个 sprint 所需的时间。

4. 使整个 sprint 失败，并将所有工作捆绑为未来版本的一部分。

我在选项 1 中看到的问题是团队没有兑现承诺。在某些情况下，您可能无法在不使整个版本无用（或至少显着降低价值）的情况下排除功能 B。如果没有特征 B，可能很难指导下一个 sprint 的方向。

选项 2 的问题是团队中的一些成员可能会在很长一段时间内处于空闲状态 - 这会影响整体生产力。您可能能够添加更多的单元测试，或润色特性，但它不会增加成比例的价值。在政治上也很难向管理层解释为什么你的大多数团队都处于闲置状态。

选项 3 似乎与敏捷精神背道而驰——您不允许前一个 sprint 的结果指导下一次开发迭代，从而使下一个 sprint 处于危险之中。

选项 4 似乎很严重，并且与选项 1 和 3 有大部分相同的问题。首先，你完全错过了一个承诺。其次，将更多功能捆绑到后续版本中会使与客户进行测试和验证变得更加困难——并且它再次排除了根据之前的反馈来指导未来迭代的能力。

我的团队的目标是最大限度地减少我们的构建被破坏的时间。

我们使用 CruiseControl.NET 进行持续集成。我想知道如何最好地回答以下问题：

“在最近的 {timespan} 中，{project-name} 花费了多少时间处于损坏状态？”

例如：“在过去的 1 个月中，我们的项目有多少时间处于损坏状态？”

CruiseControl.NET 是否有任何高级功能可以帮助在某种类型的报告或仪表板中的某处提供这些信息？

或者，您将如何解析 xml 工件文件以收集此信息？

产品正在作为功能而不是发布来开发和交付，这意味着在完成功能后，它会被推送到登台，然后再投入生产。开发中可能有多个功能，并且交付时间线重叠。因此，在任何时候，开发数据库和源代码控制都具有多个开发功能。功能完成后，我只想将功能特定的代码和数据库更改推送到登台。事实证明，此过程容易出错且耗时，原因如下：

• 特定功能的数据库实体不是独立的，而是与其他功能相关且相互交织的。因此，分离出特定于功能的实体非常耗时，有时难以实现。有没有更好的方法呢？
• 在服务器端代码上，类似地分离出特定于功能的代码与 db.xml 一样繁琐。将 .NET Entity Framework 置于 DB 之上并进行其他性能优化（例如预生成视图），是否有更好的方法来部署基于功能的开发？

开发环境包括 SQL Server 2008、.NET、带有用于源代码控制的 SVN 的实体框架。

这里的术语特性与 FDD 敏捷模型无关。

有没有人有过类似的经历？

非常感谢！