团队作业10——事后分析（Beta版本）
Posted 阿里码码小组
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了团队作业10——事后分析（Beta版本）相关的知识，希望对你有一定的参考价值。
一、设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们软件是帮助教师和助教收集查看实验报告并解决实验报告的抄袭问题，基本用户有两个：1、教师或助教；2、学生。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
我们基本达到了大部分目标了，但是还是有一些问题还没解决
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
因为存在一些问题并没有发布，目前的用户还是只有我们小组；当然阿是里目标更近了
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
一开始就要做好计划吧，明确到底要做什么，怎么做，不要花太多时间在弯路上，如果能够重来希望能够让软件发布。
二、计划
1. 是否有充足的时间来做计划?
有 。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
成员进行商讨解决，最后由组长拍定。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原定计划基本都做完了。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有。
5. 是否每一项任务都有清楚定义和衡量的交付件?
大部分是。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目的过程还是挺顺利的，要说意外的话还是beta阶段时候已经差不多是期末了，导致一个bug无法解决不能发布
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
有预留一点，但是还是时间不够，期末还是太忙了。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
留下更多的缓冲区吧
三、资源
1. 我们有足够的资源来完成各项任务么?
这个呢，还是有的。我们的最大资源就是我们的组长啦。组长的编程能力比强，也会带我们的小组成员一起完成任务，小组还有一位界面设计者，对界面的设计有自己的心得体会。还有优秀的文档编写人员，每个人都有自己的特长，各司其职，组合起来就成了我们这个大家庭啦.
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
我们将任务划分到天，每天完成相应计划的任务数，并没有很严格的要求。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试还是占了我们比较多的时间。人力和软件/硬件资源还是够的。对于美工设计和文案我们有重视，毕竟这是展示部分，但是也需要努力提高我们各部分的能力。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
会吧，有些时候我分配到的任务是文档的写作。可能本人的文笔也不是很好。小组中不乏文笔比我好的人。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
有时候任务完成得不够好，比如有一次负责写博客的成员因为晚上有事情，导致当天的博客没有按时提交。如果历史能重来，我们肯定做好应急备案，考虑事情全面一点。防止此类事情的再次发生。
四.变更管理
1. 每个相关的成员都及时知道了变更的消息?
知道，每次我们会把博客上的任务划分。每个人选取相应的来完成。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
“必须实现”的功能是项目的主要功能。“推迟”功能是一些比较次要的功能。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
我们的项目是报告的查重的功能，对“做好了”的定义是网页可以实现用户的登陆，几份报告可以对比其相似度，并且统计相似度。
4. 对于可能的变更是否能制定应急计划?
这方面确实没做好，上面提到了，有一次博客晚提交了，就是我们没有考虑周全。
5. 成员是否能够有效地处理意料之外的任务请求？
能。当项目需要修整时，大家都愿意一起面对，共商讨解决方案。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
虽然我们的项目可能完成得并不好，但是一个学期下来，多少每个人都有所收获。也学会了怎么跟小组成员合作。如果历史能够重来，我们会做好变更，考虑到可能会出现的突发性问题。
五、设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
有些界面的设计过早，大家为了字体的大小，按钮的尺寸争论，事实上这些事情不应该由开发人员在项目早期来做。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
很多，通过团队讨论来决定采取那个方法；如果还是没有结论，有相关人员来决定；还是不行由组长来决定。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
只用了单元测试，由于对于测试的能力不足，我们也没有采取其他的测试方法来测试；
4.什么功能产生的Bug最多，为什么？
选择文件的方法（只取前10个文件，多余的不行了，少了会报错），读取数据库的值（由于有对数据库的内容进行修改，而代码中没有修改，导致了读取的错误和运行的错误）
六、测试/发布
1.团队是否有一个测试计划？为什么没有？
2.是否进行了正式的验收测试？
3. 团队是否有测试工具来帮助测试？
七、成员感悟
刘光华：
1.每个成员在beta 阶段的实践和alpha 阶段有何改进?
完善老师的账号注册、修改；
2.团队在beta 阶段吸取了那些alpha 阶段的经验教训?
成员应该自动完成任务，而不是让其他成员来催；
3.总结
通过这次的软工，我觉得团队在一起的乐趣高于个人独自完成的乐趣，虽然之间有不少的矛盾，但是它只是促进我们感情的进一步深化而已。
林晨昕：
1.每个成员在beta 阶段的实践和alpha 阶段有何改进?
更加注重效率了吧，尽量不要拖延时间，自己的编程基础也提高了一点
2.团队在beta 阶段吸取了那些alpha 阶段的经验教训?
经过alpha阶段的合作后，成员们对彼此都有了一定的了解，在beta阶段磨合速度快了很多，也能够很好的去安排组员做更合适的工作。
3.总结
在软件工程的学习过程中我还是学习到很多东西的，了解的项目的开发的具体过程，提高了自己的编程基础，还学了很多课外的一些知识，过程之中虽然累也觉得事情太多很烦，但是完结之后看看还是有着很大的收获，是一个不错的经历。
林莹：
1.每个成员在beta 阶段的实践和alpha 阶段有何改进?
Beta阶段对团队合作这种方式更加熟悉，beta的初期我们团队加入了两位新成员，一开始还比较陌生，但很快他们就融入了我们团队。熟悉了我们的项目。出了什么问题大家都会共同商讨方案，一起解决。相对于alpha阶段，我们对之前的项目一些不完善的地方进行改进，也对项目进行了测试。
2.团队在beta 阶段吸取了那些alpha 阶段的经验教训?
人员分工问题。之前我们的人员分工存在着一些问题。并不是很合理，在beta阶段，我们重新对每个人的工作进行分工，每个人选择自己比较擅长的模块。提高了效率。
3.总结
说实话，这学期真的很累，每个星期都有一种在做课设的感觉。不过收获还是蛮大的。
尤少辉：
1.每个成员在beta 阶段的实践和alpha 阶段有何改进?
2.团队在beta 阶段吸取了那些alpha 阶段的经验教训?
3.总结
洪世豪:
1.每个成员在beta 阶段的实践和alpha 阶段有何改进?
按钮的设置
2.团队在beta 阶段吸取了那些alpha 阶段的经验教训?
组员的分工要适当的安排，而不是一味地让组员自己选择；
3.总结
通过这次的软工，我体会到了个人的能力是有限的，如果不借助他人的帮助有些问题,个人是很难解决的，但是也不能过度的依赖于人，适当的借助他人会促进感觉的加深。
程志铭：
1.每个成员在beta 阶段的实践和alpha 阶段有何改进?
修改文件上传的方式（学生的姓名和文件关联在一起）；
2.团队在beta 阶段吸取了那些alpha 阶段的经验教训?
事情应该提前做好，以防止有突发事件的产生导致任务的未完成；
3.总结
总在这次的团队合作中，收获颇丰。在学习方面，进一步巩固学习了编程并运用于开发中，提高了自己的水平。在人际方面，大家在一起交流，提出问题，分析问题，解决问题，一起进步。这次经历，挺难忘的。
王杰：
1.每个成员在beta 阶段的实践和alpha 阶段有何改进?
alpha阶段我是关于学生页面设计与代码编写的，这块内容感觉完成的相对较为不错，毕竟花费了大部分的时间，一直在编写与代码完善，使得界面看起来更美观；beta阶段，和组长一起对老师提出的问题----重复部分使用红色标出进行修改，虽然过程有点艰辛，但是还是完成了。
2.团队在beta 阶段吸取了那些alpha 阶段的经验教训?
时间把握不够以及个人事情耽搁，导致和队友衔接出了点小问题，多亏组长协助，成功克服了。
3.总结
经过整个学期的学习，收获很丰富，不仅提升了个人的能力也接触了与小组成员合作完成一个项目，虽然过程是艰辛的，但是还是挺开心的，毕竟我们还是成功的把项目完成了，尤其是其他队员们的不放弃的精神，深深鼓舞了我。
以上是关于团队作业10——事后分析（Beta版本）的主要内容，如果未能解决你的问题，请参考以下文章
集美大学网络1413第十五次作业成绩（团队十） -- 项目复审与事后分析（Beta版本）