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.项目的开始时间是否可以提前,后期很多课设的大作业跟软工冲突,没办法严格按照时间表进行。

 

 

posted on 2015-01-15 00:53  hots_buaa  阅读(233)  评论(0编辑  收藏  举报

导航