对于班级项目来说，最好的敏捷方法是什么？
该项目的定义不明确：我们要为 CS 111 计算机编程 I 的学生编写教育软件，重点关注功能。 我们有 6 名具有不同背景的学生开发人员在 Flex 工作。 该项目持续时间约为7周。 我们的会面时间非常有限（每周 30 分钟），工作时间也非常有限（每个开发人员每周少于 8 小时）。 我们接触客户的机会有限（我们课程的教授、CS 111 的教授、CS 111 的学生）。
我们的工具集包括 Flex Builder、Subversion 和 TRAC。
什么方法最适合这个项目？为什么？ 或者，应该从各种方法中收集哪些特征才能更好地适应这种情况？
The project is poorly defined: we are to write educational software for CS 111 Computer Programming I students focusing on functions. We have 6 student developers with various backgrounds working in Flex. The project has a duration of about 7 weeks. We have very limited face time (30 min per week) and very limited work time (<8 hours per developer per week). We have limited access to the customers (professor of our course, professor of CS 111, students in CS 111).
Our toolset includes Flex Builder, Subversion, and TRAC.
What methodology is best for this project and why? Alternately, what features should be gathered from various methodologies to better suit this situation?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是什么让您认为在这些情况下任何方法都会成功——沟通很少、要求多于时间、缺乏接触客户的机会？
话虽这么说，我会专注于增量交付（每次迭代应该有一些工作功能）、单元测试（所有测试在签入之前通过）、增量版本的标记（返回到工作版本的能力）和配对强团队成员与弱团队成员的结合，以提高团队的整体生产力。 考虑委派一名强大的团队成员来进行集成测试。
增量交付是最重要的。 展示一个低于要求的工作演示总是比展示一个无法工作的原型要好。
What makes you think any methodology would be successful under these circumstances -- little communication, more requirements than time, and lack of access to customers?
That being said, I would focus on incremental delivery (each iteration should have some few working features), unit testing (all tests pass before check in), tagging of incremental releases (the ability to go back to a working release), and pairing of strong team members with weaker team members to boost the overall productivity of the team. Consider devoting one strong member of the team to integration testing.
Incremental delivery is most important. Showing a working demo of less than what was asked for is always better than showing a non-working prototype.
您可以在这里使用敏捷方法，但显然您必须采用它来满足您的需求。
例如，如果您没有足够的机会接触真正的客户，那么最了解您的目标的人将不得不充当客户代理。 我还建议尝试更多地接触客户——几乎每个人都试图表现得比实际更忙，而且通常有一种方法可以解决这个障碍。
确保您的团队同时拥有的有限工作时间。 当你们不能一起工作时，就不可能有敏捷方法。
您绝对可以使用基于故事的估计、迭代开发过程等。
真正重要的是让每个团队成员对敏捷过程如何工作以及每个人在项目中的角色有一个清晰且明确的理解。 说你会使用 SCRUM 很容易，但不幸的是，如果没有真正的理解和经验，这并没有多大意义。
一些建议：
You could use Agile methodology here but obviously you'll have to adopt it to suit your needs.
For example if you don't have enough access to the real customers that someone with the best understanding of your goals will have to act as a customer proxy. I would also suggest trying to get more access to the customers - almost everyone try to appear more busy then they are and there is usually a way to resolve that obstacle.
Make sure that the limited work time your team have they have at the same time. There could be no Agile approach when you could not work together.
You could definitely use story-based estimations, iterative development process etc.
What is really important is too give every team member a clear and unambiguous understanding of how the Agile process works and what is each person's role in the project. It's very easy to say that you will use SCRUM but unfortunately without real understanding and experience that will not really mean much.
Some advice: