转载

软件工程经验报告的体会

　　英文原文：Writing Reports In Software Engineering

　　原文作者（author）：Isaac J (Sheepzez)（@sheepzez）

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

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

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

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

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

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

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

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

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

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

　　注释

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

正文到此结束