团队作业10——Beta版本事后诸葛亮

事后诸葛亮分析

1、总结的提纲内容：

a. 项目管理之事后诸葛亮会议。

我们的软件要解决的是教师需要花费大量时间，精力来手动组成试卷，并人工评卷的问题，代替的是自由组卷出卷评分系统。通过根据用户在web给出的科目、难易度、题型等自动从数据库或错题库导入题目，自动生成一份试卷，用户可在上面作答，系统自动判断错对，答题结束后进行评分。我们认为定义的较为清楚。典型用户和典型场景在团队作业3——需求改进&系统设计的博客中有体现： http://www.cnblogs.com/vviane1/p/6744976.html[/code] 
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?

目前算是达到了1/3吧，原计划的功能还有些没有实现，大体上可以实现基本功能。本来是打算对用户的身份进行分类，对于管理员，教师，学生等不同身份，有不同的功能权限，科目，题型的选择更加多元化，对于错题有详尽的解析，但是并没有完全完成。不过好歹在最后时刻也是完成了Beta版本的发布，只是由于功能尚未完善产品还未大范围宣传。而对于原计划的用户数量肯定是尚未达标，目前用户暂时只有我们团队的内部人员以及一些同学。


用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

用户对于重要的基本功能的接受程度还算和预想一致，当然问题肯定是有的，我们会继续努力，离目标更近一些。


有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

对于数据的分类、来源不固定，不同用户身份的权限，一开始没有好好处理。如果历史再来一遍的话，我们会先对数据进行的分大量析，整理，整合成一个完整的数据库，内容庞大，来源固定，分类有序，将不同用户的不同需求进行划分，给予不同功能的权限设置。


二、计划

是否有充足的时间来做计划?

目前大三课程较多，实验也特别多，有些队员还有在准备考公考研，课后还有上培训班，基本上每次开会都比较匆忙简短，时间上就不够充足了，只能做粗陋的计划，对于细节的把控肯定不好。


团队在计划阶段是如何解决同事们对于计划的不同意见的？

一般是大家把问题提出来，有分歧的时候，大家再进行协调，基本是少数服从多数吧。


你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

每个人原计划的工作算是没有都完成吧，对于编程、美工以及测试方面，由于有些功能没有实现，其实不算真正的完成，不过就是有一个简陋的版本，实现基础功能罢了。


有没有发现你做了一些事后看来没必要或没多大价值的事?

没有，不过有出现事后看来应该做的事而前期没有做到。


是否每一项任务都有清楚定义和衡量的交付件?

每一项任务定义清楚好像基本做到，交付件基本上有，比如代码文件、软件需求规格说明书还有博客应该也算吧。


是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

一开始由于大家不熟悉团队编程，彼此间没有默契，自然进度就比较缓慢了，不过慢慢的就彼此熟悉了。项目倒是没有很大的意外，风险的话倒是没有考虑到这一点，就不知道怎么回答了。


在计划中有没有留下缓冲区，缓冲区有作用么?

没有。


将来的计划会做什么修改？（例如：缓冲区的定义，加班）

将来计划会对于每天的任务会进行详细的划分，经常进行一些团队间的讨论，遇到问题时，及时，准确的向大家提及，这样方便讨论。


我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

通过这段时间，我们学到很多，比如对于NABCD各方面的分析，还学会了如何用燃尽图管理项目进度，以及如何进行团队合作还有博客园、团队项目的管理，界面原型设计工具的使用等。如果历史历史重来一遍，我们会做出的改进就是完善需求，整体框架做的好一些，每个人的任务分派再细致一下。


三、资源

我们有足够的资源来完成各项任务么?

对于技术的学习、数据的搜集等可以通过阅读校园图书馆的书籍或者网络查询多种方式来实现，就是时间上会有所欠缺，毕竟课程也较为紧张。


各项任务所需的时间和其他资源是如何估计的，精度如何?

只能说比较粗略的估计了大概应花费的时间和其他资源吧，任务的分配，角色的划分，编程人员根据需求人员给出的汇总进行功能的编程实现，测试人员在此期间不断进行测试，美工人员负责完善界面，由于项目进行的紧张，精确度就差不多吧。


测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试是一直进行，时间就够充裕，人力与软件/硬件资源也足够。对于那些不需要编程的资源 (美工设计/文案)，确实低估了难度，界面的美观没有很好地达到，导致现在的界面很单调，博客方面确实超出想象了，难度不小，而且助教是根据博客的内容评分，自然对博客的要求就不同，我们在这上面确实花费了不少的时间。


你有没有感到你做的事情可以让别人来做（更有效率）?

还好吧。。。


有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

·成员的分工要尽量清楚细致一些，争取每个人都能很好完成任务。
·如果历史重来一遍，我们会尽力完善我们的功能，达到甚至超出用户预想，多次进行代码测试，减少BUG的出现。


四、变更管理

每个相关的员工都及时知道了变更的消息?

对于每次变更，会在团队的群里进行通知。


我们采用了什么办法决定“推迟”和“必须实现”的功能?

内部讨论，对于用户提出的需求进行分析后决定。


项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

实现主要功能，能够自由组卷、自动评分。


对于可能的变更是否能制定应急计划?

只能说有限的时间内有限地实现。


员工是否能够有效地处理意料之外的工作请求？

对于意料之外的工作请求，我们会大家一起努力完成。


我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们学到了团队的重要性，一个人的力量是有限的，有时候那些你自己无法解决的问题，当抛给团队一起讨论时，问题可能就变得简单了。所以队员之间要相互配合，相互合作，才能更好的实现团队价值。
如果历史重来一遍，我们会强调组员间的配合，发挥最大的合作效率。


五、设计/实现

设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作是在需求分析的时候开始的，由全体成员一起商量讨论完成的，应该是比较合适的。


设计工作有没有碰到模棱两可的情况，团队是如何解决的？

经常遇到模棱两可的情况，团队通常是通过查阅资料，讨论解决的。


团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

没有使用这些工具，就无法说明其好坏。


什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

自由组卷功能产生的Bug最多，因为我们使用随机分配的方式，那在题目较少的情况下，题目的重复率就会有点高了。


代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

一人写完自己的代码之后，交由另一人复审。


我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们学到了设计/实现阶段要认真，基本上就是架构接下来的项目模型了，如果历史重来一遍, 我们会更加认真的设计我们的基础模型。


六、测试/发布

团队是否有一个测试计划？为什么没有？

我们团队有一个测试计划，在团队作业3——需求改进&系统设计的博客中有体现：http://www.cnblogs.com/vviane1/p/6744976.html


是否进行了正式的验收测试？

没有正式的验收测试，只是一些演示而已。


团队是否有测试工具来帮助测试？

没有。


团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

经常性的进行测试，找出bug，解决它。


在发布的过程中发现了哪些意外问题？

没有。


我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们学到了测试是随着代码编程一直在进行的，如果历史重来一遍, 我们会继续努力的。


七、团队的角色，管理，合作

团队的每个角色是如何确定的，是不是人尽其才？

根据大家讨论的结果，每个人负责擅长的角色。


团队成员之间有互相帮助么？

是的，出现问题时，大家会一起讨论解决。


当出现项目管理、合作方面的问题时，团队成员如何解决问题？

当出现项目管理、合作方面的问题时，团队成员会进行协商，讨论出解决方案。


我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

我们学到了团队合作的益处，当有问题或者出现矛盾时，大家会一起解决，方便快速。如果历史重来一遍, 我们会更加相信自己的队友，一起进步，团结和谐。


八、总结:

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

属于CMM吧。


你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

规范。


你觉得团队在这个里程碑相比前一个里程碑有什么改进?

相互之间的配合更默契了，效率也提高了。


你觉得目前最需要改进的一个方面是什么?

实现更多的功能。


对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

我们小组做的最好的是第六点（无论团队内外，面对面的交流始终是最有效的沟通方式）。我们的项目每一次都有按照制定的计划分配每个队员各自的任务，不断进行更新完善。组长也经常召开线下会议，面对面的解决遇到的困难和一些分歧，因为面对面的沟通是解决问题和增强团队凝聚力最直接有效的方式。


b. 博客要附上全组讨论的照片。


2、团队成员在Alpha阶段的角色和具体贡献：