1、基本情况：
-
答辩总结：
Beta冲刺总的来说我们还是在Alpha冲刺上改进了很多，已经实现后端1.0版本，正在着手怎么部署上线，每个小组成员都为了团队付出了自己的汗水，历经风雨终于嗅得芬芳。但我们都是小白，没有开发项目的经验，所以部署上线能否将产品按期交付仍是一个未知数，不过不管结果如何，我们都在这个过程中有所收获，有所成长，也非常感谢老师对我们的鼓励与支持。
-
全组讨论的照片：
-
评估团队中每个人对本次作业的贡献比例：
-
本次Beta冲刺的工作流程：做好轮冲刺的文档撰写，前端服务器以及接口的研究、推进，后端开发、收集测试用例以及需求分析。
组员分工：
文档撰写：李佳乐、吴洁颖前端服务器以及接口的研究推进：陈小楚、吴起霖、吴尹航、王璐、何文龙、傅智鑫
后端开发整合：陈晟新
收集测试用例以及需求分析：孙晴晴
-
组员工作量比例
成员 主要工作 比例 陈晟新 统筹、后端开发、整合。 14% 陈小楚 前端页面编写、研究部署。 10% 傅智鑫 前端学习、研究部署。 8% 何文龙 辅助前端页面编写、研究部署。 8% 李佳乐 文档撰写。 11% 孙晴晴 收集测试用例，需求场景。 11% 王璐 前端学习、研究部署。 9% 吴洁颖 文档撰写。 8% 吴起霖 答辩、接口编写。 12% 吴尹航 服务器端开发。 9%
-
2、参考模板进行总结思考：
2.2.1.设想与目标（4分）
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
•主要解决的问题：我们的文档处理器主要用于解决办公学习以及各种机构高校中Excel、Word之间的大规模的转换。
•这款软件主要运用大批量信息管理处理中，例如学校调查学生考研意向信息等Word自动整理成Excel表格，个人财政支出大量Excel合并整合成一份等。
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
•原计划主要核心功能为四个，还有服务器方面的搭建，配置好了云服务器环境，前端页面以及交互还残留一些问题，但在后端那边已完成所有功能模块的整合和第一版的完整后端1.0版本。
•未在原计划时间内完整交付，前端页面的交互方面以及接口方面还存在一点问题。
•原计划还没在Beta冲刺中设定用户数量，所以用户局限在组内。
3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
•尽管还没开始正式发行，但是我们通过采取在问卷调查，抽查询问用户以及询问潜在客户的需求后，我们认为用户对重要功能的接受程度在大致上与我们的事先预想是有许多共同之处。
•在经过对潜在用户的调查后，结合调查结果，最后我们认为我们目前所努力的方向是正确的，所以是逐渐靠近目标的。
4、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
•刚开始的设想目标，感觉稍微偏离实际的方向。如果历史重来一遍，我们会更加尽可能考虑到方方面面。
2.2.2.计划（5分）
1、是否有充足的时间来做计划?
•用来制定计划的时间是充足的，可能是因为在之前的Alpha冲刺积累一些经验吧。。
2、团队在计划阶段是如何解决同事们对于计划的不同意见的？
•在计划阶段面对组员不同的意见 ，选择是让队员们发表他们不赞同的原因要素，而后我们其他组员会针对对方的意见进行协商讨论，如果最后没办法接受会采取少数服从多数又或者重新起草新的计划。
3、你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
•原计划的工作大部分都做完了，留下的一些小工作，主要是因为知识学习掌握方面的效率不够快带来的。
4、有没有发现你做了一些事后看来没必要或没多大价值的事?
•并没有，因为在进行这个项目过程中遇到的每件事都会成为以后道路上的一个经验，以这个角度来看，它们算是值得的。
5、是否每一项任务都有清楚定义和衡量的交付件?
•大部分都是有清楚定义和衡量的交付件的，但出于经验问题，无法覆盖清楚定义每一项任务的交附件。
6、是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
•并没有整个项目都按着计划进行了，最主要的意外还是知识储备方面与能力方面带来的导致任务进度上的时间规划出现偏差。
•前后端交互的技术难度以及接口问题等是当时没有估计充分的，因为缺乏开发经验。
7、在计划中有没有留下缓冲区，缓冲区有作用么?
•有留下缓冲区，但划分给缓冲的时间较少，缓冲区是有作用。
8、将来的计划会做什么修改？（例如：缓冲区的定义，加班）
•在缓冲区上估计会比这一次的冲刺要多一点，为了给由于能力不足引起的计划变动有一定的接受能力。
•在加班上可能会加重一些比例。
9、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
•在计划方面学到了计划的两面性，一方面因为有计划让事情进度更有条理，但是也容易因为计划带来负担方面的问题，因为实际情况不可能百分百按照计划，出入问题会导致后面的计划有影响。如果重来一遍，还是会更加的完善计划吧。
2.2.3.资源（3分）
1、我们有足够的资源来完成各项任务么?
•不能说有完全足够的资源来完成各项任务，有的任务的技术难度目前还是在我们的能力之外，但我们会努力利用已有的各项资源来完成任务。
2、各项任务所需的时间和其他资源是如何估计的，精度如何?
•通过自己已有的知识储备，以及通过查阅资料后的了解，将各项任务所需时间和资源进行一个估计，顶多可能有些时间需要用上一些预感来判断吧。
精度方面不说完全贴切，但是大致上还算是较为准确的。
3、测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
•测试时间、人力和软件/硬件资源目前来看是足够的。
•不需要编程的资源一开始稍微低估了难度，但主要也是因为没经验导致的，所以总体上还算是可以的。
4、你有没有感到你做的事情可以让别人来做（更有效率）?
•并不是很确定，最开始进行任务分工的时候，队员们是尽量按照自己的能力来进行挑选任务的。
5、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
•经验教训：在进行资源和时间分配上，需要更加的明确具体，还会充分考量大家的学习能力。
•会做什么改进：任务分工更加明确，更且会在一些任务上优先倾注一些资源。
2.2.4. 变更管理（4分）
1、每个相关的员工都及时知道了变更的消息?
•是的，在群里发布变更消息后，相关人员都会回复或者通过其他方式保证自己收到了。
2、我们采用了什么办法决定“推迟”和“必须实现”的功能?
•对功能任务进行评级，评出功能重要程度的等级，将资源优先倾向于能够实现且 重要的功能，就此决定出“推迟”和“必须实现”的功能。
3、项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
•“做好了”，应该是在测试上首先是达到可靠而合格的要求，其次，我们将分别模拟用户进行操作测试，还会邀请真正的潜在用户进行测试评分，不可能一下子预料到所有问题，但是起码要经得住用户简单的操作测试。
4、对于可能的变更是否能制定应急计划?
•可以的，而且将会集中大家的意见，有的比较重点的项目会在一开始就保留有B计划，以便能够更好面对各种突发情况。
5、员工是否能够有效地处理意料之外的工作请求？
•可以的，相信自己的队员，以及强大的网络支持。
6、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
•在变更管理上，我们体会到了计划安排和变更之间的联系。如果能够重来，我们应该会在一开始估计更多的可能的困难和可能出现的问题，避免变更频繁。
2.2.5. 设计/实现（4分）
1、设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
•是在一开始就由李佳乐和吴洁颖完成的，是。
2、设计工作有没有碰到模棱两可的情况，团队是如何解决的？
•出现过，是由大家共同讨论，各抒己见，最后通过以理服人或者投票或者组长敲定的。
3、团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
•由于后端算法初步完成还需要变动代码进行优化，所以目前还未运用单元测试，将来完善代码后会运用单元测试测试代码性能，有使用jmeter工具测试系统性能，对服务器压力等信息可以反映出来。
4、比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
•没区别，不需要更新。
5、什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
•在批量word归并到excel这个功能实现的过程中产生的bug比较多，因为word归并到excel中，应用场景word文件是表格形式的比较多，而表格可以有非常复杂的形式，所以这方面的解决也需要不少时间。产品并未进行发布，所以没有出现发布之后的重要bug。
6、代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
•代码复审由队长和组内选择出来的大佬一起负责，正在改善代码规范中，会努力严格规范代码，代码规范后，组长会将这些转交会由专门负责测试的队员进行测试。
7、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
•学到了什么：后端功能的实现中学到了如何利用强大的库函数解决问题，还有代码规范的重要性。
•会做什么改进：在整合代码之前做好交流，使代码整合之前就更加规范，减少代码整合时间，同时也能给接下来的工作展开起一个更好的开端。
2.2.6. 测试/发布（3分）
1、团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？
•有测试计划。由于接口方面仍存在一些问题，所以暂未开始验收测试，只先进行了局部方面的测试。
2、团队是否有测试工具来帮助测试？
•使用jmeter进行测试。
3、团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
• 首先进行接口测试，测试网页是否能连接；连接成功之后进行性能测试，测试网页的请求数、响应时间、错误率与吞吐量。这些测试工作还是有用的，能够观察到网页的性能如何。改进的话就是细节问题吧，不是很全面。
4、在发布的过程中发现了哪些意外问题？
• 花费的时间超出预期，因为组员对于这方面的知识掌握度并没有到达能够熟练使用的地步，所以在这方面会比较耗费点时间。
5、我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
• 学到了如何测试网页；如果历史重来，我们将会更早去接触这方面的知识，尽量使自己能够早点具有这方面的能力。
2.2.7. 团队的角色，管理，合作（3分）
1、团队的每个角色是如何确定的，是不是人尽其才？
•在确定团队角色时，我们会让每个成员拥有自己的第一志愿和第二志愿，首先看成员最想担任的角色，如果实在有冲突就查看第二志愿，尽量保证每个成员分配的任务都是他所擅长或感兴趣的，做到人尽其才。
2、团队成员之间有互相帮助么？
•有困难的时候会密切沟通，互相帮助。
3、当出现项目管理、合作方面的问题时，团队成员如何解决问题？每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
•当遇到管理合作的问题时，我们会先在群里初步沟通，如果网上的沟通没办法解决我们的问题，那么我们会选择在线下沟通。
我感谢陈小楚对我的帮助， 因为某个具体的事情: 教我怎么写代码等等问题。
4.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
•学到了如何资源利用最大化和团队协作的重要性，如果重来，我们会在目前薄弱的地方多安排人手，尽量将每个人安排到合适且需要的位置上。
2.2.8. 总结（4分）
1、你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
•属于defined档次。
2、你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
•在规范的后期。
3、你觉得团队在这个里程碑相比前一个里程碑有什么改进?
•增强了团队协作能力，队伍的凝聚力有了显著的提高，各方面的开展更加规范。
4、你觉得目前最需要改进的一个方面是什么?对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
•目前最需改进的是—每个队员完成工作的责任感 ；对照敏捷开发原则，我们小组做的好的方面有：
① 简单化是根本（不做过度设计和预测）。在设计界面时，我们将设计重心放在了4个核心功能
页面的设计上，项目本身除了基础功能设置外几乎没有其他多余的功能。
② 每隔一定时间，团队会在如何才能更有效地工作方面进行反思并对自己的行为进行相应调整。
我们每周都会开3-4次的会议来交流各小组的成果进度，并据此做出接下来的规划。
③ 在团队内部，最具有效果并且富有效率的传递信息的方法，就是面对面的交谈。
我们每周都会开3-4次的会议来交流各小组的成果进度，并据此做出接下来的规划。