事后诸葛亮分析
事后诸葛亮分析
一、团队讨论照片
二、设想与目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们做的软件主要是想为在广东工业大学生活的广大师生们提供一个了解身边流浪动物的渠道，增加一些人文关怀。定义的比较清楚，前面的博客中也对典型用户和场景有较为清晰的描述。
2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
招新系统基本功能基本都实现了，原计划的功能除了一开始设想的二级评论，历史记录我们认为较为复杂且意义不大舍弃了以外，其他计划的功能基本都实现了。后端所有功能均按时交付，前端小程序的页面代码也按时交付，但由于前端接口对接部分的逻辑代码有些问题，所以正式交付要比预期晚。
由于小程序未正式上线，所以用户数量没有达到预期。
3.和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高？
团队软件工程的质量提高，代码质量，前后端之间的交流，功能特性方面有所提高。
4.用户量, 用户对重要功能的接受程度和我们事先的预想一致么?
用户量没有达到预期，用户的接受程度与想象中大致相同。
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
前期我们低估了项目的难度，导致有部分本来想完成的功能半途而废了，而且我们前后端开发的组员在前期的交流也不够多，后面直接影响了前后端对接的效率，比如光是条件查询动物这个接口我就改了三四次。
三、计划
1. 是否有充足的时间来做计划?
由于我们现在在大三上，很多同学都在忙自己的事情，所以做的很多计划并不完美，但相对来说还是有个比较合理的规划的。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
主要在宿舍内或者微信群讨论，经过多方面的意见交流最终得出一个统一的解决方案。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我本人是负责所有博客和项目的后端关于动物和部分申请模块的代码编写。可以说我计划的工作基本都完成了。
4. 是否项目的整个过程都按照计划进行，项目出了什么意外？
总体来说，项目的进行还是比较顺利的，除了现在小程序部署那边还有点小问题，其他接口基本都是正常的。
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
有，缓冲区主要是为了应对突发事件和短时间内解决不了的BUG。比如在前后端对接的时候有一个条件查询动物的接口在后端接口测试工具测试时功能正常，但前端请求的时候会报空指针异常，通过缓冲区负责前端的同学询问了前辈解决方案并顺利解决了问题。
6. 将来的计划会做什么修改？
虽然下周马上又要面临两场考试，但还是计划大家都尽量贡献一点时间，把项目最后正式上线的问题解决。
7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在团队合作项目开发的时候往往会遇到很多意料之外的问题，因为计划永远赶不上变化。如果再来一次，身为组长的我一定会更加合理地安排任务和调动组员的积极性，将任务更早地完成，以避免出现临近截止日期问题却无法解决的现象。
四、资源
1. 我们有足够的资源来完成各项任务么?
由于我们团队仅有一名学习前端开发的同学，所以前端的任务相对来说比较重，也没有很好的考虑美工之类的问题。后端的三位同学及时完成了开发任务，资源比较充足。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
我们根据各项任务实现的难易程度来分配所需时间和其他资源，精度还算比较高，但也有诸如低级错误，难以被发现的bug等导致的偏差。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间和资源是足够的。关于美工我们确实也没有考虑太多，主要是前端人手不足且我们优先把基本功能完成再考虑美工这些。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
可能会，我们组内有代码和逻辑能力比我更强的同学，或许可以更好更快地完成我需要负责的部分，但合理分工我觉得还是很有必要的。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
如果重来，我们会将更多精力花在前端上，但也需要更高的学习成本。
五、变更管理
1. 每个相关的成员都及时知道了变更的消息?
是的，在变更消息后我们都会在线下或者群里及时通知组员。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据我们在开工之前讨论好的这个系统必须要有的功能，以及锦上添花的功能。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有，所有接口均能正常测试。
4. 对于可能的变更是否能制定应急计划?
在确定变更前我们都会讨论，并决定相应解决方案
5. 成员是否能够有效地处理意料之外的任务请求？
能，遇到问题小组成员都会积极配合并解决。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
如果重来，我们可能会在开工前将想要实现的功能的可行性考虑的更周到，而不是临时发现问题后再半途而废。
六、设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作主要是在项目开工前完成，具体功能由大家讨论决定，确定后首先由负责原型设计的同学设计出可供前端参考的模型，负责后端的同学再根据原型建立数据库表等。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，主要是通过讨论解决。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
我们用到了单元测试工具；有效，可以更方便地检验我们的接口是否有误以及方便调试。
4.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审由我们的开发人员负责，基本执行了代码规范。
七、测试/发布
1. 团队是否有一个测试计划？为什么没有？
有测试计划，在开发和接口对接过程中都会进行相关测试。
2. 是否进行了正式的验收测试？
是的，功能编写完毕后都会进行测试。
3. 团队是否有测试工具来帮助测试？
有，使用Swagger来测试接口。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们将各个模块的测试进行分配并测试，测试肯定是有用的，能让我们发现编写的功能里逻辑的问题，比如这个参数有没有正确传进方法中，那个参数类型是否匹配。改进的话，应该要进行更多测试。
5. 在发布的过程中发现了哪些意外问题？
除了前端小程序部分还未正式上线，并没有发现其他意外问题。
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
通过我们自己输入参数进行测试效率太低，如果重来的话我们会学习使用测试工具。
八、团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
我们根据每位同学擅长的方向来安排任务，擅长前端的同学负责前端模块，擅长后端的同学负责后端模块。每位同学都负责自己最擅长的领域，做到了人尽其才。
2. 团队成员之间有互相帮助么？
有，遇到问题特别是前后端对接方面的问题我们都会第一时间讨论并解决。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们会先讨论出一个大家都满意的结果。
九、总结
1. 觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
二级
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
萌芽，我们的开发经验还远远不够，自身也存在很多问题，希望在以后能有所成长吧。
3. 你觉得目前最需要改进的一个方面是什么?
提高解决突发问题和统筹兼顾的能力。
4、你觉得目前最需要改进的一个方面是什么?
每个人的编码水平
5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
我认为做的最好的是前后端分离的原则，前后端各司其职并仅通过接口测试
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
1、代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
应该更频繁地commit，最好每次都能细化至某个具体的功能。代码复审和规范的质量需要多参考别人的项目。
2、整个程序的架构如何具体提高？
这个我们也不太清楚
3、其它软件工具的应用，应该如何提高？
应该去学习更多测试工具的使用
| 名字 | 角色 | 团队贡献分 | 可验证的贡献 |
|---|---|---|---|
| 陈卓鸿 | 后台开发，数据库设计 | 9 | 后台个人用户、权限认证相关规则，提示功能编写 |
| 黄润波 | 测试 | 7 | 对已编写功能测试 |
| 林郁达 | 原型和数据库设计 | 8 | 设计出可供参考的项目原型，根据项目的实际情况改进了数据库 |
| 王春锦 | 前端开发 | 9 | 所有小程序页面和负责与接口交互的逻辑代码的编写 |
| 张超榆 | 后台开发 | 8 | 后台申请，评论功能的编写 |
| 张栩 | 后台开发，博客撰写 | 9 | 后台所有关于动物模块和部分涉及申请功能的编写，博客的编写 |
