团队作业——Alpha冲刺之事后诸葛亮

小组成员：

武健男：201421123091

林俊鹏：201421123076

何跃斌：201421123082

陈鑫龙：201421123078

潘益靖：201421123086

黄睿：201421123069

 

一、设想和目标

1.我们的软件要解决什么问题？是否定义得清楚？是否对典型用户和典型场景有清晰的描述？

我们的软件主要是为了解决实验室设备报修问题，典型用户是学校里需要做实验的学生和老师。

2.是否有充足的时间来做？

由于平时课比较多，时间紧张，但我时间就像海绵，只要愿意去挤，还是会有的。但也因此做的比较仓促，做的还不够好。

3.团队在计划阶段是如何解决成员对于计划的不同意见的？

一言不合就开会，六个人聚在一起讨论，畅所欲言。

4.有什么经验教训？如果历史重来一遍，我们会做什么改进？

我只想说，人生中没有如果。

 

二、计划

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

嗯，做完了

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

我觉得，每个阶段你的所作所为都有一定的意义，正是有了这些过程的发展才有了我们所看到的结果，不管这个过程是顺利的还是坎坷的，有正确的，有错误的，我觉得都是必要的，都是不可或缺的，我们都能从中获益。

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

能够衡量的应该是每一次提交的代码吧，但是并没有每一项任务都定义的很清楚，只能说主干任务会比较清晰，比如说我们这个报修系统各个功能的实现，以及小组成员如何去分工等等都是有明确定义的，具体内容都在规格说明书里面。

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

并没有按照原计划进行，就是用户添加的时候选择的文件，原本使用的office 2007和WPS不能提交成功，只能用office 2007，后来了修改了代码，增强了兼容性，现在已经解决了，不过在此期间确实费了许多周折。

5.在计划中有没有留下缓冲区，缓冲区有什么作用？

缓冲区大概是用来缓冲的吧，说真的，我们计划中没有留下缓冲区。

6.将来的计划会做什么修改？

既然我们原来的计划中没有留下缓冲区，那么将来的计划中可定要将缓冲区添加进去的。

7.我们学到了设么？如果历史重来一遍，我们会做什么改进？

这个问题我刚刚已经回答过了，人生中没有如果。

三、资源

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

资源不够：1、时间资源不够，因为大家课程比较紧，时间调度上还是不够自如

          2、人力资源不够，缺乏美观设计师，所以对于页面这块感觉还不够专业

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

我们几乎是每周做好一项任务就测试一次，但是也只是手动测试一下，并没有要专门的测试软件工具，所以精度不高。

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

这个问题，我只能说，既然我们是小组作业，那么每个人不管他的能力如何，贡献如何，我们小组的每一成员都无可替代，we are 伐木累。

5.有什么经验教训？如果历史重来一遍，我们会做什么改进？

额，您好像有点健忘！！！

四、变更管理

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

知道，在博客上会通知。

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

功能的实现时“必须实现”，外观是可“推迟”的。

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

有的

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

这个没有制定，我们都致力于报修系统的功能设计方面去了，具体的功能以及该符合完善，所以这方米昂考虑的不是很周全。

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

老样子，一言不合就开会，意外之事也如此。

6.我们学到了设么？如果历史重来一遍，我们会做什么改进？

。。。拒绝回答！！！

五、设计/实现

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

是由武健男同学来完成，他的领导能力组织能力都比较强，我们每周的计划会议和那个所谓“一言不合就开会”的会议都由他来组织。这我们也一致认可的，所以毋庸置疑，绝对是合适的时间，合适的人。

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

比较少，因为队里有两个编程大师，字典里根本就没有模棱两可这样的词语，还有就是一言不合就开会，虽然这个词用了四次，但是事实就是这样的，哈哈

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

团队没有进行单元测试，主要是时间紧迫。

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

代码中在创建批量用户的时候出现bug，不知道什么原因不能批量创建。在发布之后，好像没发现什么大问题。

5.代码复审是如何进行的，是否严格执行了代码规范？

这项工作时有两位编程大师尽心竭力修改的，然后为我们演示和讲解，在此间我们学到许多，知道了某个函数的执行过程会出现什么结果和对应的实现什么功能

 

6.我们学到了设么？如果历史重来一遍，我们会做什么改进？

。。。您为什么就追着我不放呢？

六、测试/发布

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

有的

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

有的

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

没有，纯手工，所以导致的问题是精度不高，效率也不是很高

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

测试环节我们做的比较不全，希望后期可以好好改进

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

没有，可能有人默默地祝我们心想事成，还是比较幸运的

6.我们学到了设么？如果历史重来一遍，我们会做什么改进？

。。好吧，服了你了，那我就说说吧，如果有如果，历史的车轮在倒退，回流的年轮在穿梭，我们回到了还没开始的时间：

A.计划要周详，因为工程的实施大部分还是按照计划去一步步实现的，没有好的详细的计划，能力技术再强，做出来的结果也会不尽人意

B.人员分配要合理，这点我们觉得还是有做到的，只是有些方面比较欠缺，所以还是准备得不够充分，需要努力

C.时间的利用，本来时间就紧，不应该浪费一分一毫在一些没必要的事情上面

最后，我还是想再强调一点，这个问题问的不好，因为人生没有如果，每一天都是现场直播。

 

团队贡献分：

 

武健男（201421123091）：17

 

林俊鹏（201421123076）：16

 

何跃斌（201421123082）：19

 

陈鑫龙（201421123078）：15

 

潘益靖（201421123086）：19

 

黄睿（201421123069）：17