Beta冲刺——总结
一、基本情况
答辩总结
beta冲刺时间较短，看起来的成果很少，本次大部分时间花在服务器的部署以及和前端的对接。
讨论图片
Beta阶段的工作流程分为前端交互、后端接口和服务器数据库开发学习
- 前端交互又分为界面美化和接口交互
界面美化：郭畅
界面交互：高菲，金昌鸿 - 后端接口分为服务器部署、算法嵌入，算法研究
算法研究：苏镜泽
服务器框架：郑烜
算法嵌入：马向超 - 数据库开发尚在学习尝试阶段
参与人：林坤贤、柯圳浩、杨泽远
| 成员 | 分工 | 比例 |
| 郑烜 | 统筹，服务器部署 | 10% |
| 高菲 | 整体性对接 | 11% |
| 郭畅 | 界面美化 | 11% |
| 白霖 | 给静态页面添加逻辑 | 7% |
| 柯圳浩 | 数据库搭建学习 | 8% |
| 杨泽远 | 数据库存储，维护 | 8% |
| 金昌鸿 | 客户端调用接口 | 11% |
| 马向超 | 相似度算法接口，答辩人 | 11% |
| 林坤贤 | 数据库交互学习，博客编写 | 8% |
| 苏镜泽 | 协同过滤算法研究 | 10% |
| 杨锋夏 | 博客整合，审核 | 5% |
2.1 设想和目标
-
2.1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决运动时音乐推荐的问题；软件是面向运动听歌或者日常听歌人群而定义的；典型用户为资深的运动听歌发烧友，场景即为运动场所或者用于日常听歌 -
2.1.2 我们达到目标了么(原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么？)
可以算是达到了我们Beta冲刺的基本目标，原计划的功能几乎全部实现，除了协同过滤暂时不知道怎么用打算之后慢慢研究，同时所有功能都在原计划时间交付了，用户暂时还是我们开发人员，等待推出后会有用户数量增加。 -
2.1.3 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
在软件推出之前用户暂时为我们开发人员，所以和我们预先的设想一致，而我们团队一直都在朝着我们的目标前进，同时也确实离我们的目标更近了。 -
2.1.4 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
APP的开发相较于小程序而言更加困难，而以我们目前的能力在做的过程中有些许困难，所以重来一遍我们可能会选择小程序和APP开发双线程一起进行，不过后面又发现小程序上可能会出现各种授权问题，可能无法正常上线等等，所以还是需要综合考虑。
2.2 计划
-
2.2.1 是否有充足的时间来做计划？
由于Beta冲刺时间短暂，本次Beta冲刺我们并没有太多的时间来制定计划就开始了完善项目，时间是比较紧的。 -
2.2.2 团队在计划阶段是如何解决同事们对于计划单不同意见的？
团队队内氛围友好，民主气氛浓厚，在有不同的意见时会提出，并在团队共同讨论商议。 -
2.2.3 你原计划的工作是否最后都做完了？如果没有做完的，为什么？
由于我们组理想版本的难度确实偏高，原计划想在Beta冲刺里实现的部分功能只能在最终版本实现了，原因一是时间较短，本周课业较多；二是难度多内容杂，大多数知识之前从来没接触过。 -
2.2.4 有没有发现你做了一些事后发现没必要或没多大价值的事？
为了和Alpha版本比较有差别，制作了android studio与本地sqllite的连接，但是并不能对接口提供什么帮助，不能用来云端存储。 -
2.2.5 是否每一项任务都有清楚定义和衡量的交付件？
我们对项目进行过程中将会遇到的各项任务不能够做到完全的估计和衡量在真正开始项目之前，随着项目的推进，我们对于各项任务的认识愈发得清晰了起来，基本上对每一项的任务都做出了清楚的定义并制定了衡量的交付件。 -
2.2.6 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
我们组在Beta冲刺中是摸索的前进的，所以并没有很明确的说“整个过程都按照计划进行”，出了点小意外就是组员不小心占用了服务器端口并无意中重置了新密码，幸亏及时发现不然可能导致服务器上的工作前功尽弃；没有预估到的原因还是对云服务器的使用还比较不熟练。 -
2.2.7 在计划中有没有留下缓冲区，缓冲区有作用么？
Beta冲刺时间紧迫，很遗憾我们组并没有留下缓冲区，在短时间内现学现卖并且能实现就是我们的理想状态了。 -
2.2.8 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划中将会腾出时间缓冲区用以解决发生在意料之外的情况，以及更好地完善产品；更加明确的对各个功能模块进行划分以更好的分工合作；进一步改善任务的分工安排，优化团队间的合作， 提高团队的工作效率，避免不必要的“加班”。 -
2.2.9 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在这次团队冲刺中， 我们团队协力完成了Beta版本的发布，在这一过程中虽然时间短暂，但是我们不仅在各自研究的前后端领域学到了全新的知识，还认识到了好的计划调度和团队合作对整个项目进度的重要性。如果历史重来一遍，我们会事先做好更加完善的计划，在本地数据库的选择上不会去死磕Mysql8.0而早点选择SQLlite，从而省下这“半无用功”的时间去为接口和云端做更充分的准备。
2.3 资源
-
2.3.1 我们有足够的资源来完成各项任务么？
资源稍有不足。
beta阶段，前端的美化界面挺顺利，但对于前段对后端API的对接上由于经验不足，网上指导资源泛而遇到一些一时半会儿无法解决的问题，在一次次尝试中推进。
至于后端的接口实现，算法优化，还算顺利。
在之后，我们将进一步把所需的功能完善，优化在APP上的使用体验。 -
2.3.2 各项任务所需的时间和其他资源是如何估计的，精度如何？
对于beta冲刺阶段，根据之前alpha的实际开发能力表现和对开发任务有一定的认识经验进行时间和资源上的估计。在经历了alpha的冲刺阶段的锻炼，目前对于任务有一定的把控，精度预估的比较准确。 -
2.3.3 测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源 (美工设计/文案)是否低估难度？
测试的时间，人力和软件/硬件资源稍有不足。
本次冲刺开始前后端的对接，进行了对双方内容交互的测试，debug上耗费了不少时间，需要时间打磨。
没有低估难度，在不需要编程的资源 (美工设计/文案)上，有专门人员进行，同时文案设计上全组通力配合，进行顺利。 -
2.3.4 你有没有感到你做的事情可以让别人来做（更有效率）？
没有，在任务分工上人员分配合理，各人员在负责任务上有效的发挥自己长处。 -
2.3.5 有什么经验教训？ 如果历史重来一遍, 我们会做什么改进？
经验教训：在前期提前查询，了解，APP开发的功能实现流程，提前了解一些可能出现的问题的解决方法，加快对实现过程中问题的解决。
改进：任务开发人员及时进行功能实现的交流，尽早了解前后端的需求，做好对开发工程的资源准备，在开发过程中考虑完善对接时的需要。
2.4 变更管理
-
2.4.1 每个相关的员工都及时知道了变更的消息？
每个相关组员都能够及时知道变更的消息,并作出相应的工作调整。 -
2.4.2 我们采用了什么办法决定“推迟”和“必须实现”的功能？
beta版本中我们根据产品完整性的需求以及功能的核心程度来决定“必须实现”的功能，即将前后端对接起来，实现产品的完整性。
而将耗时长，人力消耗大且非核心的功能进行“推迟”。 -
2.4.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？
beta版本中我们项目的出口条件是能够实现产品的完整性，将前后端对接并进一步完善功能。 -
2.4.4 对于可能的变更是否能制定应急计划？
对于可能的变更我们有制定应急计划，我们会先在github上查找大佬的源码作为一个实现的基础保障，
然后再在此基础上进行更进一步的学习，并且根据我们项目的具体需求对代码进行针对性的修改与添加。 -
2.4.5 员工是否能够有效地处理意料之外的工作请求？
我们组员能够在课余时间中，尽自己最大的能力和时间去及时补足自己的知识缺口来应对意料之外的工作请求。 -
2.4.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进？
我们学到了如何将工作的轻重缓急给分配清楚，如果重来一遍，我们会在前端多安排一些人手，并且安排指定的人员去负责前后端的对接。
2.5 设计/实现
-
2.5.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人吗？
本次的设计工作是根据组内分工在整个冲刺进行设计优化的，界面由前端人员完成，在整个过程中，根据美观及适应用户体验为原则进行修改迭代，所以时间与人员都是比较合适的。服务器、数据库等由后端人员实现，按照我们需要完成的功能进行，所以时间与人员也都是比较合适的。 -
2.5.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有碰到模棱两可的情况，组内同学一起讨论确定方案。
前端组讨论以后，决定要使界面更加符合主题以及吸引眼球为开发方向。
后端组的成员也讨论确定了数据库、服务器、接口的设计的方向，并进行了明确的分工。 -
2.5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效吗？
本次同样使用了uml来帮助设计和实现，时间很紧但效果不错。 -
2.5.4 比较项目开始的UML文档和现在的状态有什么区别？这些区别是如何产生的？是否要更新UML文档？
到现在为止与之前的有很大区别。
在项目开发过程中，我们希望将项目更好的制作与呈现，所以对制作的成功进行更加细致的优化及大幅的整改，故需要进行更新，以更好的辅助开发。 -
2.5.5 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的Bug？为什么我们在设计/开发的时候没有想到这些情况？
在开发过程中，前端组在接口制作以及部分界面布置上出现了一些问题，后端组在服务器部署及数据库连接上出现了一些问题。
因为无论在接口还是服务器或是数据库大家都是在学习中进行，有很多不清楚的地方，所以难免会有bug。 -
2.5.6 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
由于本周时间仓促，并未进行严格的代码复审。但在开发过程中前后端的同学有代码进行一些有意识规范，所以规范情况还可以，仍需专门优化。 -
2.5.7 我们学到了什么？如果历史重来一遍，我们会做什么改进？
我们在这一次的冲刺学到了很多，设计方面，前端学会了调用更多的方法来实现更加美观的界面，后端学会了更多的知识来完成对接、服务器等的实现，以及大家都学会了更好的安排时间，团队氛围也更加融洽。
如果历史重来一遍，感触还是一样，我们会花更多时间提前学习新的知识，以避免模糊不清的情况影响项目开发进度。
2.6 测试/发布
-
2.6.1 团队是否有一个测试计划？为什么没有？是否进行了正式的验收测试？
本次没有测试计划，算法功能在上一次冲刺已完成大半，本次冲刺重点是界面美化以及服务器的搭载、接口访问。还没有进行正式的验收，还要对项目的页面进行完善以及将数据存入云端。 -
2.6.2 团队是否有测试工具来帮助测试？
使用pycharm专业版自带的性能分析工具进行性能分析。 -
2.6.3 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
不断找同学亲身体验。有用，应扩大用户体验群体。 -
2.6.4 在发布的过程中发现了哪些意外问题？
还没对不同机型适配相对应的APP界面大小 -
2.6.5 我们学到了什么? 如果历史重来一遍, 我们会做什么改进？
我们学到了服务器的搭载，接口的调试，及云端存入数据的流程。如果能重来，我们会重新安排时间，为测试阶段预留充足时间，并且扩大测试群体。
2.7 团队的角色，管理，合作
-
2.7.1 团队的每个角色是如何确定的，是不是人尽其才？
根据每个组员擅长技术和个人能力决定，我们尊重每个组员自己的选择方向。是人尽其才。 -
2.7.2 团队成员之间有互相帮助么？
我们组员之间经常讨论并相互帮助。 -
2.7.3 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
先沟通交流，发现问题所在，如果无法决策的，由组长决定或者投票表决。 -
我感谢柯圳浩对我的帮助，在我对于接下去的任务不知道怎么入手的时候可以给我提醒与帮助。
-
我们学到了什么？如果历史重来一遍，我们会做哪些改进？
团队沟通交流非常重要，如果历史重来，我们会更加注重这一方面。
2.8 总结
- 2.8.1 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
团队目前处于CMM/CMMI的第三级已定义级和第四级已管理级之间。 - 2.8.2 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
团队目前处于规范和创造之间。 - 2.8.3 你觉得团队在这个里程碑相比前一个里程碑有什么改进？
前后端对接成功，开发能力得到提升，团队之间的配合更加紧密，氛围更加融洽。 - 2.8.4 你觉得目前最需要改进的一个方面是什么？
目前最需要改进的方面是时间安排，因为12月考试很多。 - 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则？ 请列出具体的事例。
原则4:项目过程中，业务人员与开发人员必须在一起。
原则5:要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
原则6:无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
我们团队会在活动室共同开发、互相交流。
对于项目人员，我们会给予提高贡献度的奖励，以及提供相应的支持。