首页 > 代码库 > M2事后分析
M2事后分析
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
原计划是修改M1阶段发现的bug,并进行修复。测试软件性能,增加自动更新功能。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
M2阶段更有目的性,只是解决bug的过程比较费时。
3. 是否每一项任务都有清楚定义和衡量的交付件?
代码测试覆盖率,用户体验,专业测试软件。
4. 是否项目的整个过程都按照计划进行,有什么风险是当时没有估计到的,为什么没有估计到?
基本上整个项目都按照计划进行,就是在期末的时候时间很紧,有很多课程的大作业都要完成,后期的工作做得非常仓促。
资源
1. 我们有足够的资源来完成各项任务么?
成员的能力毋庸置疑,他们的能力完全可以解决现有的问题,只是时间问题。
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
根据M1阶段完成任务的时间和效率,给每位开发人员分配了任务。
3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间贯穿了整个项目的开发过程,文案和UI设计也分担一些测试的工作,没有低估难度。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
开发阶段会开每日例会,每天我们都通过QQ群进行消息的通知。TFS签入代码。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
因为软件的基本功能确定,我们在决定一个功能是推迟实现还是必须实现时是围绕基本功能确定的。
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
我们在认定软件的出口条件时以是否能够实现基本功能为准则,如果能够实现,那么可以发布。
4. 对于可能的变更是否能制定应急计划?
对于之前遇到的一些问题和挑战,我们都及时召开会议商讨解决方案。因为在项目中,我们在前端设置了两名人员,后端有两名人员,还有一位机动人员,相对能力更强一些,可以随时处理一些应急事件。
5. 员工是否能够有效地处理意料之外的工作请求?
从团队创立到现在,我们没有一个人因为懈怠而放弃自己的工作,每个人几乎拿出了200%的热情去对待项目。意料之外的工作请求大概每天都会出现,主要原因还是原有代码中问题过于多,以至于在进行开发的过程中,不得不花费超出一倍的时间去修复,而不是去创造。
设计/实现
1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
在M1阶段总结的时候已经设计了M2阶段的任务,由大家共同讨论决定。
2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
没有。
3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
用到了单元测试,百度开发的测试软件。
4. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
参见bug列表。
测试/发布
1. 团队是否有一个测试计划?为什么没有?
有,根据老师的要求。
2. 是否进行了正式的验收测试?
在百度测试软件上。
3. 团队是否有测试工具来帮助测试?
百度的测试软件,UML。
4. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
主要的测试用百度的软件,根据结果来看。
5. 在发布的过程中发现了哪些意外问题?
暂时没有。
总结:
1.服务器不能容纳很多组同时使用,导致在项目的收尾阶段因为服务器的缘故耽误很多时间。
2.项目的开始时间是否可以提前,后期很多课设的大作业跟软工冲突,没办法严格按照时间表进行。
M2事后分析