beta冲刺——答辩
一、设想和目标
-
做这个项目的背景、意义是什么？要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
- 背景：2020年突如其来的疫情使手机、互联网在生活工作中成为了我们最重要的东西。在这样的大环境下，线上工作的重要性尤为突出。因此，我们组提出的团队线上协作的解决方案，致力于为用户营造便捷的线上协作体验。
- 意义：解决具有进行线上协作或办公需求的团队的痛苦，提供快速搭建的团队环境，简单高效的项目管理，清晰直观的任务分配，方便快捷的文件存储等，它能给用户带来好处是免费又便捷的团队在线协作服务
- 对典型用户的描述：团队协作成员
- 对典型场景的描述：
- 文件共享上传：在线文件共享服务帮助成员在项目组内能够共享文件、传输文件，避免了文件丢失、重复发送等问题
- 任务面板、日程安排：任务便捷发布，成员可自主领取；随时更新任务进程与状态；安排每日计划，明确工作目标
- 即时聊天、通讯：快速发起会话；实时增加、删除成员；随时随地高效沟通；及时反馈工作信息
-
项目达到目标了么（原计划的功能做到了几个？在原计划之上是否有所拓展)
- 原计划实现——文件上传共享、任务面板、日程安排、即时聊天通信文档协作以及用户管理与项目管理模块
- 实际上做到了除了文档在线协作之外的功能
- 拓展了消息通知模块，其他模块在细节上也有所拓展。
-
和alpha阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？
- 团队软件工程的质量提高了，对于整个软件的开发以及管理和计划的把握上有了一定的提高，更加重视每日会议的汇报总结，及时提出解决方案和改进方案。
- 通过开发的软件项目质量以及开发过程中对问题的处理以及初始的计划安排情况来衡量；提高了软件开发过程的可见性，提高了软件内部模块、项目中间阶段的交付质量。
- 主要使用定时提示的形式，PM定时提醒成员应该做的任务、以及询问进度；具体时间由各成员自行管理，采取适当压力；由于其他课程的任务繁重，常常出现任务不能再规定时间内完成的情况，处理方式为顺延任务时间。
-
设想用户量是多少, 用户对重要功能的接受程度和我们事先的预想一致么?
- 设想的用户量为：500
- 用户对重要功能的接受程度和我们事先设想的基本一致
-
有什么经验教训? 如果历史重来一遍，我们会做什么改进?
- 经验教训：前端的界面设计和逻辑交互部分在后期出现了意外。每个人的代码习惯不同，容易造成最后整合的困难。将逻辑交互分离造成了负责的同学工作量过大，带来重复的工作量。使得界面设计的交付没有一定的规范，产生冗余和其他的问题。也就是α阶段的问题累积到了β阶段
- 改进： 用合理的分工来安排工作。
二、计划
-
和alpha阶段相比，每天是否时间规划的更好?
时间规划更好，体现在有预留缓冲区时间段，可以进一步的修复bug和优化代码质量；
-
团队在beta阶段是如何解决队友对于计划的不同意见的？
如果有队员对计划有不同的意见，都会鼓励积极提出来，评估提议和原先项目最初定下的计划相比较下的合理性的高低，看情况进行适当的调整。
-
你们原计划的工作是否最后都做完了? 如果有没做完的，为什么?
计划的工作均已完成
-
是否每一项任务都有清楚定义和衡量的交付件?
是。在计划阶段我们就已经在会议时清楚了每一项任务的定义，之后也可通过队员们的commit来衡量任务的推进与完成。
-
项目是否出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
否。
-
在计划中有没有留下缓冲时间，缓冲时间有作用么?
有计划留下了缓冲时间，且缓冲时间有作用。我们留下了约一周的缓冲时间用于进一步修复代码bug和优化代码质量，如优化加载速度、完善文档记录等。
-
我们学到了什么? 如果重来一遍, 我们会做什么改进?
计划的任务内容分配粒度应该更加细一些，更加明确一些
三、资源
-
有足够的资源（可以是时间、开发资源等）来完成各项任务么?
时间和开发资源较为充足，各项任务完成基本达成
-
各项任务所需的时间和其他资源是如何估计的，精度如何?
时间资源根据负责人估计的任务难度，精读比较差一些
-
和alpha阶段相比，测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 和alpha阶段相比，测试的时间，人力和软件/硬件资源较为足够
- 对于那些不需要编程的资源 (美工设计/文案)确实是比预计中繁琐一些，需要更多的时间人力，低估了一定的难度程度
-
变更的组员工作如何？如果未变更是否项目完成效率会更高？变更的组员学到了什么？对于可能的变更是否能制定应急计划?
本来以为新成员的加入可以在一定程度上减少前端组员的工作压力，但是我们“多个组员”且“多次”尝试与新组员进行联系，都未能取得联系。在这种情况下，我们无法对新组员进行任何交接和培训工作。因此，我们无法给他分配任务，由于无法与新成员取得联系的原因，只能将任务分配给其他成员。
-
有没有感到某个成员做的事情可以让别人来做（更有效率）?有什么经验教训? 如果历史重来一遍, 你们会做什么改进?
-
因为小组分工主要是从个人能力方面考虑，故比较大的程度上是效率较高的组合选择
-
经验教训：
前端任务比较繁重，应该更多的安排人力资源，，避免有的成员过于忙碌。
任务内容的分配粒度更加细一些，更加明确一些
-
四、设计/实现
-
项目是否经历重构？为什么需要重构？
否。
-
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的UML文档和现在的状态有什么区别？这些区别如何产生的？是否要更新UML文档？
群聊模块和文件模块部分与最初设计的uml不同，主要原因是使用了第三方的sdk来完成这些模块。这些sdk减少了一定的工作量，也存储了一部分信息在其他平台上，所以方便对接sdk，调整了部分类图来匹配对应的接口。
-
什么功能产生的Bug最多，为什么我们在设计/开发的时候没有想到这些情况?
- 前端：互相依赖的数据的异步更新、ant-design UI库。前者是因为在设计vuex中有状态数据的存储时欠考虑，没有太多顾及他们间的依赖和先后次序，所幸之后都已解决；后者是因为低估了ant-design UI的复杂程度，文档用例和标准API没有好好去读，在认真学习文档并逐一对照后，bug都基本解决。
- 后端：群聊模块和文件模块引入了第三方sdk来完成，因为对sdk接口的使用方法不完全了解，所以产生了不少相关bug。其余模块产生的bug因为方便追踪数据，均可在发现时及时修复。
-
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
前后端分别由周方旭、黄晨阳负责主要部分，由其他成员完成编码后，相关负责人均有对其代码进行复审，保证符合代码规范。
-
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到
- 多人合作中，严格执行代码规范非常重要。写出可读性极差的面条代码，也许在个人一次性项目中无关紧要，看似功能都已实现，但在重视可读性以及维护性的合作项目中，这无异于灾难。
- 着手开发前，一定要做到熟悉框架以及常见写法用法，重构也许不是是必需的，但如果能在开发前，将写法通过查阅技术博客和大神经验来达到最优，那一定是极好的。
- 改进
- 严格执行代码规范，不遵守者直接退回代码，多次违反者开除。
- 提前在网上查阅资料和技术文章，常用的框架已有大量前辈的经验，他们总结出的最优写法以及避开的坑，很值得我们初学者去思考和借鉴。
- 学到
五、测试/发布
-
和alpha阶段相比，测试工作有提高吗？在哪些地方提高了？
增加了压力测试
-
团队是否有一个测试计划？
- 由于是第一次接触压力测试，所以压力测试没有明确的测试
- 接口测试则与alpha阶段一样，正常进行。
-
团队是否有测试工具来帮助测试？
- 压力测试使用Jmeter进行自动化压力测试，使用Badboy来录制测试脚本（但由于和项目不兼容，不能使用）
- 接口测试——postman
-
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？在发布的过程中发现了哪些意外问题？
- 压力测试方面，根据测试结果分析在不同并发数下，软件的响应时间来衡量软件的效能。由于分析能力有限，感觉测试结果并没有发现太大的问题，只能根据响应时间，确定软件能承受的合理的并发用户数。
-
我们学到了什么? 如果重来一遍, 我们会做什么改进?
重来一遍，我会制定明确的测试计划，编写测试用例，对软件系统各方面进行充分测试，学会分析测试结果，由分析测试结果对开发给出建议。
六、团队的角色，管理，合作
-
团队的每个角色是如何确定的，是不是人尽其才？
团队的角色是组队之初就有确定的，beta冲刺阶段再次重新明确工作任务
-
团队成员之间有互相帮助么？
团队之间是互帮互助的，在前后端的两个负责同学的带领下解决了不少问题，是整个团队和谐成功的关键
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
在出现项目管理、合作方面的问题时候，团队成员都是在开会讨论的时候解决的。总的来说就是很和谐
七、总结
-
组员们自我总结
-
黄晨阳
beta阶段在开发上我觉得符合预期，没遇到太多的困难。后端依靠着alpha阶段完成的架构，无论是写新模块的代码还是修bug，都能快速的定位，完成编码。
-
周方旭
这是我近来第一次参与多人合作项目，从中学到了Github协作、前后端合作等方面的知识，当然更多的是对先前知识的巩固和熟练，也了解到代码可读性、风格的制定对合作开发来说至关重要。总的来说我对自己的表现不算很满意，因为时常对项目有所懈怠，很多细节处理也不肯花太多时间去弄，感觉差不多能做出来就放那儿了，反观组员都很上心，更会下功夫去研究文档和用例——希望自己以后对敲代码更有热枕和激情。 -
张钰荟
beta冲刺感觉我们小组比起alpha阶段在效率和时间安排上有了很大的提升，这些提升也最终体现在交付的软件产品上，在用户调查的结果中也得到了不错的反馈，确实的感受到开发成果得到用户肯定的开心；同时体会到了项目开发过程要进行不断进行各方面的优化，比如页面响应速度，出错处理等，从而改善用户体验 -
林杰
beta冲刺我主要的任务是压力测试。而压力测试我也是第一次接触，在测试的过程中像摸石头过河，跟着一些教程一步一步做，却没有整体的概念。有时候遇到问题，需要花费一些时间解决。整个测试包括学习、尝试、重复、总结，最后对于压力测试才有了些许概念，就如同一个视频里老师说的：“会使用测试软件和会测试是两个概念！”。确实，经过beta阶段，我好像只是学会了使用测试软件（甚至还不够熟练），并没有真正学会测试。测试的基本步骤也没有一步一步系统地进行。归根结底，对于测试没有一个深刻的理解，没有系统的把握测试。希望在以后的项目中，多接触测试，从而从测试中获得对项目开发有利的建议。 -
洪澍楠
-
衡天宇
这次的Beta阶段比前期的Alpha阶段顺利多了。对于前端而言，掌握了接口获取数据展示数据的知识就很容易了（除了后期修改bug有点困难）。这次因为时间比较充足，所以可以花大量的时间去做每个模块的部分，每次做完一部分还是蛮有成就感的。看着后端数据整齐正确的显示在前端应在的位置，浏览器的报错红叉消失干净，这也许就是码农的快乐吧。队友很强，肝很久都解决不了的问题让队友一改就好了，还附送经验小知识。最后项目成品落地挺欣慰的。 -
余璐
beta阶段，感觉很充实，虽然有很多的时间都是在“尝试解决BUG——发现无法解决——换种方法继续尝试——仍旧无法解决”中循环，最终那些BUG也都是队友来解决的（泪目）。
与alpha阶段相比的进步之一是这次前端的大家都参与了js的编写，而不是像之前那样把html、css与js分开，后者全都交给一个人来做。在beta阶段感觉更平衡了一些。其次，在beta阶段，成员之间的交流比alpha阶段更多了，感受到了彼此交流对于推动任务完成的重要性。
-
-
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
CMM/CMMI将软件过程的成熟度分为5个等级,以下是5个等级的基本特征：
(1)初始级(initial)。工作无序，项目进行过程中常放弃当初的计划。(2)可重复级(Repeatable)。管理制度化，建立了基本的管理制度和规程，管理工作有章可循。
(3)已定义级(Defined)。开发过程，包括技术工作和管理工作，均已实现标准化、文档化。
(4)已管理级(Managed)。产品和过程已建立了定量的质量目标。开发活动中的生产率和质量是可量度的。
(5)优化级(Optimizing)。可集中精力改进过程，采用新技术、新方法。拥有防止出现缺陷、识别薄弱环节以及加以改进的手段。
团队应该处于初始级别，然后向可重复级别前进的阶段
-
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
磨合到规范这一阶段
八、提高软件工程的质量
-
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
- 代码风格必须一致，依据代码规范的制定
- 制定代码复查工具，减少重大缺陷的发生概率
- 设计逻辑与思路的检查
-
项目管理有哪些具体的提高？
- 对于项目管理的实施部分，时间管理有了较明显的提高。在前期Alpha冲刺的时候，前端部分是较为手忙脚乱的，因为任务分配的不合理性以及组员对于新开发技术的陌生导致进度被耽误。而在本次Beta冲刺阶段，前端的进度是较为可观的，因为项目模块的划分是很清晰的，每个人都自主负责几个模块，加上对于框架不再陌生，以及学期期末较为空闲的时间，就不会赶不上进度。组员们都可以很好地安排出自己的项目时间，高效完成功能任务。另外，活动排序也起了不少作用。有一些的代码框架甚至其本身是可以被很多部分复用的，这就表明完成了一点就可以免去后续编写复用代码的时间，例如前端日程详情的弹窗与消息通知日程部分的详情版块。
- 项目沟通管理也有了提高。同组组员相处时间久了就产生了一种默契。前后端对接的沟通效率大大提高，做到了有问题实时提出和讨论。减少了前后端对接出错的可能性。同时前端部分对于不能解决的问题也可以积极在群里讨论，这比一个人默默debug要省时省力得多。
-
项目文档的质量如何提高？
- 提高交付物编写质量，细化任务力度，明确任务分配，强调逻辑性、避免出现错别字等现象
- 提高项目文档版本管理的规范度和清晰度
- 提高项目文档的评审质量，提升文档内容要点的清晰度
-
对于人的领导和管理， 有什么具体可以改进的地方？
对于前端来说，在Beta冲刺阶段并没有指定人员去做特定的任务，大家都是自己发现有哪些功能需要添加或者改进而自己去做的。这就导致了有一部分任务没有落实，而被忽略。大家做的部分也没有被实时跟进，导致每个人的任务量不同完成度不同。改进的地方就是在冲刺开始前应该就要制定好每人的任务，防止最后遗留问题不知道该给谁去解决。
对于整个项目来说，任务的分配可以再细化一些，及时追踪各任务的完成情况，便于发现问题时迅速解决。
