首页 > 软件 > 软件工程经验报告的体会
2016
04-15

软件工程经验报告的体会

  英文原文:Writing Reports In Software Engineering

  原文作者(author):Isaac J (Sheepzez)(@sheepzez


  本周,我一直在写一份经验报告注1,涉及我参与的长达 6 个月的大学团队项目。对于反思软件工程过往经验的难度,我想分享一些观点。

  在过去的两周,我一直和团队致力于输出一份关于大学团队项目的经验报告,大约 20 页。这份报告涵盖了长达 7 个月的开发时间,包括规划会议。

  讲师们正在寻找一份文档,它最好能反映出我们项目开发中遇到的具体主题。举个例子,我们是否发现过,在某次迭代中不得不放弃某个功能,以及讨论它不得不被放弃的原因。我们曾给自己太多工作量吗?某个功能的难度超乎预期吗?它是不必要的?

  我觉得,用如此详细的方式反思我们的软件实践,将是非常艰难的任务。整个学年里,我都知道这份报告一定要提供,不过,面对 6 个月的开发时间,只用 20 页的报告讨论,相对要容易些。很明显,可能是这样子的,否则科目督导(course coordinator)就不会这样要求了。

  存在一些困难,因为缺乏记录整个项目期间发生事情的文档。我们大概每月举行一次回顾会议,但是每次回顾所记录的问题(和改进)都不够详细,因为这些问题毕竟都是我们亲身经历的——然而,6 个月后,细节变得模糊起来。如果有人在开发过程结束后需要写报告,那么我一定建议他写文档、写文档、写文档。写下发生的所有事情,不管好坏,只要它发生了。

  去年夏天实习期间,我们召开回顾会议,原定 1 小时——实际上,很少能超过 15 分钟。我还不敢十分肯定,为什么开发人员(据我经历看)不喜欢回顾碰到的错误或问题——貌似成了责任问题。回顾会议的初衷是好的:我们需要反思最初的错误、找到根源,防止未来再次发生。那么,为什么各种经验水平(从高级到实习生)的开发人员都乐于跳过表面讨论的反思呢?

  或许,这算作需要直面的下一个挑战吧,我这样说,既是因为我自己,也是因为其它开发人员,把回顾会议看成一项不幸的任务。我们急于跳到下一个冲刺(sprint)。我们不愿意在每天站立会议上讨论已经解决的问题,可能只是在某种程度上提一提就过去了。

  或许,是为了首先避免承认犯下的错误。我们跨过这些障碍,即,当赛跑开始时,就不要在意我们绊倒的事实了。

  我敢肯定,在这方面更有经验的某个人,将能就回顾会议、以及如何召开,提供更为深刻的见解,但是我可能要回去继续写我的报告了……


  译文: 《软件工程经验报告的体会 》 腊八粥

  注释

  1. 经验报告(experience report):由真实组织中已完工(或即将完工)的参与者所编写的一种报告。工作应该具有实际目标,比如:对已有问题的甄别和分析、寻找解决方案、或真正地实现它们、或评估解决方案实施的效果。以纯研究为目的的工作不应该归结为「经验报告」。另外,它不同于「案例研究」,因为项目发起人的主动参与,只能算作经验报告要求的一部分。http://processplatsen.ibissoft.se/node/72 

 
最后编辑:
作者:同创卓越
这个作者貌似有点懒,什么都没有留下。

留下一个回复

你的email不会被公开。