M1事后分析报告
我们M1阶段的工作终于告一段落,刚开始拿到任务时,许多队员都因为觉得自己能力水平不够,抑或没有参与过这样大的一个项目等原因对于团队项目的工作心存畏惧,但是千里之行始于足下,为了今后能够更好地适应工作需要,我们总是要开始接触这些代码量稍微大一点的任务. 我们小队的PM在跟队员进行过沟通后,决定通过将任务拆分得比较细,比较具体,一步步地提高任务难度等措施,很好地调动了大家的积极性,经过一个月的努力,我们M1阶段的工作终于完成了,这一个月的时间,大家都付出了很多,也有了很多的收获.M1阶段的软件开发周期到 目前为止已经结束了,但是我们还有很多的事后工作要完成.其中非常重要的一项就是我们需要将组员召集起来开一个会,对M1阶段的开发工作进行一次总结回顾,也就是所谓的Retrospect.一味地完成工作,不进行反思只会导致问题不断地发生而得不到解决.通过回顾上一个阶段的工作,我们总结了M1阶段,我们团队有哪些做得比较好的东西,值得在今后继续发扬,有哪些不足的地方需要在今后改正.在会议上,大家都热情高涨,各抒己见,会议的氛围非常热烈.下面 是我们的会议总结.
团员合照：
设想和目标：
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件是用来为广大的计算机爱好者提供一个网上的知识搜索和问答交流平台，我们小组的任务是其界面的构建。关于定义这一块，我们认为还是比较清楚的，关于几个小组分工的边界性问题，在碰头讨论之后也得到了解决。对于我们软件的典型用户为：与计算机相关专业的学生以及计算机爱好者；典型场景：搜索和提问。
2. 是否有充足的时间来做计划?
由于小组成员平时的课业任务都比较紧，所以每次都是在开上一次的总结会议时，伴随进行计划的制定，导致用来做计划的时间并不是很多，进而造成计划会在之后的工作中临时变更，有一种计划赶不上变化之感。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
团队在制定计划时，采取共同商议，取其最优的方法。集思广益，将原本不是很完美的几个方法取长补短，得到最优方案。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
由于我们的工作还没有最终的完成，所以用户量、用户对重要功能的接受程度等还没有一个数据。但在大家的一致的努力下，我们的一轮迭代顺利完成了，我们离目标更近了一步。如果我们能从新来过，我们会将初始时的分工设计和预期定位做的更加的明确，为后续的工作的有序高效的进行打下基础。
计划
1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
我们原计划中的工作可以说是大部分都已完成，但由于我们许多组员都是第一次参与如此正式的一项团队工作，所以难免在制定计划时过分的估计了自己的执行能力，导致一部分的计划内容超出了在有效时间内我们的完成工力。没有做完的工作我们会尽可能的融入到二轮迭代中去完成，这也需要我们提升自己在二轮迭代中的工作效率。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
有，比如说在界面美化时，开始要使用表格布局，但后来觉得不够灵活，改用了框架加DIV布局。
3. 是否每一项任务都有清楚定义和衡量的交付件?
每一项任务的定义都还是比较清晰的，衡量的交付件也比较清楚。
4. 在计划中有没有留下缓冲区，缓冲区有作用么?
我们在制定计划时就有考虑到缓冲区这个问题，缓冲区的作用就是给自己的工作留下一定的回旋余地，不至于发生一环卡壳、全团崩掉的结局。
5. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将缓冲区的定义变得更加的具体和明确，加班也会在考虑工程量的情况下适当做出调整。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们在一轮迭代中初步的磨合了团队，学会了如何合理地进行分工，以及对时间的合理利用。如果我们从头再来，我们一定会在大的框架上更好地安排额我们的任务日程，更科学地进行分工以及缓冲区的设定，让我们的工作变得更加的有序和高效。
资源
1. 我们有足够的资源来完成各项任务么?
我们的资源并不是很足够的，我们的需要的数据库信息就不能及时到位等等。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
这是有我们团队在制定计划时共同决定的，精度在工作中看来还不错。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
由于我们仅仅进行了一轮迭代，所以还没有进行很正式的测试。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
这就提到了人与其工作的适应性问题，其实这个问题在生活中的各行各业都有存在，我们团队也不例外，所以我们也在努力地进行探索，以求使我们的工作效率变得更高。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验无非是在工作之前，在制定计划时，就要考虑到工作和资源之间是否对等。如果再来一次，我们就会更好地考虑这方面的事宜，不要等到计划制定下来了，才发现所需的资源还没有到位。
变更管理
1.每个相关的员工都及时知道了变更的消息?
因为我们每都会开一次会议，有变更PM会及时告知。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们会根据功能的重要性决定“推迟”和“必须实现”的功能。同时也会考虑到项目的截止时间，尽量将比较耗时的功能尽早完成。
3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有清晰的定义。功能必须完善并且通过各种测试。
4.对于可能的变更是否能制定应急计划?
有，紧急变更时会召开紧急会议。
5. 员工是否能够有效地处理意料之外的工作请求？
个别员工编程能力不是很强，对于这种意料之外的工作请求没有经验。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们认为在开发过程中制定计划要更合理，尽量减少变更，避免员工做无用功；同时，当出现变更时，要及时与组员进行沟通。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
我们是在项目开始之前，是由PM黄健锟同学来完成的,是合适的时间和合适的人。
2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有，我们小组开始分配任务时没有明确每个人的具体任务，认为是能者多劳，结果导致任务没有按期完成，我们团队通过每天开一次小的例会明确每个人的任务。
3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
团队运用了单元测试，其他的都是人工测试。这些测试有效，发现了一些bug。
4.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
在搜索功能方面Bug多，主要是因为对于学长的代码没有理解全面。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由于时间问题没有代码复审。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计时要切合实际不要好高骛远，选择能力范围之内的功能来实现。同时任务尽早开始，不要拖到最后，以便有时间代码复审，保证代码质量。
测试/发布
1.团队是否有一个测试计划？为什么没有？
没有系统的测试计划，主要是编程完成后人工测试功能是否实现。因为不会那些比较专业的测试方法，并且时间比较紧。
2.是否进行了正式的验收测试？
没有。
3.团队是否有测试工具来帮助测试？
只用过VS的单元测试。
4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
目前还没有进行专业的软件效能测试，只是测试了软件的执行时间，以此来判断软件的效能。作用不是很大，应该使用一些专业的测试工具。
5. 在发布的过程中发现了哪些意外问题？
由于没有跟数据库组沟通好导致数据库中的资源无法查看。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
要有完整的测试计划，学会一些专业负载测试，如果不会的话要请教别的组员，好像别的组展示时用过云测试等，可以向他们请教而不是不做。
对比敏捷的原则, 你觉得你们小组做得最好的是什么?
我们小组做的最好的地方就是相互沟通，由于我们都是六班和七班的同学，住的比较近，所以能够做到每天开一次例会，这样保证了我们小组成员相互沟通，使得我们的项目进行的更加有效率。
什么是在下个阶段 M2 要改进的地方?
