问题标签 [agile]

我对 TDD 有复杂的感觉。虽然我相信测试，但我对测试驱动我的开发工作的想法有疑问。

当您编写代码以满足为满足您现在的需求的接口编写的一些测试时，您可能会将注意力从构建可维护的代码、简洁的设计和健全的架构转移。

我在驱动而不是测试方面遇到问题。有什么想法吗？

所以我有一个积压的功能，我们即将开始一个相当大的项目。我正在努力定义我们 sprint 的结构，我对社区的反馈很感兴趣。

我在想的是：

• 一日冲刺计划
  • 填写待办事项并弄清楚每个开发人员在这个 sprint 之后会做什么
• 三周的开发
  • 去！去！去！
• 每日站立会议
  • 检查是否有人需要帮助或感觉偏离轨道
• 两天的冲刺评审
  • 代码审查在这里进行，利益相关者演示
• 一日冲刺回顾
  • 我们在上一个 sprint 中完成了什么？下次我们怎样才能做得更好？

冲刺应该总是在周二结束（以避免周末压力过大）。

还要别的吗？敏捷显然不止于此。我想为团队提供一个简单的大纲，说明我们在启动这个项目时将如何运作。

我们已经使用 Scrum 大约 9 个月了，而且基本上是成功的。然而，我们的燃尽图很少看起来像“模型”图表，而更像是一个可怕的过山车，带有一些呕吐物引起的爬升和下降。

为了尝试解决这个问题，我们在 sprint 原型设计和设计之前花费了更多时间，但我们在 sprint 期间发现的工作似乎仍然比最初想象的要多得多。注意：我的意思是满足积压工作所需的工作比最初想象的要复杂得多，而不是我们已经确定了积压工作的新项目。

这是 Scrum 的一个常见问题吗？是否有人有任何提示可以帮助顺利进行？

我应该指出，我们的大部分开发工作都不是全新的，因此我们正在维护现有大型复杂应用程序的功能。Scrum 是否不太适合这种类型的开发仅仅是因为您不知道现有代码会抛出什么问题？

在 sprint 开始制定开发细节之前，我们应该花费多少时间？

更新：我们现在取得了更大的成功和更顺畅的旅程。这主要是因为我们在估计时采取了更加悲观的观点，这给了我们更多的喘息空间来处理没有按计划进行的事情。你可以说它让我们更加“敏捷”。我们还试图改变燃尽图是某种时间表而不是范围v资源指示的看法。

I've been applying agile for a few months now on my project. However we are seeing a steady problem with our iteration burndowns. We aren't hitting zero each iteration.

The tasks remaining are QA tasks. Things like writing tests, testing, etc.

Now, there is some organizational resistance to the "cross-functional team" idea of agile. Dev's develop for single projects but Testers are shared for multiple projects. Which is quite contrary to the agile idea of Dev's and QA working together.

The fact that my tester's time is split across so many other projects is the cause of our slowdowns. The developers are testing to pick up as much slack as they can, but some tasks are still not getting done.

From what I see, I can do two things:

1. Persuade the organization to move towards "each project having a dedicated QA person"
2. Change my definition of "Done" to not include QA/Testing work. Things would still be unit tested though.

I'd much rather avoid doing #2, since I value the testing collaboration we're doing.

What advice do you have for my predicament?

我在一个 4 人的小型开发团队中工作。我们正在尝试开发“敏捷风格”——故事点、小任务等......不幸的是，我们目前正在（共享）Excel 表中管理我们的任务。

我们查看了一些可用的工具（Mingle、TFS、Scrum for Team System），但所有这些看起来都会带来太多的开销，并且会让工作失去乐趣。

您的敏捷爱好者使用什么来长期跟踪您的任务？

更新 当前的最佳答案并不是我打算问的真正答案 - 从长远来看，我需要一些工具来帮助我找出我正确估计的功能和任务，以及我在哪里犯了可怕的错误。我看到白板/所有便利贴如何帮助管理当前或以前的迭代，但我没有看到自己在寻找 2 个月前的便利贴。

我在上一个项目中使用Cruise Control作为 CI 框架。对其他一些工具有什么建议吗？

（并不是说我发现缺少 CruiseControl，只是想知道是否有人进行了一些比较）

可能是主观的和/或讨论的......但这里有。

我被要求为工作中的下一件大事估计一个功能。我把它分解..使用故事点来估计。然而，除了各种其他公司计划之外，该功能还需要与第三方图表组件 GoDiagrams 进行交互。（一整套 2008_Limited_Edition 框架/服务：）。我一直在使用燃尽图跟踪自己，我发现我无法维持我的步伐主要是由于“尖峰”..定义

我估计每周工作 2 点，然后我发现自己在周末工作（很好地尝试......最终既不在这里也不在那里），因为我不知道在哪里挂钩，以便我可以预览用户操作，显示上下文菜单等。最后，我花时间制作尖峰，使我的日程表偏离轨道……并降低其价值……没有给出正确的画面。

钉子需要钉子穿过无知的木板。但是它们是如何被纳入估计方程的呢？在功能看起来错误之前执行所有必需的尖峰..（可能会变成 YAGNI）在两者之间执行它会破坏我的流程。现在它是在预迭代计划期间..但这每周都会将接触线推开。

团队中的一些成员在一起编程时遇到了问题。不同的性别，不同的文化，不同的年龄。如何处理这些问题？- 不要将它们配对在一起，或者 - 将它们配对在一起，让它们达到“黄金中间”

Do you think that project iteration length is related to project team size? If so, how? What other key factors do you use to recognize correct iteration length for different projects?

所以，在我目前的工作中，我们通常是每个项目有 1-3 名开发人员、1-2 名艺术总监和 1 名项目经理，最小的只是每个项目中的一名，而较大的则为 3 名开发人员和 2 名艺术总监。

我正在寻找一种软件、软件组合或某种类型的服务，以使我们能够单独管理我们的项目，重要的是我们能够在一个系统/软件中一次管理多个项目（无需经过每个项目的设置过程过于复杂），因为我们通常同时有 2-3 个正在进行的项目。

我们需要能够与 SVN 集成，跟踪错误/功能/请求，建立里程碑和某种类型的敏捷管理，比如 SCRUM 会很好。

最好它应该能够在 Windows 上运行（没有太多麻烦，曾经尝试在同一个 Windows 2003 服务器上安装 Apache+Python+Svn+Trac 并让它们一起运行？不好玩。）因为我们大多这样做。 NET 开发，我们的大多数服务器都运行 Windows 2003。