M1的事后诸葛亮 第二弹

设想和目标

• 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

学霸系统，主要面向在校计算机专业的大学生，同时对于其他理工科专业学生同样可以使用本系统。

CodingCook小组负责的部分：用户管理。

主要解决的问题是用户的注册、登陆、各种信息的修改、浏览，保证用户在使用学霸系统时感到简单易用。

典型用户和典型场景有描述，但不够清晰。且典型用户中，考虑不全，如之前未曾考虑恶意攻击系统的用户。

• 是否有充足的时间来做计划?

我们做计划的时间是1个星期。当时觉得1个星期时间很充裕，现在想来，1个星期时间有些短了。

• 团队在计划阶段是如何解决同事们对于计划的不同意见的？

在M1阶段，基本上同学们之间不存在不同意见。

如果历史重来一遍, 我们会做什么改进?

明确本组的任务，分析典型用户和典型场景，而不是想当然的认为应该这样，应该那样。

 

计划

• 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

除分类外，全部完成。分类未完成，是用于对分类的数据库、数据结构设计清楚，设计未完成。

• 有没有发现你做了一些事后看来没必要或没多大价值的事?

有。比如说回答的获取，实际上可以通过数据源绑定直接显示到页面，无需再额外编码。

• 是否每一项任务都有清楚定义和衡量的交付件?

没有。

• 是否项目的整个过程都按照计划进行?

基本上不是。所谓计划赶不上变化，而且当初的计划也是很不周全。

• 在计划中有没有留下缓冲区，缓冲区有作用么?

没有。个人感觉，缓冲区可以防止由于项目太困难而掉下进度，又可以有时间进行休息或者下一步的计划。

• 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

还未想好。

如果历史重来一遍, 我们会做什么改进?

改进主要应该是在项目的结构设计部分，修正设计中的一些缺陷，去掉写了却没有价值的代码。

 

资源

• 我们有足够的资源来完成各项任务么?

有吧。

• 各项任务所需的时间和其他资源是如何估计的，精度如何?

结合个人能力、之前经验，再加上一拍脑袋，就估算出来了。精度，不高吧

• 用户测试的时间，人力和软件/硬件资源是否足够?

最后整合测试时间比较少，因为开发的时间比较长。

• 你有没有感到你做的事情可以让别人来做（更有效率）?

会有。毕竟PM对于每个人的能力和兴趣不能完全了解，分配的任务自然会有考虑不周的情况。

如果历史重来一遍, 我们会做什么改进?

可能不会有改进吧。。

 

变更管理

• 每个相关的员工都及时知道了变更的消息?

变更会体现在TFS上

• 我们采用了什么办法决定“推迟”和“必须实现”的功能?

PM咨询各个组员，做出决定。

• 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

不清晰。M1阶段，大抵如下，用户可以注册、登陆、退出、修改个人信息即可。

• 对于可能的变更是否能制定应急计划?

未遇到这种青口。不知能否制定。。。

• 员工是否能够有效地处理意料之外的工作请求？

可以吧，不太确定。

如果历史重来一遍, 我们会做什么改进?

变更管理，基本上做的很水，对于变更管理的重要性也不太清楚，而且，感觉大家在一起，口头通知很快。。不知会做什么改进。

 

设计/实现

• 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

团队的PM。合适。

• 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有。大家说出自己的想法，明确需求，提出解决方法。

• 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

没用使用。

• 什么功能产生的Bug最多，为什么？

底层SQL。实现没有想到SQL注入

• 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

没有代码复审。

如果历史重来一遍, 我们会做什么改进?

设计的时候对项目要整体把握，通观全局，而不是着眼于细节。编码时，应有编码规范，并严格执行。签入时，进行代码复审。保证签入的质量

 

测试/发布

• 团队是否有一个测试计划？为什么没有？

基本没有。仍然认为编码最重要，测试留待最后。

• 是否进行了正式的验收测试？

没有。

• 团队是否有测试工具来帮助测试？

使用过单元测试。没有其他的测试工具。

• 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

试过Web负载测试，不过没有成功。根据高工组的负载测试，可以知道自己组的问题（当时数据库连接用的单例。。。）VS自带的Web的测试确实有效，不过要会用才行。。目前已经根据负载测试的结果，对数据库连接使用.NET的连接池。

• 在发布的过程中发现了哪些意外问题？

三个UI组的整合进行得并不顺利，数据库不统一。呃，这个不算是意外吧。。

如果历史重来一遍, 我们会做什么改进?

单元测试，对于复杂的模块要求单元测试。简单功能不强制。学习并使用VS自带的测试工具，

 

补充问题：

• 对比敏捷的原则, 你觉得你们小组做得最好的是什么? 

持续开发，坚持每天写代码。对于需求变更有适应性。

• 什么是在下个阶段 m2 要改进的地方? 越具体越好。 

界面：增加js支持，即时反馈用户操作结果，加强用户体验。重写CSS。

功能：增加密码找回、邮箱有效性验证，均需要生成一次性URL，发送邮件。注册、登陆添加验证码，防止脚本攻击

后台：改善代码组织，重构部分代码，优化逻辑

 

下面上图。。