mirror of
https://github.com/LCTT/TranslateProject.git
synced 2024-12-23 21:20:42 +08:00
89 lines
8.8 KiB
Markdown
89 lines
8.8 KiB
Markdown
在大学培养学生们参与开源代码开发的十四个技巧
|
||
================================================================================
|
||
|
||
|
||
|
||
学术界是培养和塑造未来的开源开发者的最佳平台。研究中发现，我们偶尔会开源自己编写的软件。这样做有两个理由，一是为了推广自己编写的工具的使用，二是为了了解人们使用这些工具时会遇到哪些问题。在这样一个编写研究软件的背景下，我的任务就是为 Bradford 大学重新设计二年级的本科软件工程课程。
|
||
|
||
这是一个挑战，因为我所面对的 80 个学生是来自不同专业的，包括 IT、商务计算和软件工程，这些学生将要在一起上课。最有难度的是，需要和这些编程经验差距很大的学生一起编写代码。按照传统，该课程允许学生选择自己的小组，然后给他们布置构建一个加油站数据库系统的任务，最后提交报告作为评估的一部分。
|
||
|
||
而我决定重新设计课程，让学生了解现实中的软件团队是如何协作的过程。根据学生的专业和编程技能，我将他们分为五、六个人一组。这是为了确保每个小组的整体水平相当，避免小组之间的不等。
|
||
|
||
### 核心课程 ###
|
||
|
||
课程的形式改为讲座和实践课两项结合在一起。然而实践课作为指导过程，主要是老师监督各个小组的实践进度以及他们如何处理客户和产品之间的关系。而传统的教学方式由项目管理、软件测试、工程需求分析以及类似主题的讲座组成，再辅以实践和导师会议。这些会议可以很好的考核学生的水平以及检测出他们是否可以跟得上我们在讲座部分中的软件工程方法。本年的教学主题包括以下内容：
|
||
|
||
- 工程需求分析
|
||
- 如何与客户及其他团队成员互动
|
||
- 程序设计方法，如敏捷和极限编程方法
|
||
- 如何通过学习不同的软件工程方法进行短期的水平提高
|
||
- 小组会议及文档编写
|
||
- 项目管理及项目进展图表（甘特图）
|
||
- UML 图表及系统描述
|
||
- 使用 Git 来进行代码的版本控制
|
||
- 软件测试及 BUG 跟踪
|
||
- 使用开源库
|
||
- 开源代码许可及其选择
|
||
- 软件交付
|
||
|
||
在这些讲座之后，会有一些来自世界各地的嘉宾为我们说说他们在软件交付过程中的经验。我们也设法请来大学里知识产权律师谈关于软件在英国的知识产权问题，以及如何处理软件的知识产权问题。
|
||
|
||
### 协作工具 ###
|
||
|
||
为了让上述教学内容的顺利进行，我们将会引入一些工具，并训练学生在他们的项目中使用这些工具。如下：
|
||
|
||
- Google Drive：团队与导师之间进行共享的工具，暂时存储用于描述项目的文档和图表、需求收集、会议纪要以及项目时间跟踪等信息。采取这样一个方式来监控并提供直接反馈到每个团队，是非常有效的。
|
||
- [Basecamp][1]：同样是用于分享文档，在随后的课程中，我们可能会考虑用它取代 Google Drive。
|
||
- BUG 报告工具，如 [Mantis][2]：只能让有限的用户免费提交 BUG。稍后我们提到的 Git 可以让小组内的所有人员用做 BUG 提交。
|
||
- 远程视频会议工具：在人员不在校内，甚至去了其他城市的情况下使用。学生们可以定期通过 Skype 来交流并记录会议内容或则进行录音作为今后其他用处。
|
||
- 同时，学生们的项目中还会用到大量的开源工具包。他们可以根据自己小组的项目需求来选择自己使用的工具包和编程语言。唯一的条件是，这些项目必须开源，最后成果可以安装到大学里的实验室，并且大多的研究人员都非常支持这个条件。
|
||
- 最后，所有团队必须向客户交付他们的项目，包括完整的可以工作的软件版本、文档和他们自己选择的开放源码许可。大多数的团队选择了 GPLv3 许可证。
|
||
|
||
### 技巧和经验教训 ###
|
||
|
||
在最后，这一年过的很愉快，并且所有学生的项目都做的非常棒。这里有一些我学到的经验教训，可能有助于提高明年的课程质量：
|
||
|
||
1. 提供各种各样有趣的选择项目给学生选择。比如说，游戏开发或者移动应用开发以及完成各种目标的项目等。建立普通的数据库系统已经不能提起学生的兴趣了，而参与到有趣的项目中去，学生本身就是自学者，同时可以帮助解决小组成员和小组之间的常见问题。再通过一个消息列表，学生们发表他们在测试中遇到的任何问题，以寻求其他人的帮助建议。然而，这种方法有一个缺点。外部考官建议我们使用统一种类型的项目和统一的编程语言以帮助缩小对学生的评估标准。
|
||
|
||
2. 定期给学生在每一个阶段的表现进行反馈。比方说，可以在和各个小组开指导会议的时候，或者每个阶段进行反馈，以帮助他们在接下来的工作中自我改进。
|
||
|
||
3. 学生更加愿意与校外的客户一起协作。他们期待着与外部公司代表或校外人员协作，不过是为了获得新体验而已。与导师进行交流时，他们都能够表现得很专业，这样使得老师非常放心。
|
||
|
||
4. 很多团队版将开发单元测试的部分放到项目结束之后，从极限编程方法的角度来说，这是一个严重的禁忌。也许测试应包括在不同阶段的评估中，来提醒他们需要并行开展软件开发和单元测试。
|
||
|
||
5. 在这个班的 80 个人里边，仅有 4 个女生，每个女生都分在不同的小组里边。我观察到，男生们总是充分准备好来承担起领队角色，并将最有趣的代码部分留给他们自己来编写，女生则多大遵循安排或者是编写文档。出于某种原因，女生选择不出头，即使在女性辅导员鼓励下，她们也不愿编写代码。这仍然是一个需要解决的主要问题。
|
||
|
||
6. 允许不同风格项目文档，比方说，UML 图表、状态图或其他形式的。让学生学习这些并与其他课程融汇贯通来提高他们的学习经验。
|
||
|
||
7. 学生里边，有些是很好的开发人员，有些做商务计算的则没有多少编程经验。我们要鼓励团队共同努力，避免开发人员做得比那些只做会议记录或文档的其他成员更好的错误认知。我们常在辅导课程中鼓励角色转换，让每个人都有机会学习如何编程。
|
||
|
||
8. 小组与导师每周见面沟通是非常重要的，可以有效监督各个小组进展情况，还可以了解是谁做了大部分工作。通常，没来参加会议的小组成员基本就是没有参与到他们的团队工作中去的，并且通过其他成员所提交的工作报告也可以确定哪些人不活跃。
|
||
|
||
9. 我们鼓励学生们把许可证附加到项目中去，使用外部库以及和客户协作的时候要表明确切知识产权问题。 这样可让打破陈规，开拓思维，并了解真实的软件交付问题。
|
||
|
||
10. 给学生们自己选择所用技术的空间。
|
||
|
||
11. 助教是关键。同时管理 80 个学生显然很有难度，特别是需要对他们进行评估的那几周。明年我一定会找个助教来帮我一起管理各个小组。
|
||
|
||
12. 实验室的技术支持是非常重要的。大学里的技术支持人员对于本课程是非常赞同的。他们正在考虑明年将虚拟机分配给每个团队，这样没个团队可以根据需要自行在虚拟机中安装任何软件。
|
||
|
||
13. 团队合作，相互帮助。大多数团队自然而然的支持其他团队成员，同时指导员在中间也帮助了不少。
|
||
|
||
14. 来自其他同事的帮助会锦上添花。作为一名新的大学导师，我需要从经验中学习，如果我想了解如何管理某些学生和团队，或者对如何让学生适应课程感到困惑时，我会通过多个方面来寻求建议。来自资深同事的支持对我来说是一种极大的鼓励。
|
||
|
||
最后，对于作为导师的我以及所有的学生来说，这都是个有趣的课程。在学习目标和传统评分方案上还有有一些问题需解决，以减少教师的工作量。明年，我计划会保留这种教学模式，并希望能够提出更好的评分方案以及引入更多的软件来帮助监督项目和控制代码版本。
|
||
|
||
--------------------------------------------------------------------------------
|
||
|
||
via: http://opensource.com/education/15/9/teaching-open-source-development-undergraduates
|
||
|
||
作者：[Mariam Kiran][a]
|
||
译者：[GHLandy](https://github.com/GHLandy)
|
||
校对：[Caroline](https://github.com/carolinewuyan)
|
||
|
||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||
|
||
[a]:http://opensource.com/users/mariamkiran
|
||
[1]:https://basecamp.com/
|
||
[2]:https://www.mantisbt.org/
|