事后诸葛亮分析报告
一、总结
设想与目标
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件为辅导员与学生的交流提供便利，提高辅导员的工作效率，方便学生联系辅导员的微信小程序，定义得很清楚。典型用户和典型场景在之前的博客中已清晰提及。
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
针对于计划书中的功能大部分都有实现，但是由于技术问题导致项目尚未完成，用户数量没有达到预估的数量。
3、和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
事实上，工程的质量并没有提高，团队合作的优势得到没有充分发挥，项目完成度不太理想。
4、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
由于项目未能上线，无法得到用户量数据，等我们团队将最后一些问题解决并把项目上线后，我相信用户接受程度应该比较高。我们离目标已经不远了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
这次团队开发的过程中，人员工作分配不是特别合理。前期太拖沓，工作全堆到中后期去做，导致比较赶时间。每个人的分工也不够明确，负责的模块数量不合理。如果能重来一遍，我们一定会在整个项目开始前明确项目的全局内容，合理分配工作模块。
计划
1、是否有充足的时间来做计划?
有十分充足的时间来准备我们的计划
2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
及时沟通，每个人都会发表自己的意见，然后团队投票采取较好的计划
3、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
并没有做完。由于技术原因，后台数据暂时不能和前端交互
4、有没有发现你做了一些事后看来没必要或没多大价值的事?
有，在决定做微信小程序后，后台人员就去网上学习小程序后台内容。然而实际上只需用原来学过的知识就可以完成，浪费了不少时间
5、是否每一项任务都有清楚定义和衡量的交付件?
是的
6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
不是，意外和风险主要是出现在后台数据无法与前端交互，因为我们团队是第一次接触小程序开发，对于项目部署方面不太熟悉，导致没能完成
7、在计划中有没有留下缓冲区，缓冲区有作用么?
有，留出一段时间进行bug排查，但是没用上，因为项目还没完成
8、将来的计划会做什么修改？（例如：缓冲区的定义，加班）
更加细致地给每个人划分工作模块，督促成员完成各自的工作。合理安排时间，预留更多的缓冲区
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了如何进行团队合作，如果历史重来一遍，预留更多的缓冲区
资源
1、我们有足够的资源来完成各项任务么?
- 人力资源：团队成员有5名，分别负责前端开发、后端开发、UI界面设计、项目总体架构，人数充足
- 开发资源：都是在网上搜资料边学习边开发
- 设备资源：人手一台电脑
- 时间资源：充足
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
按照每个人的能力大概估计，精度一般
3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
资源足够，并没有低估美工设计/文案的难度
4、你有没有感到你做的事情可以让别人来做（更有效率）?
没有，每个人都是做自己擅长的方面
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
应该在项目开始前提前想好所需的资源，这样就不会占用开发阶段的时间。
变更管理
1、每个相关的员工都及时知道了变更的消息?
是的
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
开会讨论
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有
4、对于可能的变更是否能制定应急计划?
能，结合git的使用变更计划
5、员工是否能够有效地处理意料之外的工作请求？
能
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了如何处理意料之外的计划，兵来将挡水来土掩。
设计/实现
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在项目开始前完成，由整个团队共同讨论得出。是合适的数据，合适的人
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
碰到过，对于界面UI的设计不清晰，通过开会讨论解决
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
没有运用单元测试，TDD，UML等其他工具
4、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
预约功能产生的Bug最多，因为这是项目中最核心的功能，实现难度较大。由于团队的编程经验都不多，对于类似的情况无法预料
5、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
主要是测试各部分功能是否可以正常运作，在修改bug的时候严格执行了代码规范
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在开发过程中，提高了编程能力和设计思维，学会了团队合作。如果能重来一次，一定会把每个人的能力充分发挥
测试/发布
1、团队是否有一个测试计划？为什么没有？
有测试计划
2、是否进行了正式的验收测试？
没有进行正式的验收测试，我们进行了简单的测试，而且小程序测试有点复杂，需要通过大量审核
3、团队是否有测试工具来帮助测试？
很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
微信开发者测试工具
4、团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
通过微信开发者测试工具，没有压力测试，有用，暂时无改进
5、在发布的过程中发现了哪些意外问题？
项目未能实现后台数据与前端交互，尚未发布
我们学到了什么? 如果重来一遍, 我们会做什么改进?
学会了如何使用测试工具
团队的角色，管理，合作
1、团队的每个角色是如何确定的，是不是人尽其才？
根据每个人擅长的方面确定角色，是人尽其才
2、团队成员之间有互相帮助么？
有
3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？
及时进行开会讨论
总结:
1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
属于CMMI二级
2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
萌芽，因为是编程小白凑出来的队伍
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?
这是我们团队第一个里程碑，希望日后能越来越好
4、你觉得目前最需要改进的一个方面是什么?
每个人的开发能力
5、对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
前、后端开发完全分离，只通过接口进行交互
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
1、代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
使用github、码云等托管代码。努力学习，规范代码。
2、整个程序的架构如何具体提高？
更加具体的分析项目各个部分
3、其它软件工具的应用，应该如何提高？
无
4、项目管理有哪些具体的提高？
进度和质量需要提高
5、项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
项目未发布，无法跟踪用户数据
6、项目文档的质量如何提高？
努力学习如何写项目文档
7、对于人的领导和管理， 有什么具体可以改进的地方？
应该选举一个有大局观并且懂管理项目的人
二、团队讨论的照片
三、团队成员在Alpha阶段的角色和具体贡献
| 成员 | 角色 | 团队贡献分（10分制） |
|---|---|---|
| 黄俊鸿 | 前端开发 | 8 |
| 李金锋 | 打杂 | 4 |
| 李文锋 | 文档 | 6 |
| 欧振浩 | UI、架构 | 5 |
| 欧柱轩 | 后台开发 | 7 |
