小小小——事后诸葛亮

软件工程	https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1
作业要求	https://edu.cnblogs.com/campus/zswxy/software-engineering-2017-1/homework/10863
团队名称	小小小
作业目标	团队测试总结
作业正文	见下文
其他参考文献	百度

一.设想和目标

1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
A：我们的软件要解决的是各种连锁门店之间的管理问题。定义清楚，面向管理员。对典型用户和典型场景有清晰的描述。

2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
A:没有达到，原计划功能：门店信息的修改，增加门店，订单的改，订单的增加，单独门店的订单管理，客户的点单系统。按照原计划时间交付了。

3.和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
A:和上一个阶段相比，团队软件工程质量提高是肯定的。在编码的风格和规范上面，具体提高了一个档次，从不规范到规范的档次，从编码规范来衡量，之前的编码规范程度和现在编码的规范程度。

我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

A：离目标更近了。经验教训：更加注重分工合作，和时间安排。如果历史重来一遍，我们会加快时间进度，和分工更加明确具体。

二.计划

1.是否有充足的时间来做计划?
A:时间充足，课程时间足够长，有足够的时间计划。

2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
A:进行商量讨论，最后抉择出一个最终方案，一个大家都认可的方案。

3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
A:没有，三点原因，第一分工问题，第二自身能力问题，第三世界问题。

4.有没有发现你做了一些事后看来没必要或没多大价值的事?
A:有，但是还是能够提供经验，没必要没价值的事情做了其实也有一点价值，就是下次你就知道了。

5.是否每一项任务都有清楚定义和衡量的交付件?
A:没有，每个任务都有相应负责人，但是每个模块的验收标准没有具体的明确。

6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
A:没有，每个人的任务不能确保同步完成。时间和能力风险没有预估到，组员都不太了解。

7.在计划中有没有留下缓冲区，缓冲区有作用么?
A:没有留下。缓冲区能够减少意外影响。

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

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

A:学到了计划的重要性，如果历史再来一遍，我们会更注重计划。

三.资源

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

2.各项任务所需的时间和其他资源是如何估计的，精度如何?
A:所需时间靠自己预估的，不太尊亲，也没有标准，自己也没有经验。

3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
A:测试方面资源足够，但是我们没有做，时间和能力问题，对那些不需要编程的资源，我们也很重视。

4.你有没有感到你做的事情可以让别人来做（更有效率）?
A:有，每个人比较会的部分个月不同，但是也不能全追求效率，要每个人每方面涉及。

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

A:学到了利用资源和时间的重要性，如果历史再来一遍，我们会改进时间的安排，更加好的利用资源。

四.变更管理

1.每个相关的员工都及时知道了变更的消息?
A:及时知道了，交流群随时发变更消息。

2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
A:单独的模块可以“推迟”，关联上下的模块“必须实现”。

3.项目的出口条件（Exit Criteria）是否得到清晰的定义?
A:没有

4.对于可能的变更是否能制定应急计划?
A:没有出现变更，能。

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

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

A:我们学到了对变更的应对，如果历史重来，我们会增加对变更的的应对。

五.设计/实现

1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
A:设计工作是在项目开始的时候，一起设计的。

2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
A:有，现实语音电话商讨解决。

3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这A:没有使用，在绘制类图时UML提供了一定的便利，不需要更新UML文档。
。
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
A:前端，兼容问题。在发布之后没有发现bug。

5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
A:没有进行代码复审。

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

A:学到了代码审查的重要性，重来一遍，会进行单元测试和代码审查。

六.测试/发布

1.团队是否有一个测试计划？为什么没有？
A:没有，能力原因和时间原因。

2.是否进行了正式的验收测试？
A:没有

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

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

5.在发布的过程中发现了哪些意外问题？
A:没有出现意外。

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

A:学到了，测试的重要性，重来一遍，会制定测试计划，和用测试工具来测试。

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

1.团队的每个角色是如何确定的，是不是人尽其才？
A:团队角色分工主要根据个人喜好与技术特点进行针对分工,人尽其才。

2.团队成员之间有互相帮助么？
A:有

3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
A:项目管理合作的问题，如果是两个人，小问题尽量协商解决，大问题都是团队协商，一起解决。

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

A:学到了团队安排的重要性，如果再来一次，分工会更加细致，任务安排更加合理，加大效率。

八.总结

1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
A:CMM,第二级：可重复级(Repeatable)基本的项目管理管理.

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

3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
A:大家都有了一定的进步，不管是在个人能力方面，还是团队项目跟进方面。

4.你觉得目前最需要改进的一个方面是什么?
A:专业技术的不足

5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例
A:项目过程中，业务人员与开发人员必须在一起，项目过程中，我们都在学校。
无论是团队内还是团队间，最有效的沟通方法是面对面的交谈，有问题经常到寝室面对面交流。
团队要定期反省如何能够做到更有效，并相应调整团队的行为，经常反省项目和个人问题。