本文来自于 Rational Edge: 迭代开发技术最好是在逼真的环境下学习,但是如果组织得合理的话,学校开设的课程也可以近似的模拟出业务环境。Gary
Pollice描述了他所讲授的介绍性课程是如何像一个为期七个星期的软件开发项目一样运转的。在我二月份的专栏里,我曾经批评过一些不切实际的教授软件开发的方法,它们通常披着软件工程学课程的伪装。我介绍了我的方法,并且自认为能够为软件开发提供更加实际的介绍。这个月,我将向您介绍课程的细节。我相信类似这样的课程在许多情形下都会很有效,而不仅仅适用于传统的学院的设置。
何谓成功?
在讲课时,关键是要清楚通过这门课程你期望取得什么样的成果。Worcester工业学院计算机科学系的教学目标和成果都已列在学校的网页上。1
这些目标描述了我们所期望的毕业生的类型。 而这些成果则是对那些我们希望学生们掌握的各种专业技能的描述。并不是所有的成果都会应用到软件工程学中,但是它们确实是一个必要的起点。
对于我所教授的软件工程学课程,我在课程网页 2 上明确的列出了目标并详细的描述了预期成果。对于大多数近期的课程,我制定的学习目标是:
1.熟练掌握软件开发和生产的方法和步骤,其中代码和用户说明文档尤为重要。
2.获得那些能够帮助你作为软件开发团队中的一员高效率工作的技能。
3.提高口头表达能力和写作技巧。
4.认识到软件工程的基本原则。能够识别和描述软件生命周期、角色、工件以及活动。理解软件“最优方法”的概念,以及它们何时适用。
5.展示你根据需要改编程序的能力和选择适当的最有方法集知道你完成软件开发项目的能力。
我也详细列出了一些技能,我希望我的学生们能够随着课程的进行逐步掌握它们。
出发点
我心里清楚七个星期后我所要达到的效果。3 我最关心的就是把同学们聚集在一起,并且使他们知道从哪里开始。
这可能听起来是显然的,学习开发软件的最好方法就是亲自开发软件——这也正是许多学生没有真正做过的事情。他们以前只是在课堂上编写各种各样的程序,但是却从来没有参与过真实的软件开发项目。我认为除了一些Java和/或C++的编程技巧以外,他们几乎没有实际的开发经验。当然,有一些例外。有些学生拥有在假期或者课余时间兼职的经验。但即便是这样的同学,他们同样很欠缺有关管理需求、撰写文档和改写程序的经验。
我的直觉是在一开始就给学生们布置一个项目,此时他们没有多少方法可以遵循。但是由于知识和概念是有时间上的先后顺序的,于是由此引出了一个大问题;例如,基本概念是其他概念的基础。与之形成对照,一个运用迭代方法过程的真实的项目,要求开发团队尽早并且经常的完成大部分活动。尽管如此,你还是需要从某处入手,并且根据我的直觉,我将项目作为这门课程的主线,为同学们提供足够的信息使他们能够将项目启动起来,然后再逐步弥补知识上的不足。
这种方法的缺点是某些特定的技术,比如文本分析和识别主域类,学生们在学习这些知识之前就要在项目中用到它们。但是我相信,这个缺点同学生们所获得的经验相比就微不足道了,并且这一点被我所收到的反馈和实际取得的效果所证实。
进行商业项目的开发还是学校项目的开发是个永恒的话题。在学院的环境下,并没有一个严格的截止期限。4 在Worcester工业学院,我们拥有一个独特的条件。我们的本科生学期横跨七个星期,每一位学生通常在一个学期选修三门课程。在这七个星期里,我们给学生们准备的学习材料相当于一个为期14周的学期的工作量。大多数本科生课程,比如软件工程学,一周有四节课,每节课50分钟。
学生们需要花费课下的时间来准备工作。同样,他们需要找到一个工作场所。在校园里有若干个计算机实验室,而且校园无线局域网几乎可以覆盖每一栋建筑楼和宿舍楼。学生们经常会在他们自己的房间内工作,团队成员之间通过电子通讯手段彼此联系。他们认识到在软件工程中这些是不够的,还必须找到一种定期面对面沟通的渠道。
第一周
我使我的学生们在第一周期间陷入到一种半控制状态的混乱之中。
第一堂课:总体介绍课程内容,介绍软件工程学和软件开发的相关知识,并且谈论一下团队。这堂课布置的作业是组建团队并且选定学校的SourceForge系统的一部分作为本团队的项目。每个团队大约15名同学。我所教授的这个班级共有学生43人,每个团队的人数应在12至17人之间。我试着确保每支团队中至少有10名成员。对于学生们来说,这应该是一个(心理上的)极限值。他们会感觉10人以下的团队就是小团队,但是10人或者10人以上的团队就是大团队了。
第二堂课:描述项目,解释可用到的工具,并且讨论一些实用的方法,比如配对编程和迭代开发。我要求学生们两人一组,开发一个小程序,并且必须在第四堂课之间上交这次作业。他们必须提供一份报告,描述他们的经历并且评价这次两人组的编成练习。比起实际的程序,我更看重这份报告。这份任务也让学生们习惯了用一种这门课程所接受的方式撰写程序文档。如果他们不为程序撰写文档,确确实实对他们没有好处。拙劣的文档、命名、代码格式以及其他源代码方面的问题将影响他们的成绩。
第三堂课:今年的第二个学期始于一个星期二,所以第三堂课是在周五进行,5 周五是所谓的“项目讨论会”日——这一天开发团队向他们的客户和其他利益相关者展示其工作成果。我们利用第一次项目讨论会的机会安排各个团队和客户见面,并且为他们指派一位“指导老师”。我稍后还会谈到这一点。我期望学生们利用这次机会向客户询问他们所要建造的系统的相关信息,并且对于项目的规模和不同的利益相关者的需要有一个初步的认识。这时,他们开始认识到这门课并不同于他们以往所经历过的那种基于说教的课程。
第四堂课:现在,学生们已经对这个项目有了一些认识,他们通常会对此感到一点紧张。他们确实不知道从哪里入手。需求此时最多算是模模糊糊。我会给予他们很少的提示,但并不是说些类似“你们的工作就是让客户满意”和“你们如果想完成这个项目的话就要像一支团队那样好好工作”这样的话。
现在,我开始介绍一些能够帮助这些团队从混乱中走向清晰的技术。首先,我们来看一看项目、利益相关者,以及指导老师。
项目
每支团队所承担的项目各不相同。在上个学期,四个项目分别是:自动化停车库、锻炼日志,内核管理系统和参考资料管理系统。我在每堂课之前都花费大量的时间开发体系结构,并且实现最小限度的应用。
今年,我采用另一种方法,为什么呢?因为在第一个学期中,我曾经教授过面向对象分析与设计(OOAD)课程,这门课是同学们可以选修的第二门软件工程学的课程。大多数同学已经学习过这门介绍性的课程。我让选修过OOAD的学生设计体系结构,并且实现一个可以供介绍性课堂使用的可执行的结构。他们于是设计了一个可以控制未来电子住宅的软件系统(EHOF)。这是我从软件工程学学会的一份报告中得到的想法。
这一体系结构要支持照明、器具、娱乐和安全等子系统。考虑到他们的工作可能会作为下一学期软件工程课学生的基础,所以这些设计体系结构的同学必须提供代码、文档以及用户手册。结构团队由三到四名同学组成。
我从选修过OOAD的同学所提供的10份执行方案中选择了一份,并且将它用作介绍性软件工程学课程可利用原始代码的基础。他们的项目就是要根据用户的需求实现照明子系统。
利益相关者
在我所有的软件工程学课堂上,都有一份神秘的议程。我想要确保我的学生们认识到,他们不能随心所欲地构建他们想要的任何系统,而只因为它很“酷”。软件必须要能解决问题,并且在大多数情况下,正是使用系统的人来决定哪些功能是重要的。为了逼真的营造这种氛围,我们的这个项目由某家客户机构“出资发起”。我通过运用不同的人物将这家客户机构介绍到课程中来。每个人物扮演机构中的一个角色,这些角色由我,或者某一位助教,以及一名特约人员分别饰演。
在OOAD课程和软件工程学课程的项目中,都涉及到三个客户人物。第一位是Russell T. Customer,公司的主席,是他“雇佣”了我们的学生团队。他对产品的要求是符合公司总体的业务策略,他还对该系统提出了一个远景概述,7
每周五他还是公司项目进度检查组的一员。Russell是一位投资者 ,他将自己的财产投资到这个项目上来。
第二位人物是和Russell一起共事过若干项目的公司的首席技术官Gonzo N. Propellerhead。Gonzo在内心里是一位技术狂人。他一向喜欢涉足其中,并且他知道许多对于开发团队来说可以利用的技术。他喜欢酷的边缘技术,并且更热心于帮助团队。Gonzo最大的问题就是:他能够引导团队尝试许多有意思的想法,但是却没有一种可以帮助他们生产出符合Russell要求的产品。8
第三位人物是客户的利益相关者Marty M. Weasel,他是产品销售部门的负责人。市场营销行业的读者会对这个名字感到不舒服,我之所以这样用是为了增加幽默的元素,并且传递一个信息。技术人员们在公司里这样谈论营销人员是很普通的事情。如果你还是不相信我的话,就请看一看Dilbert(美国
Scott Adams 的有名职场卡通人物)的漫画。但是我希望我的学生们认识到,如果他们想要获得成功,他们就必须同营销人员密切合作。Marty是客户利益相关者,他同客户的联系最为密切。
我作为教师,是第四个主要的利益相关者。我在项目中拥有股份,他们必须将我的需求考虑在内,并且需要平衡不同利益相关者之间的关系。在第一堂课上贴出了一份利益相关者页面,学生们可以通过它认识他们并且获得联系他们的渠道。9
最后一组利益相关者包括指导老师和团队成员。指导老师嘛,是我的助教们,他们的主要工作就是给学生的作业打分,以及指导一支团队。如果没有足够的助教(TA),我就亲自指导一支团队。指导老师在每周五出现,讨论团队的进展情况,并且为下一周的工作提出建议。
他们也可以帮助团队走出前进道路上不可避免的困境。我很幸运的得到了几位出色的助教,他们对他们所带领的团队很负责任。
那团队的成员们呢?他们是经常被遗忘的利益相关者。但你承担一项团队分配的任务时,要记住你的队员们依靠着你并且希望你取得成功——至少,这是一个健康的团队所应当具备的气氛。事实上,我清楚地告诉我的学生们,他们在该项目中的大部分评分都是基于团队成绩的。如果某位团队成员没有完成任务,将会影响到整个团队,所以每个人都应当主动帮助其他队员取得成功。这并不代表每位队员都要或者应当完成相同的任务量。每支团队应当根据不同成员的能力大小合理安排工作,从而取得最好的效果。
交流,交流,再交流
真正的工作始于第四堂课。我对于我的学生们如此快速的组成团队感到非常欣慰。团队成员必须要学会彼此之间如何进行交流。但是随后他们必须同利益相关者进行沟通。通常,一部分团队成员在组织团队会议时体现出主动性,并且将各种事情运转起来。一味或更多的成员随后担负起同客户利益相关者沟通的任务,他们负责搞清楚客户真正需要的东西是什么。
由于同学们的课表都排满了,所以他们在确定团队会议时间时遇到了麻烦;他们几乎没有时间同客户(即我)在一个彼此共有的开放时间内进行面对面的交流。我提出若干方案来使得这种联系变得更加容易。同学们可以在预定的工作时间来办公室见我,至于其他时间,只要我在办公室而且不太忙的话也是可以的。他们也可以发送电子邮件或者使用即时消息。在每周五的课堂以外,大多数同客户的联系都是通过即时消息进行的。作为不同的利益相关者,我需要处理不同类型的电子邮件和即时消息。
在本学期我们的第四堂课结束后的那个晚上,确切的说是在晚上8:30,我家里的即时消息对话框弹出一个窗口,是一位学生发给我的消息。她联系的对象是Marty,市场营销的利益相关者,她想得到一些用户信息以便开始工作。我们聊了大约一个小时。在这期间,他问了一些关于我作为教授,而不是Marty这一角色的问题。作为Marty,我不知道她在说些什么,并且提醒她我是Marty。她随后只得将消息发送到我的账号,并同我谈论起那些真正关于我,一个教授的问题。这项练习除了使我增强了扮演不同角色的能力以外,对学生们大有好处。因为他们开始思考他们正在和谁交谈,以及如何进行交谈。
我扮演Marty时,同学生们进行的一次讨论的片断如下:
……
学生:同样,现在我们询问你的想法对我们来说很有益处。我会把我们的想法带回到我的团队来讨论它们的可行性。
MartyMWeasel:好的。有时候我们也应当为了迭代的需要对用户的要求进行优先权的排序。
学生:会的
学生:首先,在上次会议期间所提出的假期布景问题,用房屋中灯光的打开与关闭来模拟有人在家里和在房屋附近走动的情形。
Marty:好的。你需要使用者关于这个问题的说明?
学生:我认为这是关于最重要的部分的使用者说明
学生:而且不是一个形式上或者技术上的问题
Marty:好吧,这是一个非常高水平的问题。它可以变成若干个使用者说明,比如:……
Marty:用户描述之一:用户应当可以编排任意一个照明设备来展示半随机的行为。也就是说,灯光可以根据某些约束条件在不同的时间间隔内打开或者关闭,比如“从下午7:00到晚上11:00,每个小时打开时间为15分钟”
学生:好的
Marty:用户描述之二:另一种约束或者指定灯光如何开启和关闭的策略就是为用户制作一个描述开-关模式的“剧本”。
学生:好的
学生:很好
Marty:用户描述之三:这个系统应当提供一个脚本库以供用户从中选择灯光的工作方式。
Marty:用户描述之四:用户能够将脚本存入库中以供将来的重新使用或者进一步编辑修改。
Marty:用户描述之五:用户应当能够创建一份拷贝以便于将来进行修正。
Marty:Pollice教授说:“想一想如何将这些描述中的每一项变成能够指派给一两个人实现的详细而具体的任务?”
学生:好的
学生:比我想象中的宽泛程度要小得多
Marty:不,这些描述需要被详细而明确的传达给开发人员,从而有效地实现计划、测试、实现等等。
学生:我明白了
学生:我认为假期使用者的说明听起来不错,除非你有其他什么完全不同的描述?
Marty:我们为系统架构团队提供的用户描述要具有必要的宽泛程度,因为他们并不需要实现那些细节。
学生:有道理
Marty:这是一个好的开始。我确信随着时间的推移我们将不断进行补充,而且我们会看到你们团队的成果。
……
一旦把话说出来,学生们就能够真正地同利益相关者们建立起联系,只要我在电脑前,这种联系就随时都可以发生。他们开始有规律的带着问题出现在我的屏幕上,他们需要问题的答案从而取得进展。我经常发现自己同时在和两到三支团队进行交流。一些团队在他们开会的时候连线我,于是我可以马上回答他们所提出的问题。
有些人会认为这种方法对于我这一方来说太占用时间了。实际上,它每周仅仅占据我一两个小时的时间。在那段时间里,我还经常完成一些其他的工作,比如当学生们整理他们的消息的时候,我可以准备课堂笔记或者撰写论文。我相信这些时间是我所能够给予同学们的最佳时间之一。
进行迭代的重要性
现在团队已经组建完成并且开始运转起来。他们面临的下一个考验就是将事情整合在一起以便迎接客户们每周五的迭代回顾。在课程期间,我将若干顶帽子和Marty的假发带进课堂,10
通过这些道具区分不同的人物。各个团队在上课伊始就开始提出问题。他们通常要求得到需求的确认和澄清。
在提问结束后,Marty和Russell来到每一支团队来看一看一周以来他们的工作完成情况。他们会对那些为下一阶段迭代工作提供适当的输入的团队提出表扬。在整个学期期间,通常是在前几次迭代回顾的时候,Russell至少会澄清和纠正一次团队的开发方向。
在今年的第一次迭代回顾时,两支团队看起来已经取得了显著的进展。但是,他们的进展同用户提出的需求并没有多大的关系。Marty指出了这一点,Russell也质问他们是否还想从这份工作中得到报酬。这一信息清晰而强烈的传达了出来。在那之后,这两支团队就始终确保他们按照Marty或者Russell批准的计划开展工作。
一支团队采用一种有趣的方式取得进展——通过迭代开发期间所完成的用户描述的数目来加以衡量。该团队做了很多工作,但是却没有完成一项计划的描述。因此,他们没有取得任何进展,这明显的伤害了该团队的集体自豪感。这一经历促使他们重组队伍并寻找新的工作方法。在那次迭代开发之后,他们在每一周都能够取得明显的进展。
附加主题
一旦各个团队开始了项目的开发工作,我就可以介绍更多的传统的学习资料。正如我前面所提到的,由于这些资料具有介绍时间上的先后顺序,所以同学们经常会在他们第一次需要他们之后才能得到这些信息。但是,他们可以将这些素材应用到下一次迭代开发过程中。
在开发项目的过程中,下面这五个主题看起来最具有价值:
运用优先权计划编制策略。他们学会通过所完成的用户描述的数量来衡量他们的工作成果,并且根据这一数据来预知下一迭代开发阶段所能完成的工作。这是一种简单而且非常有效的方法。我们使用电子数据表来保持对需求的跟踪。每一周团队成员将表格放送给Marty并且告诉他有多少单元他可以选择。Marty将很快回复这一信息,然后团队成员明确了在即将到来的迭代开发周期中前进的目标。
需求优先级排序。同学们很快就认识到客户所应担负的职责。他们也学会了如何同客户进行交谈,并且使者去“推销”自己关于项目的好的想法。有时他们会取得成功,有时则不会;但是他们不会在没有得到用户批准、排定优先级并由顾客增加到迭代中的情况下,在项目中添加任何内容。
测试。所有学生都参与单元测试,但并不是所有人都养成了记录任何测试情况的习惯。有些人非常好的适应了测试驱动的开发方式。我并不要求同学们采用“测试第一”的方法,但是我要求他们进行测试。那些采用测试第一方法的同学将会进行更多更好的测试。每支团队都安排一部分成员负责系统测试。但是,测试团队中的人员真正涉及到客户。这就是在今后的课程安排上我所要进一步完善的地方。
设计模式。这并不是一门介绍性质的软件工程学课程所要关注的主要课题,但是我所介绍的那几种模式相当有价值。同学们几乎都想马上将它们应用到自己的项目开发中。
源代码管理。我很惊讶于有那么多的学生在进入第二年或者第三年的计算机科学编程学习时仍然对于代码管理(SCM)知之甚少。我们至少花费了一堂课的时间来讨论如何使用SourceForge所带的CVS软件的基本功能。我们也会探讨分支和合并。
结果
课程的效果可以通过完成的项目,学生的反馈和评估,以及学生在其他课堂上和毕业以后在工作中的表现体现出来。学生们感觉到不同角色的运用非常的有效。他们发现通过七个星期的学习,自己所具备的从起初的混乱到后来能够从事产品生产的这种能力取得了长足的进步。大部分同学发自内心的喜欢两人组的编程模式,他们说如果可能的话,他们今后会继续使用这种方法。
我所收到的抱怨主要有两条。第一种抱怨,他们更喜欢小型一些的团队。我们中的大多数人不是这么想的么?但是问题的关键是要具备大型的但并非是臃肿的团队规模。他们打算在毕业之后进入这种结构类型的团队。
第二种抱怨:学生们更喜欢从事白手起家的项目。再则,大多数软件已经作为现有系统的延伸而存在了。我们中的大多数人确实难得获得几次在“绿色领域”中从事开发工作的机会。因此我们需要懂得如何处理那些依赖其他人工作的项目,特别是所依赖的那些人无法接触到的情形。
介绍性质的软件工程学课程是我最感兴趣的课程之一。对我或者我的学生们来说,它并没有带来很大的智力方面的挑战。但是我们却都可以从中学到一些有用的东西,并且通过我们的努力可以看到切实的效果。图1和图2来自一支团队的最终的项目成果。
图 1:eHOF的控制台
图 2:平面图的细节
注意到平面图中显示的左侧的一盏灯处于开启状态,而右侧的一盏灯处于关闭状态。在下部还有一道被锁上的门。如果你不喜欢图形的描述方式,你也可以将数据视为表格。这正是模型-视图-控制器(Model-View-Controller)设计模式的一个经典的例子。
eHOF系统的使用者可以通过连接到服务器的一个简单的控制台来控制所有的设备。我总是惊叹于学生们在七周的时间内所完成的工作量之大,产品的质量之好。我希望你们能够认可他们在课堂上所获得的经验,并且在他们毕业之后能够给予他们一些帮助。
我们下个月再见,“我会为你一直打开这盏灯。”
注
1 请参见 http://www.wpi.edu/Pubs/Catalogs/Ugrad/Current/csdept.html
2 请参见 http://web.cs.wpi.edu/~gpollice/cs3733-b05/index.html
3 我在以前的文章中提到过,Worcester工业学院的本科生有四个学期,每个学期为期七周。在每个学期中,一个学生通常选修三门课程,一周的学习时间为四个小时。在每个学期的第七周时,学生们会收到一些学习材料,这些材料大约相当于10-14个星期(每周两个或者三个小时)时间的工作量。
4 当然,我们也可以根据完成的进度情况作出评价,并让学生们以后再完成,但是我在自己的软件工程课上从来没有这样做过。
5 大多数本科生班级每个工作日(除周三外)都会会面。每周三是为实验室和特殊会议保留的日子。
6 可在 http://www.sei.cmu.edu/publications/documents/00.reports/00sr009.html
上找到此份报告。
7 可在 http://web.cs.wpi.edu/~gpollice/cs3733-b05/Project.html 上找到此份富有预见性的声明。
8 我是从Wang毕业生研究协会的William McKeeman博士那里得到的这种类型的利益相关者的想法。他有一个类似的角色——一位被称作
“Sweet Willie”的技术顾问。
9 利益相关者的网页是 http://web.cs.wpi.edu/~gpollice/cs3733-b05/Project/Stakeholders.html
10 对于Marty,我觉得我需要一顶新帽子。因为我头顶上的头发已经没有了,而假发总是引出笑话。
参考资料
您可以参阅本文在 developerWorks 全球站点上的 英文原文。 |