问题标签 [agile-project-management]

我正在从Redmine的实验安装切换到公司范围内使用。我们确实使用了一些我们必须使用的插件，例如 redmine_backlog 和 redmine_gitosis（未维护，存在多个分支）。redmine 发布 1.2.0 时，chiliproject刚刚发布 1.5.0，并确保主题和插件兼容。

让他们决定分叉 redmine 的原因让人觉得支持该项目的动机很强烈。似乎 chiliproject 的贡献者更多，更新更频繁。

因此，我正在寻找在类似生产环境中使用这些项目之一的利弊！

谢谢，

马修

在持续部署方面，敏捷项目有什么更好的工具——Go来自 ThoughtWorks 或JetBrains的TeamCity ？

我最近开始使用带有“GreenHopper”插件的“Jira”。但是，我不觉得这真的是在做我想做的事。我在“Scrumworks pro”中看到了一个很酷的功能，您可以将应用程序作为桌面应用程序运行。因此，我的要求包括：

• 必须有一个非常简单的 UI 来管理 Scrum 任务
• 最好有一个可以插入网络版本的桌面版本
• 它不一定是免费的，只要它摇摆不定！
• 它不能是一个被屠杀的应用程序，而是专门为 Scrum 设计的，有一个好的开发团队。
• 如果它能够以某种方式与 Subversion 集成，那也是一个额外的优势。
• 如果 sprint 可以将已完成工作的摘要发送给企业主，那将是另一个额外的优势。即自定义报告。

有什么建议么？

我们正在做看板，并有一个带有彩色贴纸的白板。由于有时团队是分散的（如家庭办公室），我们需要对该板进行另一种视觉访问。我们希望使用每个人都可以访问的固定网络摄像头来做到这一点。

我们的要求：

• 质量好的图片
• 通过物理缩放或通过高分辨率放大部分，使贴纸笔记可读（描述等）
• 通过浏览器网络应用程序访问相机，或者即时消息
• 与 linux 操作系统兼容的硬件/软件设置

你们有人设置过这样的东西吗？你的经验教训是什么？

拥有真实笔记的物理墙很重要。寻找另一个项目管理 Web 应用程序对我们来说不是一个选择。

我正在寻找“最好的”敏捷友好的功能和缺陷跟踪软件。目前，我们正在使用fogbugz，但据我所知，这对于遵循敏捷方法的团队来说并不是非常有用。有更好的工具，例如 JIRA 的 Greenhopper。我以前使用过 JIRA，但我想知道是否还有其他更好的工具。

我正在寻找一个特定的项目/任务跟踪工具：

1. 能够定义任务的层次结构。比如项目 -> 任务 -> 子任务等。
2. 分配所有者的能力。
3. 状态级别，例如 NotStarted、Inprogress、Impeded、Complete
4. 基于通知，即任何更改都应通过电子邮件或 RSS 提要通知。
5. 开源

谢谢。

我们遵循敏捷开发方法。作为 SCRUM 大师，我正在维护 Sprint BackLog。我想知道在项目中间为特定任务增加工作量的最佳实践是什么。

例如，我正在做 ABC 任务，在 sprint 开始时，我估计需要 10 小时才能完成，但第二天我意识到它需要 20 小时，那么我将如何更新 Sprint Backlog。

如何确定敏捷方法中的故事点值并确定团队速度？在网络搜索中能够得到定义但不能得到实际过程的解释。

我正在学习如何使用敏捷方法领导一组开发人员进行 RoR 项目。我在网上找到了一些工具，例如 VersionOne 或 PivotalTracker，它们可以帮助您创建迭代、积压、故事等，因此您可以将工作与前端和后端分开，并使您的开发人员完全专注于特定任务。

我的问题是关于你开始使用这个敏捷工具之前的步骤，创建故事和迭代，你的开发人员开始让它在每一个上成长。我的疑惑是关于技术、功能和非功能软件需求规范的步骤，所以当你弄清楚之后，你就可以开始写故事了：

http://en.wikipedia.org/wiki/Non-functional_requirement。

是否有工具可以指导您如何成功地将 Web 应用程序（或移动应用程序）的想法转换为故事/迭代列表？某种状态、特征或功能（及其关系）的视觉表示，您可以在其中指定功能、非功能和技术规范，然后您就可以创建故事了？

非常感谢您提前付出的时间和耐心。

在估计敏捷软件开发中用户故事的相对大小时，团队成员应该将用户故事的大小估计为 1、2、3、5、8、13……。所以估计值应该类似于斐波那契数列。但我想知道，为什么？

Wikipedia 上对http://en.wikipedia.org/wiki/Planning_poker的描述中包含了神秘的一句话：

使用斐波那契数列的原因是为了反映估计较大项目时固有的不确定性。

但是为什么较大的项目应该存在固有的不确定性呢？如果我们进行更少的测量，意味着如果更少的人估计相同的故事，不确定性不是更高吗？即使在较大的故事中不确定性更高，为什么这意味着使用斐波那契数列？有数学或统计原因吗？否则，使用斐波那契数列进行估计对我来说就像是 CargoCult 科学。