问题标签 [agile-processes]

我们一直在寻求在我们地理分布的开发团队中实施敏捷方法，因此我需要有关您使用并发现有用的任何免费在线应用程序的建议。

现在我们正在使用纸卡和墙来管理这个:)，但我们希望转向在线版本，最好是免费的。

我在以前的工作中使用过 TargetProcess！

我的核心要求是：

• 业务分析师可以添加用户故事
• 我们可以为开发人员分配不同的用户故事，并对其进行优先级排序。
• QA 团队可以围绕不同的用户故事添加测试用例。
• 项目经理可以跟踪所有资源的时间，并可以为上层管理拉报告

我在一个小型敏捷开发团队工作，该团队隶属于一家大型非敏捷思维公司。目前，我们在练习 Scrum，有时我们会超过我们的 sprint 承诺。

我的问题是，当你超过你的 sprint 承诺时，你如何处理燃尽图？我可以想到两个选择：

• 向负方向延伸y轴并继续倒计时
• 添加更多卡片/故事/作品，并让烧毁值增加该数量，当工作完成时烧毁。

对我的团队来说，最终的解决方案是对业务清晰且为开发人员增加真正价值的解决方案。到目前为止，这些解决方案都没有完美解决。

这个线程是我之前的一个后续。这实际上是 2 个问题，所以我希望没有人介意，因为它们是相互依赖的。

我们正在工作中开始一个新项目，我们认为这是一个在实践中尝试敏捷技术的绝佳机会。我们对在几本书和文章中阅读的想法进行了头脑风暴，并提出了最适合我们的概念：2 周迭代，然后与客户联系，他们会选择他们想要在下一次迭代中拥有的东西。我还有几个问题，我们自己也搞不清楚。

第一次迭代要做什么？

一般来说，如果我们从头开始，在最初的几次迭代中应该做什么？只是给它一个月的开发时间来编写应用程序的核心代码，还是从具有有限预编码功能的简单线框开始？客户通常希望看到什么？闪亮的东西不起作用或丑陋的东西起作用？

如何与客户沟通？

我们最初的想法是将流程设置为这样的：

替代文字 http://img690.imageshack.us/img690/2553/communication.png

在客户端设立联络点是个好主意，还是直接与所有客户沟通以防止沟通不畅更好？

欢迎任何想法！提前致谢。

我怀疑我的合并信息已损坏，但我不确定。有谁知道我将如何做出决定以及有哪些资源可以帮助解决问题？

这就是问题所在。我的团队最近转向敏捷并使用功能分支（实际上是故事分支），不同的团队同时处理相同的资源。随着故事达到高度就绪状态，团队合并到主干。由于缺少更改、意外更改和冲突，合并需要几天或几周的时间。我们谈论的是 5-10 人的团队，工作量/流失率似乎很高。

人们使用这种合并模式 a) PULL - 合并主干到分支，解析，测试，提交 b) 推 - 合并分支到主干，解析，测试，提交 c) 重新创建分支（或通常创建新的故事分支和完成后就老掉牙）

到此结束时，分支和树干应该对齐。

我们看到的问题：

1. 在主干到分支合并期间未报告的更改显示在后续的分支到主干中
2. 合并期间 svn:mergeinfo 属性的冲突
3. 文件丢失，但对分支中添加的新文件进行本地编辑并推送到主干
4. 传入 + 本地删除（在主干和分支上删除的文件显示为冲突）

(1) 不应该发生。从分支到主干的拉动应该使两者在主干上已经发生的所有更改同步。分支到主干合并中的更改是主干上发生的更改。因此，在第一次合并中，它们应该传播到分支但没有传播。这表明合并信息数据中的损坏会“隐藏”主干更改。

(2) 不应该发生。SVN 应该管理合并跟踪中的更改。这也表明 mergeinfo 数据损坏

(3) 不应该发生。这是在分支上添加新文件的情况。它应该显示为添加到主干的新文件。这也表明合并信息数据损坏。

(4) 我相信这是一个 SVN 错误，我们无法修复它。如果这是我们唯一的问题，我会很高兴

我们目前在 svn 1.5.x 服务器上，客户端使用 svn 1.6.x 和 svn+ssh 进行连接。我们计划升级到最新最好的 SVN，因为一些修复可能会影响我们的问题。

不过，看起来我们的 mergeinfo 数据确实是错误的。

• 不报告所有更改的合并
• mergeinfo 属性合并中的冲突

有什么好地方让我开始寻找吗？

敏捷/Scrum 是答案吗？Scrum 如何处理这个问题？

一个产品负责人，一个产品待办事项与多个产品负责人和产品待办事项？

它如何为您工作？请分享你成功失败的故事？

我正在尝试将一个流程放在一起来管理多个工作队列，从基础设施项目、简单的功能增强到大型项目，以及一个由 6-7 名开发人员组成的小型开发团队。

这些天听到很多关于 DevOps（运营中的敏捷技术）的信息。有人可以了解实际开发人员在此过程中的参与程度吗？

我们有两个不同的敏捷团队，每个团队都致力于独立但相关的应用程序。
到目前为止，每个团队都能够以独立的方式工作（不同的代码库、持久性存储、冲刺、积压等）。最近，产品管理部门决定这些应用程序将更加紧密地集成在一起。附带说明一下，每个团队（由 QA、Dev、BA 组成）的规模将在未来 6-12 个月内增加。

管理层决定在很大程度上保持敏捷过程的完整性，因为它运行良好（两个团队尽可能独立工作），但提出了将基于合同的服务层作为集成应用程序的手段的想法。

在每个 sprint 中，将确定需要与其他应用程序集成的任何故事。届时，将在其他团队的待办事项中添加一个额外的“整合”故事。然后，该团队将负责履行合同。与此同时，另一个团队可以继续他们原来的故事工作，替换一个 mock/fake 服务，直到另一个团队产生一个工作服务。

由于敏捷宣扬 KISS 哲学，团队中的几个人对这种方法的“复杂性”提出了质疑。他们提倡继续使用存储过程共享作为一种“过去运作良好”的更精简/更简单的集成方法。

出于各种原因，我更喜欢基于契约的编程，但主要原因是它能够为您的应用程序预期提供的行为提供编译时可见性。您还可以清楚地了解谁拥有什么代码，以及如果您违反合同，您可能会破坏谁的代码。存储过程不做这些。

由于我们已经从敏捷中获得了很多好处，我想已经有一种“敏捷友好”的方式来处理这种应用程序集成/同步。创建基于契约的 SOA 层是否符合敏捷气味测试？有没有我没有考虑过的第三种选择？

我们的 IT 经理正在推动 ITIL，我只是对它不太熟悉，想知道 ITIL 是否适合敏捷工作周期？

从我最初的印象来看，我认为不会，主要是因为我们的经理提议的是对所有事情设定时间表，向业务说明 SLA “必须在 x 小时内完成高优先级任务”等......我们作为开发人员会受到惩罚如果我们不满足这些 SLA。

如果有的话，我更喜欢一种谈判策略，其中时间表基于敏捷的速度和故事点方法，以便与最终用户协商预期的时间范围。

我们有我们的敏捷开发实践、测试驱动开发、持续集成，还有需要改进的地方，但我们正在努力。

ITIL 和敏捷方法协同工作的其他经验是什么？

当我是初学者时，谁能简单地解释一下螺旋模型和敏捷模型之间的区别？你能给我一些真实世界的例子吗？螺旋比敏捷更有用，反之亦然……我知道互联网上有很多链接，但由于我是初学者，它们很难理解。所以如果你用简单的术语解释会很有帮助？ ? 提前谢谢...

假设您正在编写一段遗留代码，该代码是在您的公司开始使用像 Scrum 这样的敏捷方法之前编写的。

现在假设您在该领域发现了一个需要修复的错误，并且从未编写过该功能的故事。团队中的每个人都知道那个特别的功能是什么以及它应该如何表现，但只是没有与之相关的故事。

现在，在当前的 sprint 中，您将处理该缺陷，因为营销和支持已经厌倦了处理该问题。

您是否创建了一个回顾该缺陷的故事？您是否将缺陷重新标记为故事并修改格式以使其看起来像故事？如果您不创建故事，您是否会因缺陷而获得积分？如果您确实创建了一个故事，您是否会因修复缺陷而获得积分（通过故事的积分）？

处理这种情况的最佳方法是什么？

更新：假设安装过程突然开始在 Windows 7 64 位系统上蓝屏，并且一直要求应用程序安装在所有 Windows 平台上。新问题可能是由于 Service Pack 1 或类似的东西而出现的。