M2尸检报告
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件的首要目的，是帮助用户记忆单词。因为我们认为，用户学英语的首要需求就是背单词。所以我们就是要解决如何帮助用户有计划的进行单词记忆训练。
典型的用户和场景就是划分了不同的考试需求。英语四六级、TOEFL、GRE等几类考生。
2. 是否有充足的时间来做计划?
是有一定的时间，我们大概花了有三天来进行这个计划，因为拿到了一个已经完成的软件。所以我们初步是试用找出缺点，然后进行功能上的优化和改进。在M1的基础上，我们对于这个项目有了更为实际和深刻的了解，将项目时间充分安排了。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
一开始队长提出了很多”牛逼”的技术,很多只有他懂,我们完全没有技术能力.所以,在讨论的很多时候我们都只能听.但是他发现我们没办法帮助他完成,所以,他就放弃了那些设想,然后我们回到了讨论基础功能的改进上，然后队长（技术大牛）决定了我们的方向，我们都表示赞同。在M2的实施过程中，我们权衡利弊，听取每一个队员的想法，将想法汇总，排除了一些看似很牛但是对于用户而言是鸡肋的功能，同时将“背单词”的这一基本功能强化，这一切都是我们团队不同意见的整合。
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
很多没有做完。原因有以下一些。
1，任务分给的那个人，每次都无法完成他的任务，在PM询问他的时候，他总之“谎称”已经完成，但是无法整合到最后的代码中。无法“真正”的拿出可运行的代码。
2，大牛对原来软件的框架十分不满意，所以，开始从框架开始写起，但是其他的人的工作在此时没有办法继续进行下去。契约编程没有实现。在他框架构建完成 后，其他人无法明白，无法继续后面的工作，只好由大牛继续完成下面的细节。但是大牛又老是不在宿舍，打电话也不接，无法有效的跟踪他的任务进度，所以任务 进度就变得飘忽不定。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
完全重新构建软件框架。
3. 是否每一项任务都有清楚定义和衡量的交付件?
没 有,这个是一个很大的问题.比如,学习单元测试.但是没有标明到底怎么样算是学习了，这样的话就没办法评估。应该是比如学习单元测试，一定要看你最后学习 的成果，比如今天给已经写好的类完成了至少五个单元测试.那么就好了。看来，有一个清楚的定义和衡量的交付件是十分必须的!!
4. 是否项目的整个过程都按照计划进行?
没有，因为之前说的原因，在很多时候都没有按照进度进行，泪目!!!!!!!
5. 在计划中有没有留下缓冲区，缓冲区有作用么?
没有留下缓冲区，完全不懂这个概念，没有留下给软件稳定的时间。而且，以我们的情况，就算最后留出了缓存区，也会被浪费掉。
6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
加班加班加班加班加班加班加班加班加班加班加班加班!!!!!!!!
资源
1. 我们有足够的资源来完成各项任务么?
有
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
学习了邹老师那节课后，我们学会不是一拍脑袋就决定一个项目完成的截止时间，对于每一个独立的任务，我们都是三拍脑袋才决定的。
3. 用户测试的时间，人力和软件/硬件资源是否足够?
我感觉不不够，很不够。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
PM如果队长来做的话，可能会更好一点。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
不是，那些搞后台的人，都不知道我们前台变了需求，那些画前台UI的人根本不关心我们项目逻辑进行到什么地方了。一直提一些完全无理的要求。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
看大神的眼色，我们发现，没有大神我们的项目就完了。所以他决定不做了，那就真的做不了了。必须实现也是看他和PM商量后决定的。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
好像没有。
4. 对于可能的变更是否能制定应急计划?
没有。
5. 员工是否能够有效地处理意料之外的工作请求？
必须不听话啊，大家都忙自己的事情啊，我觉得，如果一周只有软工课的话，大家或许会更加用心。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
在前一周,由队长完成。是合适的时间，稍微晚了一点。人必须是合适的人，因为设计的人必须是大牛才行。要不设计出来一坨屎，别人怎么写?
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有， 因为有时候很难决定这个是不是需要这个接口。有时候我们不知道“单词类”、“课程类”、“测试类”等等到底设计成什么样比较好。因为本来关系比较乱，而且 涉及到之后实现的问题。所以大牛就召集大家开了个会。但是除了PM和大牛，大家纷纷表示这个东西自己不熟悉，所以最后也没有给出任何有创造性的意见，所 以，遇到这样的问题，都是PM和大牛自己决定了。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
没用过，不知道有没有用。
4. 什么功能产生的Bug最多，为什么？
Course类的Bug最多，原因是这个时候我们已经没有时间自己写Course类了，所以把旧的版本的此类直接拿过来用，但是由于跟我们的框架不是十分兼容，所以，一编译就会瞎。只好不停的改，改到哭。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
因为没有人感质疑大牛的代码，起初PM进行了简单的复审，遇到了一个自己没见过的用法，大牛来讲解了以后，PM收获了很多，但是以后再也没有问过了。也没有进行任何有意义的复审。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
没有测试计划，之前是有，但是当发现我们无法在期限内交工后，PM就把所有的测试人员拉过来搞开发。也放弃了测试。
2. 是否进行了正式的验收测试？
验收测试是什么？能吃么？我们能用就行了，好像就是这样。
3. 团队是否有测试工具来帮助测试？
没有。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
5. 在发布的过程中发现了哪些意外问题？
在发布过程中，很多人提供了很多有意的东西，然后在有一些网站，比如百度贴吧第一大吧——“李毅吧”，删除了我们的软件发不贴，可能是该论坛禁止发布有关广告帖的原因吧，或者是禁止外链。
