M2事后分析

计划

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

    修复了M1阶段的bug，整合前两组的数据。扩充功能，和学霸组达成功能上的一致，对数据库进行信息的完善。

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

　 M2阶段更有目的性，只是解决bug的过程比较费时。

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

    后端的接口代码，接口测试，接口说明文档，接口使用demo。

    前端代码，操作说明文档。

    UI中xml文件。

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

    前期计划有拖延，和大作业有冲突，后期抓紧完成了。

 

资源

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

    成员的能力毋庸置疑，他们的能力完全可以解决现有的问题，只是时间问题。

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

    根据M1阶段完成任务的时间和效率，给每位开发人员分配了任务。

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

    测试的时间贯穿了整个项目的开发过程，文案和UI设计也分担一些测试的工作，没有低估难度。

 

变更管理

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

    开发阶段会开每日例会，每天我们都通过QQ群进行消息的通知，TFS签入代码。

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

    原先已经完成的功能我们最先做，要扩充的功能可以稍后再做。

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

    实现了基本功能，经过黑盒白盒测试，可以保证bug在一定范围内。

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

    对于之前遇到的一些问题和挑战，我们都及时召开会议商讨解决方案。因为在项目中，我们在前端设置了两名人员，后端有两名人员，还有一位机动人员，相对能力更强一些，可以随时处理一些应急事件。

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

    从团队创立到现在，我们没有一个人因为懈怠而放弃自己的工作，每个人几乎拿出了200%的热情去对待项目。意料之外的工作请求大概每天都会出现，主要原因还是原有代码中问题过于多，以至于在进行开发的过程中，不得不花费超出一倍的时间去修复，而不是去创造。

 

设计/实现

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

    在M1阶段总结的时候已经设计了M2阶段的任务，由大家共同讨论决定。

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

    没有。

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

    用到了单元测试，百度开发的测试软件。

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

    参见bug列表。

 

测试/发布

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

    有，根据老师的要求。

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

    在百度测试软件上。

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

    百度的测试软件。

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

    主要的测试用百度的软件，根据结果来看。

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

    暂时没有。

 

总结：

1.服务器不能容纳很多组同时使用，导致在项目的收尾阶段因为服务器的缘故耽误很多时间。

2.项目的开始时间是否可以提前，后期很多课设的大作业跟软工冲突，没办法严格按照时间表进行。

 

 

转载于:https://www.cnblogs.com/hotsbuaa/p/4199909.html