beta冲刺——问题总结
alpha阶段的问题
一、设想和目标
1.我们的软件要解决什么问题？是否定义得很清楚？
我们组的产品“17”解决了用户远程办公的繁琐和延迟，致力于为用户营造便捷舒适的线上办公体验。
2.是否对典型用户和典型场景有清晰的描述？
疫情期间不停工不停学的人员用于暂时不能面对面交互的办公场景，便于实时了解参与者的进度。
3.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？)
前端部分因为分工后产生了一些问题，最后未能完成文件和群聊模块。其余模块均正常完成。
4.有什么经验教训? 如果历史重来一遍，我们会做什么改进?
前端要按功能模块分割，一人负责一个完整功能。不能将html+css与js和逻辑功能实现脱节。
二、计划
1.是否有充足的时间来做计划?
我们团队在Alpha阶段的初期就已经规划好我们每个人的任务了，在之后的每天都是对于前部分计划的补充。
2.团队在alpha阶段是如何解决队友对于计划的不同意见的？
幸运的是在Alpha阶段队友对于计划安排并没有什么不同意见，大家都很Peace。
3.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
团队原计划在Alpha阶段完成产品的基本功能，包括：用户模块、项目管理模块、任务模块、日程模块、文件模块和群聊模块。
日程安排大致为：
- 前端完成界面、后端完成模型层和逻辑层 预期：3-4天
- 后端写控制器层，并提供接口文档给前端，前端完成接口对接，同时接口测试可以开始进行。 预期：3-4天。
- 剩下的时间寻找并解决可能存在的问题。
项目意外：
项目的整个过程都按照计划进行，就是在前端的界面设计和逻辑交互部分在后期出现了意外。每个人的代码习惯不同，容易造成最后整合的困难。将逻辑交互分离造成了负责的同学工作量过大，带来重复的工作量。使得界面设计的交付没有一定的规范，产生冗余和其他的问题。
4.beta阶段安排概览
1.在Beta阶段开始前完成在Alpha阶段未完成的部分，并且增加原型设计时未考虑到的原型图，以便接下来的实现工作。
2.在Beta阶段，先是完成原先计划中剩余的动态和提醒两个模块，之后展开产品的界面测试、接口测试和压力测试。
三、资源
1.时间
时间资源来说略微缺少，在整体任务的进度上较为延迟。
2.美工设计
对于前端的HTML和CSS来说，它的编码和排版是比以往的作业要精准的多，尤其是每个部件的摆放位置都差之毫厘失之千里。还有浏览器的报错问题以前并不会注意，而这次就成了整体错误的导火索。还有一部分产品功能是在原型设计部分遗漏的，所以在界面的制作上又耽误了一些时间。
3.测试
本次测试是由一人负责的。人力资源较为短缺。并且测试比想象中繁琐一些，特别是测试用例文档的撰写。比起开发来说确实简单一些，但是要保证测试的完整性就要做很多体力劳动。受限于时间等原因，这次测试方面比较单一。
四、设计/实现
1.设计
设计阶段是在Alpha冲刺前就设计好的，由前端和后端的负责同学进行。他们有较强的技术和能力，所以作为整个项目的设计人员很合适。后续的任务分配也是如此。
2.实现
测试使用的是postman以及Firefox web开发者工具 ，一边编码一边测试，避免错误的堆积。
五、测试/发布
1.后端测试工具
postman：
用户在开发或者调试网络程序或者是网页B/S模式的程序的时候是需要一些方法来跟踪网页请求的，这款网页调试工具不仅可以调试简单的css、html、脚本等简单的网页基本信息，还可以发送几乎所有类型的HTTP请求。
根据各种参数请求，在postman中组合设计测试用例，测试用户模块、项目基础模块、项目任务模块的功能接口。
2.前端测试工具
Firefox web开发者工具
可以在 PC 和移动设备上检查，编辑，调试 HTML、CSS 及 JavaScript。
3.测试中学到的东西
- 测试是程序的一种执行过程，目的是尽可能发现并改正被测试软件中的错误，提高软件的可靠性。它是软件生命周期中一项非常重要且非常复杂的工作，对软件可靠性保证具有极其重要的意义。
- 坚持一边编码一边测。软件测试应该是在软件的编写过程当中，对模块进行同步测试。不然很容易造成错误的积累，从而导致问题范围不断扩大。
- 测试要有计划。测试很耗时间，但是，如果为了追求测试的速度，毫无计划地开始测试，结果就容易变糟糕，而且速度不能如愿，所以测试一定要有计划性的进行。
- 测试完成及时总结也很重要。在测试的过程当中对自摸索出来的经验进行总结，做个记录，方便日后的查看，也是对学习的一个记录。
4.如果再来一遍的改进
可以将冲刺计划提前在deadline之前几天，留下比较充裕的时间对软件的效能进行深度的测试，从而发现程序可改进和优化之处。
六、团队的角色，管理，合作
1.团队的每个角色是如何确定的，是不是人尽其才？
团队的角色是组队之初就有确定的。
2.团队成员之间有互相帮助么？
团队之间是互帮互助的，在前后端的两个负责同学的带领下解决了不少问题，是整个团队和谐成功的关键。
3.当出现项目管理、合作方面的问题时，团队成员如何解决问题
在出现项目管理、合作方面的问题时候，团队成员都是在开会讨论的时候解决的。总的来说就是很和谐。
七、提高软件工程的质量
1.代码管理的质量具体应该如何提高？
- 代码风格必须一致，依据代码规范的制定
- 制定代码复查工具，减少重大缺陷的发生概率
- 设计逻辑与思路的检查
2.代码复审和代码规范的质量应该如何提高？
代码复审在这种较大型的产品开发中尤为重要。因为代码量较多所以一些小的差错很容易被忽略。
- 代码复审的代码要符合需求和规格说明。
- 代码设计有比较周全的考虑，耦合度要小，方便之后的修改。
- 代码有较高的可读性。代码根据功能分为了几个不同的类，对功能的划分较为直观，关键部分有详细的注释。因为是合作代码，并且大家的编码习惯往往大不相同，可读性较强的代码更容易大家的理解，提升效率，易于维护。
代码规范的制定也是方便代码的相互融合，个人特色不至于很突兀。 - 代码规范依据通用的代码规则，尤其是一些大型互联网公司的代码要求，一时方便理解，二是司空见惯比较熟悉。
- 代码规范适当加入大多数组员的个人习惯。
3.整个程序的架构如何具体提高？
- 分块：各业务模块之间应该尽量少的耦合
- 异步：不影响业务流程的尽量使用异步处理
3.记住失败：记录每一个异常，记录每一次请求的内容和返回的结果
4.自动化：用尽量少的配置完成更多的工作
4.如何通过重构等方法提高质量，如何衡量质量的提高？
重构方法提高质量
- 分离方法到新类中，避免臃肿的代码
- 重命名方法，模糊不清的方法名会影响代码的可使用性。这些模糊不清的名称应该重命名为有意义的可能与业务术语有关的名称，
衡量质量的提高 - 统计代码行数可能是最简单的方法。它能体现软件的规模，为项目的发展和计划提供一些数据支撑。
- 问题跟踪是保证测试和可维护性的关键步骤。问题数量可以作为衡量开发质量的一个标准。
- 代码被测试的程度。不能说明单元测试的整体质量，但是能说明测试的覆盖面。
- 代码可读性和可维护性。
- 环路复杂度的计算。
5.项目管理有哪些具体的提高？
1.对于项目工期计划的把握。相较于上次的团队实战来说，这次的工期安排是提高了很多的，虽然中间会有一些没有按时完成的情况，但是后期还是辛苦地补回来了。
2.对于用人的安排。通过团队间的不断熟悉，成员们之间都大致了解彼此的能力，所以人员安排上以自愿为前提，合理分配，尽量发挥成员的潜能。
6.对于人的领导和管理， 有什么具体可以改进的地方？
1.更加清晰地分配任务
2.积极解决成员的困难，引导成员的工作，听取成员的意见
7.什么是在下个阶段要改进的地方？
1.平均地分配任务，避免有的成员过于忙碌。
2.领导者更加地严格，按时分配任务，即给定截止日期，让所有成员都积极行动起来。
组员工作交接
交接及培训方案情况
本来以为新成员的加入可以在一定程度上减少前端组员的工作压力，但是我们“多个组员”且“多次”尝试与新组员进行联系，都未能取得联系。在这种情况下，我们无法对新组员进行任何交接和培训工作。因此，我们无法给他分配任务。换出的成员在alpha阶段仍处于学习阶段，且负责博客的撰写，所以并没有什么正在实现中的任务需要交接，本来希望将他博客撰写的任务及部分前端的任务分配给新成员来完成，但由于无法与新成员取得联系的原因，只能将博客撰写分配给其他成员。
