我一直在阅读敏捷开发的各种形式和方面，但都关注企业环境。我在我大学的一个学生项目团队中，我想看看一些敏捷概念是否可以在“每个人全部/兼职工作”之外的环境中工作。
我们拥有自己的项目服务器，Subversion用于版本控制，Sharepoint用于文档，wiki和操作项。
一些挑战
也许我们的团队不仅可以从敏捷技术中获益，因此欢迎所有建议。
编辑感谢所有出色的答案。我将开始向我的队友询问他们对这些想法的看法，看看他们买入了什么。我应该将它们链接到这个问题吗？您可以编辑答案或只留下评论以回答此次要问题。
答案 0 :(得分：4)
我不会尝试在您的团队中强制使用完整的企业环境风格敏捷编程工作流程，但我确实认为某种程度的敏捷方法可能很有价值。实际上，我认为某些敏捷思想会对你的某些“挑战”有所缓解，但需要团队中每个人的一定程度的承诺。
例如 - 每日站立/每周会议问题。
这不一定是一件大事（特别是在学生项目案例中，我会说它越小越好）。有一个Trac网站（如果你已经使用SVN，我建议使用SVN）和一个地方（比如一个wiki页面）只用一个句子跟踪站立信息仍然很有价值，不需要超过1-每天2分钟/人。
如果有人在这里和那里错过了一两天，这不是什么大问题，但如果团队同意这样做，它实际上可以帮助拖延问题（迫使人们只是说“我什么也没做。我是什么都不做“有一个好处 - 它让人们至少考虑你的项目，这往往会减少拖延的数量），以及让人们在不同的地方工作但仍然保持沟通。
对于非程序员来说，这也很容易，并且可以帮助保持机械和电气团队的协同工作，并且每个人都可以继续前进。
话虽这么说，但我一定要保持简短和甜蜜 - 尽量减轻负担，但我仍然认为，即使在学生环境中，一些敏捷编程思想也有价值。
答案 1 :(得分：2)
如果您问我，您的学生项目会增加太多开销。方法通常只在企业环境中使用，因为需要监控和控制人力资源（控制不是正确的词 - 但我需要一个比协调更强的一个）。在一群学生中，绝对没有必要为这样的事情烦恼。坚持一种方法只会让你失望。
您已经确定了自己的挑战。让你的同伴了解他们，并谈谈如何最好地处理他们。使用方法作为思想的来源，但在你的情况下不要弯曲。
答案 2 :(得分：1)
您可以每周或每两周进行一次模拟日常会议。通过以下三个问题开始您的会议：
请注意，非程序员队友也可以回答这些问题。在我工作的公司，我们有使用scrum（程序员和艺术家）的多学科团队，并且它运作良好。
如果你不想站起来，至少不要去舒适的沙发。这可以让人们更加专注，缩短会议时间。
你应该利用这种方法，通过制定临时里程碑来减少拖延。建立你的任务列表（excel，任何其他电子表格软件都可以）。将它们拆分为里程碑。什么时候来审查，和你的团队坐在一起，像客户一样看待你的产品，也许让你的老师参与进来。
扑克策划很有趣，也是一种很好的方式来澄清你必须做的事情，以及你计划如何做。将目标分解为任务将涉及所有学科的人员。但只有能够完成任务的人才应该对其进行评估。
答案 3 :(得分：0)
IMO，SharePoint和敏捷并不能很好地融合。选择更多“扔在那里”的东西。我会选择像 Trac 这样的东西，它有很好的Subversion集成。
听起来沟通和拖延将是你最大的挑战。如果你没有给自己足够的时间来完成工作并做好测试，那么你就不会有好的结果。这是合乎逻辑的，并且与您是否敏捷无关。
答案 4 :(得分：0)
在您的情况下，并非所有Principles behind the Agile Manifesto都易于应用您可以应用来自原则的一些想法，特别是：
在软件部分，您可以考虑TDD和pair programming
答案 5 :(得分：0)
我会说与SCRUM一起去。跳过每日会议，而是建立一个私人论坛，并要求每个成员每天至少检查一次。尝试让您的冲刺回顾和计划会议在饮料或咖啡上进行“面对面”活动。
一旦每个人都习惯了，SCRUM的整体做法（并且已经完成）是令人惊讶的。 “冲刺发布”概念还可以帮助团队成员长时间“变暗”并使项目保持现实（“两周内我们能做什么”与“我有这个想法，我将要开始，谁知道当我能完成它时“）。
此外，如果您的团队有超过8人，请跳过SCRUM =）
最后，如果你有自己的才能，团队中有人有手段（和愿望），请考虑TFS工作组（我认为它免费提供学术MSDN）。如果你的团队中没有真正想要承担这一负担的人，请跳过它。
答案 6 :(得分：0)
当我在大学时，我参加了几门鼓励采用和使用敏捷实践的课程。他们大多是一团糟，虽然我从他们那里学到了很多，但他们通常并不是教授期待我们学习的东西。我现在专业地进行敏捷开发并且喜欢它，但是当我在学校做敏捷时，我希望我知道这些事情：
按照你的日程表进行调整是非常非常困难的，这使得每日站立更重要，而不是更少。如果你不能坐在同一个房间（非常努力），那就使用Twitter或Yammer，或者只是发送电子邮件。
很多敏捷的好处只是让你进入节奏。这并不仅仅意味着每周会议;它意味着设定目标，对积分的承诺和每周可交付成果。这在学术背景下很难实现，但应该帮助你解决拖延问题。
习惯配对很难;每个人都有自己的计算机和发展方式。如果可能，尝试将第二个键盘/显示器/鼠标连接到现有笔记本电脑，或使用屏幕共享软件，并在IDE上实现标准化。配对也真的，真的有助于拖延，但试图在没有好工具的情况下做这件事是一件非常麻烦的事。
即使您认为它是一个愚蠢的，学术性的，一次性的项目，也不要吝啬单元测试。我之前已经完成了项目，我认为这些项目太小而无法进行测试，而且它永远不会再回来并且咬我屁股。
Sharepoint可能有点重量级。信不信由你，我们仍然在白板或索引卡上做了很多事情。您可能是您自己的客户，但这并不意味着您不能拥有故事（离散的，可估计的功能，基本上）和目标。能够可视化它是有帮助的：这些功能是有计划的，这些功能正在开发中，这些功能已准备好进行测试。如果你想要软件推荐我可以给你那些，但我建议在很多规划过程中使用简单的纸张。