Beta阶段敏捷冲刺总结
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
在最开始的时候我们就是为了解决集美大学计算机工程学院网页没有搜索引擎的问题。因为没有搜索引擎，在搜索内容时需要根据查找信息所属的不同区域来查找，这个过程非常不方便用户信息的得取，也很容易找不到相关信息。我们在Alpha阶段最简单的实现了计算机可以查找信息，并且相应的进行显示，但是因为没有部署到服务器上，没办法发布出去，不能进行普及，所以Beta阶段我们主要解决服务器部署的问题，然后再针对一些小细节来方便用户体验，提高用户使用的满意度。
关于定义在前期的时候就已经清晰定义了，所以整个设计过程中还是很清楚的。典型的用户和典型的场景有在需求说明书中详细给出，主要针对的一直是普通用户，可以是老师也可以是学生，更可以是想要报考集美大学了解计算机学院的人群。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)
我们基本目标都达成了，但是没有把Beta阶段所有的目标都实现。在Beta阶段我们计划了如下：
- 新增其他学院的搜索引擎
- 实现网站的定时爬取以及es的自动同步
- 主界面设置最新通知播报栏
- 新增按时间筛选信息功能
- 扩大使用范围至移动端
- 将项目部署到服务器
但是最终我们的版本里更改了主界面设置最新通知播报栏，从原先设想的多个通知栏变成一个最重要的通知栏，而新增按时间筛选信息功能因为时间的缘故最终没有去实现它。虽然少了这一部分，但是整个的主要部分都完成了。在用户调查阶段参与测试的用户79名，相信不久的将来会有更多人使用的。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
整体质量效率都有提高。之前在各个功能的实现上都走了很多弯路，然而现在实现的很多功能都可以在预期时间内完成，而且因为期末大家时间比较有限，有几次队员没办法都到，虽然人数减少了，但是项目的进展并没有影响。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
接受程度比我们预计的要高一点，因为最开始做的时候主要突破在界面以及细节完善上，但是只能凭借我们自己的主观感受来设计。但是后来我们发现，以前针对一个学院的数据时还是可以做到搜索比较精准的，等数据量扩大后，精准度上有所减少，不如第一阶段的精确度了，这个应该是关键字的索引那边需要更改，那个关键字精确的方法不适应于较大数据量的情况。
5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
整个开发下来，我觉得很多的设想需要有延续性，不能看得太眼前，不然可能未来需要动基层建设。如果历史从来一遍，我觉得我们可以在前期的时候除了关注点在界面设计上，应该在关键字索引的地方多下点功夫，应该选择一个即使数据量比较大但也同样适用的方法来实现。
计划
1. 是否有充足的时间来做计划?
是的，预留了一个半天时间专门用来准备beta阶段的冲刺计划。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
和Alpha阶段一样我们，当产生分歧的时候我们首先会进行讨论，最后得出一个大家都满意的方案，当然每个人都需要做出一定的妥协。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
beta阶段的计划都完成了。这一次我们预留的时间相当充足，最后距离截止时间甚至还有一周。冲刺过程中对计划有进行一定的调整，不过偏差不大。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
原定计划中有一项按时间排序功能，在着手准备的时候发现，主流的搜索引擎有按时间范围筛选，但没有按照时间排序的，实际运用上来说按时间排序也没有什么实际意义。在这一功能的讨论上，浪费了我们一些时间，最后删除了这一功能。所以在做功能的规划的时候，还是要再多调研一下。
5. 是否每一项任务都有清楚定义和衡量的交付件?
对比alpha阶段，这一次我们有着清楚的定义，但放弃了过于高标准的定义，追求功能的基本实现。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
本阶段顺利的按照计划进行，最后提前一周完成冲刺。唯一的意外是域名的申请备案，到用户调查结束都没有审批下来，好在影响不大。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
留下一周的缓冲区，但没有使用上，原因是用户调研结果不需要我们做出过多的更改。
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
alpha阶段，我们计划对任务量进行压缩，留下充足的缓冲空间，这一点我们在beta阶段完成的很好了。如果还需要对产品进行迭代，我们可以保持现阶段的节奏进行。
9. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
beta阶段对比alpha阶段来说，更顺利，包括技术和沟通上都有了很大的进步。历史再来一遍的话，我们也许不能做到更好了。
资源
1. 我们有足够的资源来完成各项任务么?
alpha阶段已经有基础了，而Beta阶段新增的功能网络上也有一些参考资料。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
根据个人开发阶段每个人所需要的时间进行估计，精度较为准确。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试时间相对Aplpha阶段较为足够。对于缺少笔记本电脑的成员，在除了一定要全体面对面沟通的情况下，我们采取了网上群视频通话的方式进行共同开发。对于其他资源，美工设计方面在Beta阶段无需改进，而对于搜索引擎来说文案并不需要。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
Alpha阶段虽然是混着做的，但还是有一些大致的成员分工，所以在Beta方面也是考虑了Alpha阶段的任务安排情况来进行成员分工，大家都是做自己较为擅长、Alpha阶段有经验的任务，所以还是很合理的。
5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
因为计划新增的功能较多且后阶段临近考试，所以提前完成了项目，计划新增的功能中有些需要大量的时间研究且难度较高，最后未能完成。计划时考虑时间和完成难度，做一个更合理的优化计划。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
alpha阶段的时候因为没有太多的使用码云来同步代码，所以在beta阶段的时候我们有专门注意代码的上传，每次冲刺完后都有在码云上传相关代码。同时也有在用qq传输，或者u盘。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
必须实现的肯定是不能影响主要程序使用的地方，比如搜索引擎必须能搜索到内容，结果不能错。推迟的内容是分词器能不能自行控制。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
有清晰的定义，能用搜索引擎来搜到我们学院的内容，有两个页面，一个是搜索引擎的干净整洁首页面，一个是搜索到内容的显示页面，第二个页面能准确搜索到用户需要的内容，并且进行一个最优排序。
4. 对于可能的变更是否能制定应急计划?
能，刚开始本来是定制的所有学院都做一个搜索引擎，但是后面发现要完成一个就需要花一下午的时间，所以我们就改为只加了一个航海的搜索，也是因为航海没有搜索引擎，并且也能证明我们也能把其他的学院都爬下来只是需要时间而已。
5. 员工是否能够有效地处理意料之外的工作请求？
能，当我们PM在冲刺之前给的任务，在进行之后发现还有一些零碎的关键任务没有人去完成，PM会按照大家擅长的部分去分配，并且会说一个截止日期，会在群里面督促大家尽快完成，所以我们每次都能有效的完成意料之外的工作。
6. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
完成一个项目的时候不能死脑筋，必须做完这个才干嘛，有时候需要灵活的运用和方法来促使整个项目的完成，会比一个人钻牛角尖好得多。这次我们安排了很多次冲刺，时间安排的很棒，不会说因为最后没时间的赶工，因为大家最后都有考试，所以提前了两三天就结束项目。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在第一次老师给出这个项目需要几个几个星期完成的实验课，我们在实验课上就开始讨论前端页面的样式和要求，同时也在网上查找搜索引擎和爬虫的相关知识，大家都在实验课上一起讨论，但是这个时间是远远不够的，后面冲刺的时候最开始也有讨论过我们程序的走向，讨论好后最终定下终稿。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
用户测试这一块，我们是用的调查问卷，在制作调查问卷，提问的时候因为有些考虑到很多人不喜欢填写调查问卷，所以我们准备把问卷做的简单一点，我觉得是用户的建议是最重要的，所以我推崇就一个空，我们的搜索引擎有什么需要改进的么，这样我们就能拿到我们需要的内容，别人也不会觉得很烦，但是秦玉觉得应该像普通的问一些问题，不然空口答别人可能也没什么建议，我们要的数据就根本没有。
3. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
爬虫功能产生的Bug最多，因为界面不一样，学校的网站不是Css结构的，完全是又一个一个的表格写出来的网页，所以爬取跟普通的网站爬取又有区别，都是一步一步的学习改进才爬取出数据的，因为对爬虫理解的不深。我们还没有发布。同时也是我们对爬虫了解也不够深入，只能爬取到红色标题的内容，但是经过后期的改进已经能爬取全部的内容了。
4. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审统一由一个人来规范代码，严格执行了代码规范，因我们在编写的时候就在注意代码的编写，这样方便大家的理解同时后期也不用改这么麻烦。
5. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
只有当自己真正开始编写代码的时候你才能进步。编程的重要任务还需要分的细致一点，这样大家都能写到关键的代码，更多的熟悉爬虫。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
没有花太多的时间在测试上，只是有一个大概的测试计划。因为Beta阶段完成的功能比较零散，而且很多是在Alpha阶段做一些改进（如新增其他学院的搜索引擎），代码框架都是一致的，所以在搜索速度、爬取速度等方面基本没有变化。
2. 是否进行了正式的验收测试？
进行了正式的验收测试。
3. 团队是否有测试工具来帮助测试？
没有用到，只是用黑盒测试、浏览器自带的性能测试等方法来测试。
4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
我们并没有测量并跟踪软件的效能，我们只有代码测试各个浏览器的页面是否正确，搜索速度，爬取速度等的测试，后阶段进行用户调查，调查问卷中附加了网页链接，其实也是在测试服务器和用户交互。很有用，让我们的程序更符合大众使用的要求，改进了很多我们忽略的点，同时也验证了服务器性能。
5. 在发布的过程中发现了哪些意外问题？
通过用户调查后得到的数据，发现搜索得到的结果项中的摘要部分，是显示文章中匹配到的最后一个关键字的地方，所以若某文章中该关键字出现的位置分布在文章的前部和后部，则会导致摘要显示的篇幅比较大，其实应该做到像百度搜索出来的结果摘要，显示固定的大小。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在发布过程中发现的摘要问题，我们在编写及测试的时候都没有意识到，在用户交互方面还有所欠缺。在编写项目的过程中，应该更多的以用户的角度去思考，因为做出来的产品是给用户用的，而不是程序员本身，当然在技术方面，则是要以程序员的角度寻求最优解。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
这次的角色确定会更多地还是从比较细的方面来划分，因为beta阶段与alpha相比，目标明确了很多，最后分出来的任务也比较细致，然后根据每个人的能力或是意愿来进行任务的分配，大致可以做到人尽其才。
2. 团队成员之间有互相帮助么？
有互相帮助，因为我们平时都是聚在一起来完成这个项目的，因此在遇到困难的时候，一般会直接提出来，然后手头上比较闲的同学就可以一起来想解决问题，解决完以后积累下来的经验也会跟其他成员交流，防止踩到同一个坑里。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
遇到了这方面问题的时候，一般就是让矛盾双方阐述自己的想法，然后再一起交流，最后达成一致，但是其实经过了alpha阶段，我们在这方面都比较成熟和默契，一般不会出现这种问题。
总结
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
属于第五级 优化级
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我们团队目前处于创造阶段。beta阶段我们的团队成员已经对规范方面有了比较好的实现，然后集体意识也有所提高，对于项目的走向也有一个比较好的把握。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
相比于alpha阶段，首先，我们团队成员之间的配合更加的有默契， 能够更好的沟通交流；其次我们在技术能力方面也有很大的进步，从最开始对搜索引擎的贫乏的了解到现在已经能大概掌握其全貌以及具体实现方法；最后，我们团队在代码规范方面和管理方面也有了比较大的改进，前一个阶段比较不注重规范，主要还是求能实现功能就行，然后在管理方面也没有使用专门的工具来处理，beta阶段开始我们会比较注重这一点。
你觉得目前最需要改进的一个方面是什么?
我觉得虽然我们最后完成了这个项目，但是总体的完成效果其实还是有一些瑕疵，主要还是因为我们投入的时间不太多，因此我觉得需要改进的是希望我们团队的成员能投入更多的时间在项目上，这样做出来的效果应该会更好一点。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
对照TSP原则，我认为我们小组在以下几个方面做得比较好：
- 团队的各个成员对团队目标、角色、产品都有统一的理解
在我们开始对产品进行讨论的时候，就已经小组达到一个共识，然后在后面不断地编写程序完成项目的时候，我们也会定期交流一下我们项目的未来走向以及其他一些与项目相关的内容。 - 增加团队的自我管理能力
我们团队的每个成员对于我们的项目都能够比较好的投入到里面，每个人都有自己的定位，也都能在计划时间内完成任务。
