2

该项目定义不明确：我们将为 CS 111 计算机编程 I 学生编写专注于功能的教育软件。我们有 6 名具有不同背景的学生开发人员在 Flex 工作。该项目的持续时间约为 7 周。我们的面谈时间非常有限（每周 30 分钟）和工作时间非常有限（每位开发人员每周少于 8 小时）。我们对客户（我们课程的教授、CS 111 教授、CS 111 学生）的访问权限有限。

我们的工具集包括 Flex Builder、Subversion 和 TRAC。

什么方法最适合这个项目，为什么？或者，应该从各种方法中收集哪些特征来更好地适应这种情况？

4

2 回答 2

6

是什么让您认为在这种情况下任何方法都会成功——沟通少、要求多于时间以及无法接触客户？

话虽如此，我将专注于增量交付（每个迭代应该有一些工作功能）、单元测试（所有测试在签入之前通过）、增量发布的标记（返回工作版本的能力）和配对强大的团队成员与较弱的团队成员，以提高团队的整体生产力。考虑将团队中的一名强大成员投入到集成测试中。

增量交付是最重要的。展示一个低于要求的工作演示总是比展示一个不工作的原型更好。

于 2008-10-14T16:28:49.703 回答
2

您可以在这里使用敏捷方法，但显然您必须采用它来满足您的需求。

例如，如果您没有足够的机会接触到真正的客户，那么最了解您的目标的人将不得不充当客户代理。我还建议尝试更多地接触客户——几乎每个人都试图表现得比实际更忙，而且通常有办法解决这个障碍。

确保您的团队同时拥有有限的工作时间。当你不能一起工作时，就没有敏捷方法。

您绝对可以使用基于故事的估计、迭代开发过程等。

真正重要的是让每个团队成员清楚而明确地了解敏捷过程是如何工作的，以及每个人在项目中的角色。说你会使用 SCRUM 很容易，但不幸的是没有真正的理解和经验，这并没有多大意义。

一些忠告：

  1. 教育你的团队成员
  2. 如果您不受时间/资源的限制，请列出您想要交付的内容。
  3. 找出在您的限制条件下可以实现的交付。那可能不会太多。不要试图过于乐观。专注于你真正可以实现的目标。
  4. 确保您的真正客户同意这一点。
  5. 使用短迭代（1 周或更短）。确保您可以在每次迭代结束时交付经过全面测试的产品。
  6. 尽早展示你的作品。
于 2008-10-14T16:51:31.717 回答