M2 事后诸葛亮
设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
学霸系统，主要面向在校计算机专业的大学生，同时对于其他理工科专业学生同样可以使用本系统。
CodingCook小组负责的部分：用户管理。
主要解决的问题是用户的注册、登陆、各种信息的修改、浏览，保证用户在使用学霸系统时感到简单易用。能够保证系统不会收到SQL注入、脚本攻击等简单攻击手段的影响。
典型用户和典型场景有部分描述。比如 用户注册-登录-查看个人信息-修改个人信息。或者 用户注册-探寻系统漏洞-盗取数据库信息。。
相比于M1，我们在这个阶段的工作是修补M1的漏洞以及残留工作，添加健全的用户管理制度
-
是否有充足的时间来做计划?
和M1相同，我们用来作计划的时间是1个星期。由于在M2的时候，已经对整个项目有了一个整体的概念，哪里需要改动都比较清楚。对于项目的结果页有一个没缺的预期。所以1个星期对于M2来说，时间不算短。
-
团队在计划阶段是如何解决同事们对于计划的不同意见的？
如果有不同的意见，则是最终负责这一块代码的人来决定最终的方案。
如果历史重来一遍, 我们会做什么改进?
充分学习所需的知识，从而不至于花费大量时间去进行摸索式的编程。
计划
-
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
没有。原本计划添加的AJAX动态显示没有实现。对于AJAX不了解，时间较紧张
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有发现。
- 是否每一项任务都有清楚定义和衡量的交付件?
没有。
- 是否项目的整个过程都按照计划进行?
宏观来看，是的。具体来看，比如时间、进度等等，不是。
- 在计划中有没有留下缓冲区，缓冲区有作用么?
没有。个人感觉，缓冲区可以防止由于项目太困难而掉下进度，又可以有时间进行休息或者下一步的计划。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
还未想好。
如果历史重来一遍, 我们会做什么改进?
对软件进行充分的设计，分离各个模块。现在的设计还是耦合严重，牵一发而动全身
资源
- 我们有足够的资源来完成各项任务么?
有吧。老师、同学、图书馆、网上资源。。不过重要的是需要自己去整合，从各种信息中抽取自己需要的信息。
- 各项任务所需的时间和其他资源是如何估计的，精度如何?
结合个人能力、之前经验，再加上一拍脑袋，就估算出来了。精度，不高吧。。。这个和M1一样，归于估计还是不在行
- 用户测试的时间，人力和软件/硬件资源是否足够?
最后整合测试时间比较少，因为开发的时间比较长。而且由于后面数据库、编译大作业等重多少重头大作业，以及考试等等，明显压缩了时间。至于资源，还是可以的。
- 你有没有感到你做的事情可以让别人来做（更有效率）?
会有。毕竟PM对于每个人的能力和兴趣不能完全了解，分配的任务自然会有考虑不周的情况。。。这个依然和M1相同
如果历史重来一遍, 我们会做什么改进?
可能不会有改进吧。。
变更管理
- 每个相关的员工都及时知道了变更的消息?
变更会体现在TFS上。但是M2阶段的变更比较少，变更几乎都应该是自己负责自己的，而且不是变更设计，对其他人影响不不大
- 我们采用了什么办法决定“推迟”和“必须实现”的功能?
PM咨询各个组员，做出决定
- 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有一个直观上的感觉：用户注册时感到提示信息完善及时，同时不会有让人发狂的事情。用户激活账户、重置密码功能的邮件发送快速简单。修改信息简洁功能简洁好用。
- 对于可能的变更是否能制定应急计划?
未遇到这种情况。不知能否制定。。。
- 员工是否能够有效地处理意料之外的工作请求？
可以吧，不太确定。
如果历史重来一遍, 我们会做什么改进?
变更管理，基本上做的很水，对于变更管理的重要性也不太清楚，而且，感觉大家在一起，口头通知很快。。不知会做什么改进。。。和M1相同的
设计/实现
- 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
团队的PM。合适。
- 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有。大家说出自己的想法，明确需求，提出解决方法。
- 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
部分模块做了单元测试。不是TDD，未使用UML。
- 什么功能产生的Bug最多，为什么？
没有产生严重bug的模块
- 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
没有代码复审。
如果历史重来一遍, 我们会做什么改进?
在M1的时候，就说要有编码规范并严格直行，签入时进行代码复审，保证签入质量。但是在M2的时候依然没有执行。。如果历史重来一遍，我们要做的改进，应该就是以上吧。。
测试/发布
- 团队是否有一个测试计划？为什么没有？
基本没有。仍然认为编码最重要，测试留待最后。还有就是时间问题
- 是否进行了正式的验收测试？
没有。
- 团队是否有测试工具来帮助测试？
使用过单元测试。没有其他的测试工具。
- 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
M2阶段只对一些简单模块做了单元测试。软件整体的性能基本是手动进行的。
- 在发布的过程中发现了哪些意外问题？
用于搜索组合前台界面展示两个组任务互换，两个组都不是非常清楚代码的作用，修改的时候掣手掣脚。。还有就是我们组的工程项目类型有选择错了（应该是类库，实际上选成了WIN32控制台），找了好久错误
如果历史重来一遍, 我们会做什么改进?
依然是学习，在软工课之前，至少需要了解什么事测试。另外专门设置测试人员，而不是兼任。测试人员随着开发的进行，编写用例，找出BUG。
以下是M1的补充问题，和我们当时的回答。。
- 对比敏捷的原则, 你觉得你们小组做得最好的是什么?
持续开发，坚持每天写代码。对于需求变更有适应性。
- 什么是在下个阶段 m2 要改进的地方? 越具体越好。
界面：增加js支持，即时反馈用户操作结果，加强用户体验。重写CSS。
功能：增加密码找回、邮箱有效性验证，均需要生成一次性URL，发送邮件。注册、登陆添加验证码，防止脚本攻击
后台：改善代码组织，重构部分代码，优化逻辑
现在看过来，
当时认为在M2阶段要改进的地方，我们确实做了改进，虽然某些部分并不尽如人意，不过确实实现了功能。
改进了M1的哪些问题
- 设计工作做的基本足够，虽然还是耦合严重
- 设想和目标较M1更为清晰，指向更明确
- 整个工程的代码重新组织，更有层次。各自模块的代码放在同一个文件夹。同时前台和后台分成两个项目，利用测试
- M1的界面简陋，没有js动态提示错误。在M2重新设计了CSS样式，增加了js支持（未添加AJAX），提升用户体验
- 增加邮件功能。主要是用户注册激活、密码找回功能
- 添加了验证码。
- 分工明确
没有改进的M1问题
- 测试依然不给力，原因：没有测试的兴趣，或者说，懒。。
- 签入质量不能保证，原因：整个工程在部分同学的电脑上无法跑起来，也就没法保证每次签入必须保证程序运行
- 代码格式，代码复审没有要求，原因：主观上的
- 知识、技术储备不足
另外需要有一组人在一起讨论的相片，晚上补。。
