Scrum如何适应学术环境？

我目前正在与我所在大学的一位教授合作，为我学院提供的软件工程和Capstone设计课程开发新课程。

直到最近，这两个课程都只使用瀑布模型，因此，学生们大部分时间都在写冗长的报告。在我施加很大压力之后，我的教授决定在上学期将Scrum纳入软件工程课程。

本学期的前半段仍然是瀑布式的，学生们撰写了40页的设计报告和软件规格文档。学期中，所有团队都必须发布其应用程序演示。那时，课程切换到Scrum，进行了两个为期3周的冲刺。现在，我们正在尝试找出如何完全消除瀑布并创建完全基于Scrum的课程。

不幸的是，我们在Scrum和学生之间遇到了一些不兼容性：

• 对于学生来说，每天召开Scrum会议几乎是不可能的。即使在上课期间，由于教授通常是在讲课，所以学生召开Scrum会议也不方便。
• 由于学生缺乏经验，因此无法准确地预测要花费多长时间，因此很难估计积分/小时。
• Scrum与全职，位于同一地点的开发人员最适合，但学生都不是。学生最多每周奉献15至20个小时的课程，组织工作会议可能非常困难。团队最多可以有10个学生（并且总是有一两个懒人）。
• 教授们渴望文档！我还没有听说过Scrum的任何报告，只有积压的工作量和燃尽图（我不确定这是否足以使学者安心）。
• 学生通常认为敏捷的意思是“立即跳入并开始编码而无需回头”。这导致了一些可以想象的最可怕的代码。因此，我正在寻找一种方法来执行适当的设计，而不需要50页的文档或一堆UML图。

鉴于这些问题，您如何看待我和我的教授如何使Scrum在学术环境中发挥作用（并且我们一开始甚至应该为Scrum烦恼）？此外，教导瀑布模型是否仍然有价值？

预先感谢您的任何反馈！

我会如此迅速地抛弃瀑布。

尽管对于实际构建软件系统而言，这是一个有缺陷的模型，但在生命周期的每个阶段提供良好实践指导的教学模型也不错。无论您应用于项目的过程模型如何，您仍将执行需求工程，系统架构和设计，实施，测试，发布和维护（包括重构和增强）。区别在于这些阶段的组织和执行方式，但是所有活动仍在进行。

我认为在项目中间从瀑布到Scrum的过渡不是最好的主意。Scrum成功的关键是一个长期运行的项目。前三到五个冲刺是团队以一定的速度适应，学习过程并进行团队发展。尽管您正在完成这些动作，但那时还不是真的Scrum。此外，尝试创建专门基于Scrum的课程可能不是一个好主意，因为Scrum并不是万灵丹–最好教最佳实践，而不是单一的方法。在员工队伍中，并非所有项目都将使用Scrum。实际上，在某些环境中，Scrum会对项目的成功有害。

您已经在学术环境中发现了Scrum的问题，其中有些很难适当解决。

在您的不兼容列表中，没有问题是估算很困难。是的。但是，要更好地进行估算的唯一方法就是估算并比较实际值与估算值。学生应及早使用各种方式（故事点，代码的源代码行，小时，页面，工时）来估计规模，时间和精力，以便他们在毕业和进入劳动力市场后有更多的准备。

既可以从教授的角度又可以从学生的角度解决文件需求。精益方法告诉我们，没有为团队或客户增加价值的文档是浪费的（在时间和成本方面）。但是，出于各种目的，需要一些文档来实现学生和教授（客户/客户）的某些目标。总体而言，这听起来像是一个机会来教授过程定制和定量项目管理（即使在敏捷方法中也有作用）。

关于Scrum会议和日程安排，我想到了两个想法。首先，这表明Scrum可能不是在学术环境中使用的最佳过程。对于软件项目，没有唯一的“最佳流程模型”，其中包括进度，人员配备，可见性和开发团队的经验（其中包括其他因素）。

总体而言，我建议您在单一方法上强调良好做法，流程定制和流程改进。这将使您对参加课程的每个人都最有效，并使他们了解各种过程方法，并了解在给定条件下的最佳实践。

由于您正在努力构建大学课程，因此，我将对我所在大学的软件工程课程如何融合在一起进行高层次的概述。

这是一个介绍性的软件工程，以瀑布模型进行了整个项目，每个阶段的讲座对应于进行该阶段活动的不同方式。团队以相同的速度完成了各个阶段。对于那些没有团队开发软件经验的人来说，拥有明确定义的边界非常适合教学模型。在整个课程中，参考了其他方法，包括各种敏捷方法（Scrum，XP），Rational Unified Process，螺旋模型-关于它们的优缺点。

在活动方面，有专门的课程来讨论需求工程，架构和设计（两门课程-一门课程侧重于使用面向对象方法的详细设计，一门课程侧重于系统体系结构），许多课程着眼于设计和实现各种系统类别（实时和嵌入式系统，企业系统，并发系统，分布式系统等）以及软件测试。

还有三门专门针对软件过程的课程。软件工程过程和项目管理，专注于针对多种方法来管理软件项目的最佳实践。第二个过程课程讲授测量，度量和过程改进（强调CMMI，六个Sigma和精益）。最后，有一门过程课程使用使用Scrum方法进行的项目来教授敏捷软件开发（讨论了Scrum，Extreme Programming，Crystal，DSDM）。

顶点项目是为赞助公司执行的一个为期四分之二的项目，完全由学生项目团队负责，在赞助商和教职顾问的指导下进行。在发起人规定的任何限制范围内，如何进行项目的各个方面都取决于学生。唯一的大学规定的截止日期是项目中期（10周）的临时演示，最后的最终演示，以及临近结束时的四方海报演示。其他一切都取决于赞助商和团队的同意。

当我攻读软件工程硕士学位时，有一门名为“软件过程”的课程涉及XP，Scrum和其他敏捷方法。从本质上讲，整个班级都成立了一个假设的软件公司，并被指示在课程运行期间开发一款相当复杂的软件。讲座内容涉及XP实践，独立会议等。

大多数学生都听说过这些技术，并且通常热衷于应用它们。当然，没有办法强迫团队实际进行迭代工作，等等。但这实际上是课程的重点：本身就成为举行许多短期会议，进行迭代工作，进行连续构建等的动机，因为您会很快发现这只是与一群人和少量时间来生产有价值的东西的最简单，最可靠的方法。

要记住的一件事：确保您与客户打成一片，并在中途更改一些关键要求。或“忘记”最初提到它们。

那时，课程切换到Scrum，进行了两个为期3周的冲刺。现在，我们正在尝试找出如何完全消除瀑布并创建完全基于Scrum的课程。

目的是为了促进开发，还是学习Scrum，或者-两者都是？我会考虑缩短冲刺速度以加快学习过程。

•学生几乎不可能举行每日Scrum会议。即使在上课期间，由于教授通常是在讲课，所以学生召开Scrum会议也不方便。

也许您可以在不太适合学生的情况下以不太严格的形式替换日常站立。另外，并非每个人都需要参加每个会议。

•估计点数/小时数很困难，因为学生没有经验，因此无法准确预测需要多长时间。

出于同样的原因，估计日历时间甚至更加困难：-)对于故事点，您无需估算花费的时间：您可以估算相对时间。持续时间是导出的。

•Scrum与全职，位于同一地点的开发人员最有效，但学生都不是。学生最多每周奉献15至20个小时的课程，组织工作会议可能非常困难。团队最多可以有10个学生（并且总是有一两个懒人）。

也许尝试与较小的团队？对于Scrum团队，最高级别为10。我认为您也可以在非全职的分布式团队中取得成功，但是这当然更困难！让它本身成为一个教训。

•教授渴望文档！我还没有听说过Scrum的任何报告，只有积压的工作量和燃尽图（我不确定这是否足以使学者安心）。

Scrum并没有规定需要哪种文档。事实上，甚至燃尽图也不是必需的。这并不意味着文件被禁止：团队应提供必要的文件，包括教授认为必要的报告。

•学生经常认为敏捷是指“跳进去，无需回头即可开始编码”。这导致了一些可以想象的最可怕的代码。因此，我正在寻找一种方法来执行适当的设计，而不需要50页的文档或一堆UML图。

不仅学生：-)大多数Scrum团队都使用XP实践，例如TDD（测试驱动开发）和重构：我建议您将其纳入课程中。

此外，教导瀑布模型是否仍然有价值？

是的，至少有两个原因：首先，不能确定您的学生在工作中会使用Scrum，其次，我想如果您有比较的地方，就会更容易理解敏捷开发的本质。

听起来有点像我曾经学过的主题。

一些想法：

• 您真的会举行全团队的Scrum会议吗？子团队会工作吗？
• 如果“不回头”意味着没有重构，那么评估重构的证据吗？
• 评估反思和记录-让学生维护自己活动的博客。（这实际上是对工作场所非常有用的技能-比大多数正式文档要重要得多）
• 如果估算不正确，则希望他们正在学习-他们可以跟踪估算和现实之间的差异，反思差异并证明他们学到了什么吗？
• 是否有不那么正式的方法记录适当的设计？
• Skype或Gchat或某些满足一些Scrum会议需求的东西是否足够？

我的建议是分离和隔离您要教的内容。如果这是一门软件设计或其他软件工程学科（算法或其他方面）的课程，请专注于此。如果涉及SCRUM成为障碍（正如您所暗示的），请不要理会它。

当我上大学时，我们如何做到这一点的目的是开设专门的敏捷方法课程。该课程包括一个将根据SCRUM或XP运行的开发项目。要交付的实际软件是微不足道的，因为课程的重点不是编程或设计而是过程。这里的理由与为什么您不应该将“硬核”软件开发学科与方法论学科混为一谈，因为一个学科往往会使另一个学科黯然失色，并且在该阶段，学生大多还不具备足够的技能或技能来处理这两个学科。

课程可交付成果包括冲刺计划报告，每周进度报告，回顾，燃尽报告，以及我们至少每周举行的两场会议，其中包括一次小组站立/小组会议，TA将在该会议上散发和聆听。

该课程还包括TDD（测试驱动开发），效果很好。

此外，教导瀑布模型是否仍然有价值？

无疑是的。许多公司在其项目中使用此模型的版本（PPS，RUP，PROPS等）。许多人（正确地，我认为）发现“纯” SCRUM比项目更适合于正在进行的维护。SCRUM（通常是Agile）要求在范围上具有一定的灵活性，并需要就此进行需求协商和交付的可能性。并非所有项目都是这样工作的，它们都是二进制的：在Y时间点交付X，其他所有都是失败的。

软件工程学课程的重点是讲授软件生命周期的基本阶段-分析，设计，实现，测试以及使用实际软件质量标准（而非常规作业质量代码）。

使用非瀑布式流程演示实践很有价值，但是，由于您认为SCRUM不合适的原因-学生每学期修很多门课程，许多课程在学习时也有实际工作，因此您不能拥有100 ％的敬业团队成员或举行日常会议。

考虑使用敏捷度较低的迭代过程，例如UP（RUP）。

为了显示与瀑布过程相比的价值，请在迭代之间更改要求。这将显示UP和瀑布之间的区别，并暗示使用敏捷过程的价值。

在此之后演示瀑布将是多余的，因为UP涵盖了瀑布的所有阶段。

由于学期相对较短，因此需要进行两次小迭代。

提供一个广泛的框架供学生使用，因为本课程的重点不应该是实施的深度，而是针对其他课程，而应重点强调编码标准和单元测试。

在课程中，讲座教授一些过程的理论，例如瀑布，UP，XP，SCRUM和看板（以及其他主题，例如写作要求，UML，测试等）。

对于完成上述课程的学生，可以考虑另选一个SCRUM讲习班作为选修课程，该课程在夏季学期需要全日制为期两周。

如果您有一个学期/学期的项目，并且班级分为6至10人的小组，则Scrum可以工作。然后，您可以将上课的最后10分钟专用于Scrum会议。