团队作业9——事后分析（Beta版本）

事后诸葛亮分析

1. 1.         总结

团队合照

 

a. 项目管理之事后诸葛亮会

·设想和目标

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

个人学习计划提醒系统，旨在做出一款全新的产品，让它改变我们平常习惯在纸上制定学习计划的方式。老师和学生都可以通过该系统提醒用户任务完成进度，根据事务紧急程度进行排序，显示日程的安排情况，显示当前是第几周，导入课程表，改日程安排等问题。

（2）我们达到目标了么（原计划的功能做到了几个？  按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?

我们原计划的功能基本实现了，虽然并不是那么完美，也按是交付了，但是用户数量却没有达到。

（3）用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

不太一致。主要是我们一些功能没有做到最好，例如我们只能手动一个个添加课程表。

·计划

（1）是否有充足的时间来做计划? 

有足够的时间来做计划，每个阶段老师都有给我们一个星期的时间，可以说时间还是非常充足的。

（2）团队在计划阶段是如何解决同事们对于计划的不同意见的？

在团队计划阶段各个小伙伴对项目有各自的理解是一种正常的现象，这也表明每个组员对项目都是负责的都希望可以高效地做好这个项目，因而对与组员提出的不同的意见我们是采取积极响应的态度，共同商量采取对项目实现最优的方案。

 

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

原计划的工作并没有完全做完。主要是我们团队能力有限，有些设想的功能没有完美的实现出来。

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

可能是我们团队的计划安排的比较好，在整个过程中并没有发现所谓的没有价值的事。

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

我们队每个人每周的工作量都有清晰的定义，每个人的任务都分配的很清楚。

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

基本上都按计划在进行如果说有什么意外和风险的话，那就是我们很多队员有段时间都在忙着找工作、准备面试，所以没有很按时的完成任务。

 

（7）在计划中有没有留下缓冲区，缓冲区有作用么?

有留下缓冲区，因为在开发过程中总是会遇到种种问题的，例如遇到了瓶颈，又或者是像上面所说的大家都在忙着找工作。所以为了按时完成开发，缓冲区还是很有必要的。

 

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

对与需求分析的理解组员们需要一致，分工之后，组员间还是需要加强沟通。

·资源

（1）我们有足够的资源来完成各项任务吗？

人数上来说是很充足的，但是由于我们已经大四了，大家都有各自的事要忙，所以完成各项任务还是有点吃力的。

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

我们在每周的会议上都有对时间及资源进行分配，精度还是较为准确的。

（3）测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源，是否低估难度？

足够；没有低估难度。

 

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

我觉得我们队人员安排的比较合理，大家都在做自己擅长的事，所以我们还是各司其职比较有效率。

·变更管理

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

我们几个宿舍都离得很近，而且现在QQ微信什么的都很方便，大家都可以及时沟通。

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

 我们采取少数服从多数的原则来决定。

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

没有清晰的定义，不是很清楚做到什么程度算做好了。

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

可以，比如有人这周真的很忙，那么我们就会讨论谁先去接替他的任务，然后他之后再去完成其他的任务。

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

可以的，对于处理意料之外的工作请求，我们会集体讨论，看谁比较适合完成这个任务。

·设计/实现

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

设计工作在需求分析完成之后，有大家集体讨论，然后前端负责完成。是合适的时间与合适的人。

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

有碰到，团队成员一起出来开会讨论，集思广益。

 

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

运用了单元测试，帮助我们发现了不少bug。

（4）什么功能产生的Bug最多，为什么？

发邮件这个功能，因为要抓一个邮箱的接口。

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

将代码传到coding上，大家一起检查。有执行。

·测试/发布

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

有测试计划。

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

没有正式的验收测试。

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

有的，能够解决一些常识引起的bug，减少了人力，提高了效率。

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

主要是通过人员检测，实际效能和预期效能决定性能；测试工作还是很有帮助的，就是后期应该多借助点测试软件帮助可能会提高效率

 

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

存在一些Bug

·团队的角色，管理，合作

（1）团队的每个角色是如何确定的，是不是人尽其才？

每个人的角色安排是在最开始做需求的时候，我们就通过开会讨论谁比较擅长哪个方面来确定。应该说是人尽其才了。

（2）团队成员之间有互相帮助么？

有的。

 

（3）当出现项目管理、合作方面的问题时，团队成员如何解决问题？

团队间会做好沟通来解决问题。

 

（4）对成员帮助的感谢

a.毛忠庆:感谢王海峰同学，在我设计系统的时候，有时思路不够清晰，是他帮我捋清了思路

b.陈昊元:感谢林仙平，是他帮助我很好的完成了我的工作，偶尔还帮我写博客。

c.林仙平:我感谢陈俊达同学对我的帮助，因为在我对系统设计比较不清楚的时候，主动帮助我，向我说明。

d.王海峰: 我感谢毛忠庆同学对我的帮助，在对软件测试方面提供基本常识方面的工作。

e.陈俊达:我感谢陈昊元同学对我的帮助，因为在我完成前端工作时，他会跟我详细讲参数的传递等等。

 

·总结:

（1）你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

属于可重复级。

 

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

处于规范阶段。

 

（3）你觉得团队在这个里程碑相比前一个里程碑有什么改进?

大家配合的更有默契了，互相的沟通也更频繁了。

 

（4）你觉得目前最需要改进的一个方面是什么?

我们团队有拖延症。。。

（5）对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则?

我们小组做的最好的是“以有进取心的人为项目核心，充分支持信任他们”与“保持简明--尽可能简化工作量的技术--极为重要”，对于团队成员，我们都有充分的信任与支持，对于团队的工作也尽量的简明扼要。

 

2.团队成员在Beta阶段的角色和具体贡献

名字	角色	可验证的团队贡献	团队贡献分
毛忠庆	PM	设计系统框架	30
陈昊元	后台开发	数据的传递与接受	25
林仙平	后台开发	后台的逻辑	15
王海峰	测试人员	找出了许多bug并改正	15
陈俊达	前端开发	界面的设计与实现	15

项目复审

代码地址：https://gitee.com/ouwen0819/ZhongGuoGongShangYinXingWangShangYinXing/tree/master