团队作业7---Alpha冲刺值事后诸葛

一、设想和目标

1.我们的软件要解决什么问题？

解决教师和助教对实验报告查重的问题，拥有两个用户：1.教师或助教：查看学生实验报告的重复率；4.学生：上传实验报告。

2.是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

是，在做这个选题时有一些设想，并且在正式的需求分析阶段和老师进行了交流，了解了老师的需求，对典型用户和典型场景的描述较为清晰。

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

有，时间交充裕。

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

如果有意见，通过讨论来协商解决问题，最终由组长来拍板决定。

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

Alpha版本的用户目前只有我们小组的成员，基本功能还是如期实现了，离目标确实更近了。

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

开始的时候设想的功能比较复杂，想太多了，后期进行开发时，其实只主要考法了核心功能，其他额外功能都被砍了，如果重来一遍，应该要明确主要要开发什么功能，并且将需要做的事落实到个人。

二、计划

在一个星期的时间里：

⑴ 新增一名队友，要求其在一天内，了解并熟悉我们所制作的电子文档查重系统。并且我们在当天开一次会议，宣布我们需要进行修改的bug内容：查看重复的可以点开链接直接看、可以把重复的部分用红色的字体标记出来、按钮的设置以及适当美化界面。

⑵ 利用接下来的三天的时间里，两个队友为一小组合作处理一个bug，每天开会并制定相应的敏捷流程。

⑶ 利用剩下的三天，小组互相对其他组的bug再进行测试，并提出问题帮助完善代码，除了制定当天的敏捷流程外，在小组会议上讨论测试结果。

三、资源

1.我们有足够的资源来完成各项任务么?
有足够的资源来完成各项任务
2.各项任务所需的时间和其他资源是如何估计的，精度如何?
在精度方面我们本来想好好完成的，可是随着时间的推移任务的加重精度很多时候都是草草了事。
3.用户测试的时间，人力和软件/硬件资源是否足够?
人力和软件、硬件资源都挺充足的
4.你有没有感到你做的事情可以让别人来做（更有效率）?
感觉都差不多。当然给组长做的比较快咯。

四、变更管理

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

知道。每次的任务我们都会召开小组会议，如果不方便当面讨论也会开展网上会议，除此之外，我们还建立了一个讨论群，讨论任务分配问题。每个人都会有相应的任务分配。

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

因为我们小组项目的主要用户是老师，所以在项目开始之初，我们小组访问了老师，事后结合小组成员的意见，讨论出我们项目组要实现的功能。“必须实现”的功能我们在alpha已经基本实现。“推迟”的功能就是在“必须实现”功能里没有完成有一定技术难度的。在后续的beta计划里我们会争取实现。

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

有，我们对此的定义是基本能符合老师的需求。当然由于我们的某些功能还未实现，所以还没有给老师使用。

4.对于可能的变更是否能制定应急计划？

目前的话，基本没有什么的变更，如果有的话，我们小组会一起讨论并面对的，相信团队的力量。哈哈！

5.成员是否能够有效地处理意料之外的任务请求？

可以，目前来说，我们还没遇到意料之外的任务请求，但是，如果有遇到的话，我想我们也能积极的面对。首先，我们有一位特别认真的好组长，加上热情的组员，发现越来越喜欢这种团队合作的方式了，众人拾柴火焰高！

五、设计/实现

1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
有些界面的设计过早，大家为了字体的大小，按钮的尺寸争论，事实上这些事情不应该由开发人员在项目早期来做。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
很多，大家都不知道如何解决。就看具体执行的人是如何解决的，有的解决得好，大家并不知道出过问题；有的经常拿出来讨论，大家都知道问题在哪里，但是没法达到一致。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
只用了单元测试，这些工具还是很有效的。
4.什么功能产生的Bug最多，为什么？
上传文件功能由于牵涉的面太多，Bug也最多。

六、测试和发布

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

我们有测试计划，而且因为有了计划，测试人员好像不再像无头苍蝇胡乱测试；

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

不是很正式的，但有进行验收测试，虽然结果不尽人意；

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

没有；

4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
由于是第一次做这样的项目，并不知道要用什么工具来解决这样的问题；

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

由于功能有很多的不完善，加上出现了很多的BUG，所以还没有发布，想等进一步完善后再发布；

七、开会照片，贡献分

阿杰那天有事情没到，由于组长长得太“丑”了，所以就担任摄像师一职；

贡献分的分配：由于组长有点水，加上组员之间也是比较配合的，所以我就得每个人都应该相同的；

八、总结

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

1. 在Alpha冲刺之前，我们团队有针对我们的项目做过需求分析以及项目计划

2. 在Alpha冲刺阶段，我们小组通过github进行项目管理，每天会向组长汇报自己的工作量以及工作进度

3. 在Alpha冲刺之后，团队有了类似项目的开发经验，一定程度上可重复类似项目的软件开发

4. 小组有测试人员，通过案例测试充分保证了软件Alpha版本的核心功能的使用以及质量地保障

5.我觉得我的团队应该属于可重复级。

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

1. 在Alpha冲刺之前，我们团队每个人都没有项目开发的经验，虽然大多数人都有一定的JAVA语言基础，但是并不知道自己的能力到那个地步；

2. 在Alpha冲刺阶段，组长根据每个人在java能力和web学习的进展程度来分配任务，页面设计交给了web语言学习进展较快的队友来做，偏向JAVA语言方向的就交给剩余的人

3. 在Alpha冲刺之后，团队的每个人并不能体现出自己的强项和自己的代码能力，所以在项目开发过程当中任务的虽然有一个具体的指标，但是每个任务对于成员来说都要一定的难度加上第一次合作默契什么的都不是很好，所以团队还处于磨合阶段

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

1. 有了这次的经历，让我们可以更加从容的面对软件开发，虽然做的不是很好，但通过这次有了一定的经验了；

2. 通过这次让我们小组成员之间的默契和合作精神更上一步，虽然还不是很好就是了；之间的感情也更加不错了；

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

编写代码的不规范，代码编写的有各自的风采，导致了代码合在一起时，会出现这样那样的问题，导致了不少的矛盾；加上第一次合作，有些同学之间也不是很了解，所以在合作方面出现了很多问题；