业第6周——事后诸葛亮分析
一、事后诸葛分析：
设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
本软件主要解决广工校园附近的订餐小程序大都功能缺失或不完善，菜单样式单一的问题，我们团队认为这一点定义得还是比较清楚的，并针对这样的问题希望最终设计出一个功能齐全，商家种类样式丰富，方便快捷的外卖系统。同时对典型用户和典型场景有较为清晰的描述，我们主要针对在校大学生及位于高校周边的各类饮食商家，能够方便在校学生的饮食生活，节约他们的订餐时间，而且大学城商家对这样一个订餐系统也有很大的需求。
2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
目前还没有达成我们理想的目标，原计划的功能基本都已经完成，还有一部分功能目前还无法实现，需要以后完善，但我们基本上是按照原计划的时间交付的。由于我们还没有上线我们的软件，所以目前并没有真实的用户，只是我们团队内部模拟了用户和商家，进行软件的正常运转
3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
很遗憾我们的软件目前还没能上线，所以还无法统计用户对重要功能的接受程度，但在团队内部，我们深入考虑了用户需求，一直认为大部分功能都能被用户接受。我们当然是离目标更近了。
4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训： 我们这次选定的软件项目从出发点来看是好的，但并没有在工程量的预期方面下苦功夫，导致我们团队在开发的后期时深刻感受到这次软件项目工作量的庞大，很难在预期时间内完成我们理想的效果。
如果历史重来一遍,我们会尽可能地选择更加适合预期工程时间内能完成的项目，达到我们预期的效果，成功上线我们的项目，也能让现实生活中的用户来尽情使用我们的软件。
计划
1.是否有充足的时间来做计划?
有。
2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们团队会进行多次线下线上的讨论，在计划阶段内也尽可能地综合每个成员的意见，对于实在与整个团队计划相背离的意见会在深刻讨论后摒弃。
3.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
是的，原计划的工作都做完了。
4.有没有发现你做了一些事后看来没必要或没多大价值的事?
截至目前并没有发现此类事件。
5.是否每一项任务都有清楚定义和衡量的交付件?
是的。
6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
不是，在项目的冲刺阶段中曾经出现过服务器崩坏的情况，这是我们团队开发人员在事先没有估计到的，因为我们的项目在开发过程中都是使用模拟的内部用户和商家，并没有与现实用户连接起来，没有想到还没投入实际运行就出现服务器崩坏的情况（可能服务器的搭建过程有些许问题），不过最后开发人员成功解决了这个问题！
7.在计划中有没有留下缓冲区，缓冲区有作用么?
并没有。
8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
留下充足缓冲区。
如果历史重来一遍, 我们会做什么改进?
明确好整个项目的事务，清楚定义并分配每个任务。
资源
1.我们有足够的资源来完成各项任务么？
- 人力资源：依照任务比重对各项任务都分配了不同数量的成员，每项任务所需的人力基本足够。
- 开发资源：我们团队有多个成员都参与过完整的项目开发，拥有类似的开发经验，开发资源足够。
- 设备资源：设备算是比较充足的。
- 时间资源：开发项目时由于其他课程安排的一些考试和实验等，在时间上都比较紧凑，所以留给我们开发的时间其实还是不足的。
2.各项任务所需的时间和其他资源是如何估计的，精度如何？
根据任务量估计的，前期的估计不那么准确，随着项目进行，对整个项目的把握更加深刻，估计的精度也就提高了。
3.测试的时间、人力和软件/硬件资源是否足够？对于那些不需要编程的资源（美工设计/文案）是否低估难度？
资源基本足够，稍微低估了非编程资源的难度。
4.你有没有感觉你做的事情可以让别人来做（更有效率）？
测试和开发可能需要分工更明确一点，有时候边测试边调bug感觉效率很低。
如果历史重来一遍, 我们会做什么改进?
将分工更加细化，合理利用人力资源。
变更管理
1.每个相关的员工都及时知道了变更的消息？
是的。每位成员更新代码后，都会上传至Github，并且在微信群通知大家；每位成员测试时发现接口文档有问题，都会及时更新并告知大家。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能？
团队开会分析整个项目的基本功能，作为必须实现的功能，而有些功能的工程量过大或者实现难度过高，则需要推迟。
3.项目的出口条件(Exit Criteria - 什么叫“做好了”) 有清晰的定义么？
有。
我们的出口条件是能够支持的用户数量达到60以上，以及商家数量达到15以上，能够正常注册，登录，商品查找，下单，订单取消，商品上下架，商家商品活动的推出。
4.对于可能的变更是否能指定应急计划？
可以。因为后端的工作任务一般都会更快完成，这样在前端的工作没完成前，如果存在可能的变更，我们也有较为充足的人力资源和时间。
5.员工是否能有效地处理意料之外的工作请求？
可以。有时临时增加页面的功能或表达效果，大家就一起配合调整。
如果历史重来一遍, 我们会做什么改进?
提前开始进行项目，先完成基础功能，就能留出更多的时间去完成扩展功能，完善我们的项目。
设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
我们的设计工作由前后端的开发人员一起完成，如数据库和接口的设计由刘友滨和陈景山共同完成，页面设计由卢悦盛和金文涛共同完成。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有，整个设计工作都是经过开发人员严密的讨论和相互交流的，在大致确定了整个项目的设计后，对设计的每一个模块我们都很清晰，并没有出现摸棱两可的情况。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
是的，在开发过程中，开发人员就已经利用如Junit等多种测试工具，不管是前端还是后端都有，这些测试工具都有效地解决了我们开发过程中遇到的问题。
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
商品功能产生的Bug最多，因为商品功能在实现上比其他各种功能都要复杂，而且页面的按钮基本上也是最多的，在与用户交互时更容易产生各种意想不到的Bug。
5.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码由各个开发人员自己负责复审的部分，在开发过程中我们严格执行了各种事前约定好的代码规范。
6.如果历史重来一遍, 我们会做什么改进?
更早的让大家在一起进行开发和测试（同一个宿舍），有问题就能及时讨论，及时解决，提高开发效率。
测试/发布
1.团队是否有一个测试计划？为什么没有？
有测试计划。
2.是否进行了正式的验收测试？
是的，针对各项功能都进行了测试
3.团队是否有测试工具来帮助测试？
有，开发过程中有采用多项测试工具，但验收测试则是人工测试。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
软件的效能主要是指并发性和压力测试，这一点由于设备和人力原因并没有测试。最后的运行结果证明了测试工作还是有用的，发现了很多之前没发现的潜在问题。
5.在发布的过程中发现了哪些意外问题？
服务器不稳定，可能会死机。
订单界面点击确认收货可能会再次进行扣款。
二、总结
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
达到了CMMI二级——管理级的程度。
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
萌芽，还要多学习，每个成员都要增强实力。
3.你觉得目前最需要改进的一个方面是什么?
我们团队目前的开发和后续的测试发布效率都没有达到我们预想的效果，所以最需要的就是提高整个团队的运转和工作效率，其次是团队之间的磨合和交流，应该提高交流频率，使开发更加融洽顺畅一点。
三、照片
四、贡献分配
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
| 刘友滨 | 后端 | 23 | 开发 |
| 陈景山 | 后端 | 22 | 开发 |
| 金文涛 | 前端 | 21 | 开发 |
| 卢悦盛 | 前端 | 19 | 开发 |
| 魏建雄 | 测试 | 18 | 测试与博客 |
| 陈浩锋 | 测试 | 17 | 测试与博客 |
