一、设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的网页是解决的是如何做到上传图片识别图中表达式然后进行计算输出的一个网页版简单计算器的问题； 定义的很清楚；
在本团队的需求分析书中有对典型用户和典型场景有清晰的描述；2.是否有充足的时间来做计划?
老师给了我们三周的时间，是有比较充分的时间来做计划的
3.团队在计划阶段是如何解决同事们对于计划的不同意见的？
组长约大家聚在一起讨论、分析、解决
4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训就是：不要放弃，只要坚持就一定会成功；
如果重来一遍：如果有重来的机会，我们一定会选择做网页版本的计算器，不是一开是定稿的微信小程序，我们连相关知识都没有接触过，就去做这个微信小程序，没有金刚钻别揽瓷器活！二、计划
1.你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有都做完，但大部分做完了；因为对ocr部分功能不了解，没有能够完全实现功能，需要时间来完善。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有的，本来我们组是设定做微信小程序，但做到一半发现是在是力所不及，于是放弃，改为网页实现
3. 是否每一项任务都有清楚定义和衡量的交付件?
没有每项任务都有清除的定义和衡量的交付文件，我们都是分配好了就各自做各自的任务，大家完成后会整合成一份完全体
4. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
没有完全按照计划来进行，我们在选定了要做手写识别简单计算器APP的时候，我们是制定好了是基于微信小程序来开发的计划的，但是后来我们发现这个小程序以我们的能力难以实现，加之没有接触过相关知识，所以放弃了这个最原先的计划，转而讨论另辟蹊径，我们最后选择了网页来实现，因此制定了另一套计划来遵循；
风险嘛倒是没有，毕竟我们的选题蛮简单的，实际涉及到的知识面不多，实现的功能简单，因此就没有像别的团队一样遇到的问题多。5. 在计划中有没有留下缓冲区，缓冲区有作用么?
缓冲区是什么？很抱歉貌似我们没有留下缓冲区，好像是随意做，也没有催组员快些做什么之类的，更没有说加班这种说法，随意。
6. 将来的计划会做什么修改？
就是把网页的输入输出端美化一下就更好了
7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
遇到无法解决或者力所不及的事情，在撞了南墙的情况下一定要审视当下要不要做出改变
三、资源
1.我们有足够的资源来完成各项任务么?
只能这样讲，有，但不够，我们拥有一位熟练的java组员，他负责代码部分，也拥有界面设计的组员，拥有修图能力的组员，缺少相关的测试经验人员，其实网上的学习资源很多，但是我们却没有安排好学习任务，这蛮失败的。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
这个就比较的模棱两可了，因为老师给的时间说多不多，说少不少，每个人的分配的任务每个人都会做，但不会说是规定他们要什么时候完成，或者说必须在那天之前提交给组长，反正时间各自自由分配，总之就只要在规定的时间内完成就行。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
我们上台展示了相应的功能，但还是差了一个上传图片后能够接收图片的服务器，就差这个没有搭建，只能说基本完善，我们也没有进行真枪实弹的用户测试
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
有的，比如有个组员不是很了解word文档的操作，但是他分配到的任务里面要接触到，而我比较熟悉，于是他就交给我来做，他再去把剩余的做完，于是这样就很效率。
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
多交流，多沟通，有问题提出来，大家一起解决。
四、变更管理
1.每个相关的员工都及时知道了变更的消息?
很及时的知道的，一有什么变更就会在群里@相关组员或者发公告提醒。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
推迟：一些部分，比如输入输出界面的设计，就不是那么的核心重要，对整个项目分配时间上来说可以做推迟处理
必须实现:这个部分一定是核心、是重要的部分，比如实现 上传图片后识别图片内表达式 的代码、或是 识别表达式后进行加减乘除计算的代码 这些都要必须实现的，我们对于这些东西都是及时跟进相关组员、督促其完成或提前完成。3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有的，定义就是：该项目能够达到《需求报告》中的要求
4.对于可能的变更是否能制定应急计划？
没有想过这方面，我们的选题相对别的选题较为简单，不用设计太多知识面，因此没有指定应急计划
5. 成员是否能够有效地处理意料之外的任务请求？
有的，如果说老师有什么新的要求，我们大家都会在一起讨论并统一意见作出相应的计划修改或者代码改善。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
一定要统一、统一、统一代码的书写格式啊！！！
五、设计/实现
1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
界面的设计工作在一开始没有做，他是由组长来做的，设计工作是在代码完成得差不多的时候才设计完成的，而如何实现核心功能，也就是项目整体设计是由张韵弢组员完成，该组员知识面广，比其他成员要优秀，综上，对于设计来说，都是合适的。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
没有，按照计划一步步走的，团队里面没有出现分歧，挺统一的。
3.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
1.在上传图片进行识别图片内表达式的功能中，如果图片内的字体不是印刷体或者说有污渍，就会识别不出来，或者是不准确
2.识别工作完成后，进行的四则运算中，乘号*如果和括号（）挨着，则会在输出的时候乘号会变成“米”字显示； 因为可能是进行测试的时候测试的样本太少导致没有遇到这些问题4.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
我们一开始就按照 课本 上的提议，也就是首行缩进一个tab这类的规则来制定的代码规范，为的是方便日后整合
5.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
多测试，多想想可能出现的情况，多找bug，这样就能使产品更完美
六.测试/发布
1. 团队是否有一个测试计划？为什么没有？
有测试的计划啊，是交给徐建民、冯一来进行的
2. 是否进行了正式的验收测试？
是的，最后运行了好几遍，测试了好几遍才敲定初步完成的。
3. 团队是否有测试工具来帮助测试？
测试工具就是 手动测试了啊（认真脸）
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
当然是人工手动测量并跟踪软件的效能的啦；这些测试蛮有用的，也找出了一个Bug
5.在发布的过程中发现了哪些意外问题？
没有发现，正常进行发布
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
应该使用专业的测试工具来测试，那样效率会高些，精确度也高些，毕竟人工手动测试存在着缺陷
七、总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
二级没错了
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
应该是萌芽阶段，虽说有个别组员个人能力突出，但大家还是普遍存在着个人能力不足，还是要多学习，每个成员都要提升自己。
3.你觉得目前最需要改进的一个方面是什么?
在Alpha版本的冲刺阶段的时候，交流太少，都是各做各的，出现了问题也不提出，不沟通，导致最后上台展示的时候演示得手忙脚乱。
所以 最最最需要改进的地方就是：团队组员之间应多交流，多沟通，这样可以提高项目的效率，按时按量完成