第07组 Alpha冲刺 总结
1、基本情况：
-
答辩总结：
为完成团队项目，每个组员都付出了自己的努力和汗水，虽然历经坎坷但最终迎难而上。即使每个人的技能、积极性和工作态度各异，但都在Alpha冲刺中得到了成长。
-
全组讨论的照片：
-
评估团队中每个人对本次作业的贡献比例：
-
本次Alpha冲刺的工作流程：先集中精力完成原型设计和后端开发，同时加快学习服务器端开发和前端开发以及测试工具的使用。
-
组员分工：
原型：李佳乐、吴洁颖
后端：陈晟新、王璐、吴起霖、傅智鑫
服务器端：吴尹航
前端：陈小楚、何文龙
测试：孙晴晴
-
组员工作量比例
成员 主要工作 比例 陈晟新 统筹、批量word填写的编码、后端代码的整合。 14% 陈小楚 前端页面编写。 13% 傅智鑫 完成excel一到多分割以及多到一合并的编码。 9% 何文龙 博客整合排版、辅助前端页面编写。 9% 李佳乐 原型设计。 9% 孙晴晴 练习测试工具使用。 7% 王璐 完成excel导出批量word的编码。 10% 吴洁颖 辅助原型设计。 5% 吴起霖 完成批量word归并到excel的编码、答辩。 13% 吴尹航 服务器端环境搭建。 11%
-
-
测试组提问：
1、 分割依据可以多项吗？
答：可以做到多项，如果分割依据选择多项的话，以两项为例，比如说学号前六位和姓名第一位（也就是姓氏），则所有学号前六位和姓氏都一样的记录导出在同一excel文件中，而所有学号前六位或者姓氏不一样的记录都在不同的excel文件中。
2、此次展示没有前端展示，那在前端界面交互上，如何选定相关的格式，比如表格某一栏限定格式，其他栏格式不变？
答：因为现在前端和服务器端的交互还没正式开始，我们认为这个要参照我们后端的代码，进而设计出具体的交互的方式，所以还是要等真正交互时，根据需要来做出调整。
2、参考模板进行总结思考：
2.2.1.设想与目标（4分）
1、我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
•主要解决的问题：我们的文档处理器主要用于解决办公学习中Excel、Word之间的大规模的转换。
•这款软件主要运用在办公室和学生或者其他的大批量信息管理中，例如四六级众考生成绩Excel批量转成Word，企业公司员工请假及日常填报信息Word汇总自动生成Excel等。
2、我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
•原计划主要核心功能为四个，现在每个功能后端都已经初步实现，但还需要一些算法上的修改完善，争取更高效更完善。
•未在原计划时间内完整交付，前端页面的交互方面以及后端的功能拓展方面还未完成。
•原计划没在alpha冲刺中设定用户数量，现在由于只有初步的后端模型所以用户局限在组内。
3、用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
•在经过问卷调查，抽查询问用户后，用户对重要功能的接受程度在大致上与我们的事先预想是有许多共同之处。
•在经过对潜在用户的调查后，我们认为我们目前所努力的方向是正确的，所以是逐渐靠近目标的。
4、有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
•刚开始的设想目标，感觉稍微偏离实际的方向。如果历史重来一遍，我们会更加尽可能考虑到方方面面。
2.2.2.计划（5分）
1、是否有充足的时间来做计划?
•在时间规划中，做计划的时间是比较充足的。
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、对于可能的变更是否能制定应急计划?
•可以的，而且将会集中大家的意见针对常见的变更预留应急计划。
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次的会议来交流各小组的成果进度，并据此做出接下来的规划。
