第05组 Alpha冲刺 总结
Alpha冲刺——总结
一、基本情况
答辩总结
组员都比较积极，开发的过程氛围很好，一群人聚集在一起，也积极讨论学习，用从繁重的学业中挤出来的时间做出了成果。每个组的开发的难易度和成员实力都有差距，也不必过于比较，力求每次都能超越自己，让自己问心无愧。我们组的开发周期持续非常长，这只是第一阶段的总结，组员都很棒，但是未来的开发路会更加艰辛，也坚信我们会做到更好。
讨论图片
Alpha阶段的工作流程分为前端开发和后端开发
- 前端分为界面美观设计和界面交互实现
界面设计：柯圳浩，杨泽远，金昌鸿，杨锋夏
界面交互：高菲，郭畅、白霖 - 后端分为推荐算法和音乐分类
推荐算法：郑烜，马向超
音乐分类：苏镜泽，林坤贤
| 成员 | 分工 | 比例 |
| 郑烜 | 统筹，音乐处理，方法指导 | 10% |
| 高菲 | 整体性交互，测试 | 13% |
| 郭畅 | 底部导航栏切换实现，制作了几个页面，实现多个按钮点击 | 9% |
| 白霖 | 界面制作，并实现了音乐播放功能 | 9% |
| 柯圳浩 | 运动界面及功能实现 | 9% |
| 杨泽远 | 歌单页面，主界面，加点多个按钮实现 | 8% |
| 金昌鸿 | 心率界面及动态实现 | 9% |
| 马向超 | 相似度推荐算法，答辩人 | 10% |
| 林坤贤 | 音乐参数向量构建，PPT制作 | 8% |
| 苏镜泽 | 音乐分类模型优化 | 10% |
| 杨锋夏 | 反馈界面 | 5% |
测试组提问：可以过滤掉不喜欢的歌/歌手吗？
Alpha阶段的产品暂时没实现这个功能，以后的版本预期实现在每次使用运动音乐功能结束后的反馈界面对用户进行调查，选择歌曲喜欢或者不感兴趣，达到标记喜欢歌曲和过滤歌曲的功能，过滤歌手需要的条件太大，不考虑实现
二、总结思考
2.1 设想和目标
-
2.1.1 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
解决运动时音乐推荐的问题；软件是面向运动听歌或者日常听歌人群而定义的；典型用户为资深的运动听歌发烧友，场景即为运动场所或者用于日常听歌 -
2.1.2 我们达到目标了么(原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么？)
可以算是达到了我们α冲刺的基本目标，原计划的功能几乎全部实现，除了运动圈的功能略微鸡肋打算留在后面有空再做，同时所有功能都在原计划时间交付了，用户暂时还是我们开发人员，等待推出后会有用户数量增加。 -
2.1.3 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
在软件推出之前用户暂时为我们开发人员，所以和我们预先的设想一致，而我们团队一直都在朝着我们的目标前进，同时也确实离我们的目标更近了。 -
2.1.4 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
APP的开发相较于小程序而言更加困难，而以我们目前的能力在做的过程中有些许困难，所以重来一遍我们可能会选择小程序和APP开发双线程一起进行。
2.2 计划
-
2.2.1 是否有充足的时间来做计划？
我们团队有很充足的时间做计划，在学期初确定选题之后就制定了初步项目计划和分工，有充足的时间进行调度和进一步修改计划。 -
2.2.2 团队在计划阶段是如何解决同事们对于计划单不同意见的？
我们团队队内氛围友好，民主气氛浓厚，在有不同的意见时会提出，并在团队共同讨论商议。 -
2.2.3 你原计划的工作是否最后都做完了？如果没有做完的，为什么？
前端和后端各自的原计划的内容大部分完成了，但是由于计划赶不上变化，解决一个问题时会衍生出新的问题，加之前后端对接难度较大，目前对接部分暂时未完成。 -
2.2.4 有没有发现你做了一些事后发现没必要或没多大价值的事？
由于组内分工得当，计划较为精确，所以并没有出现“做无用功”的情况。 -
2.2.5 是否每一项任务都有清楚定义和衡量的交付件？
在真正开始项目之前，我们对项目进行过程中将会遇到的各项任务不能够做到完全的估计和衡量，随着项目的推进，我们对于各项任务的认识愈发得清晰了起来，基本上对每一项的任务都做出了清楚的定义并制定了衡量的交付件。 -
2.2.6 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
前端组的意外和风险：由于专业原因，组内没有成员有曾经学习过有关Android开发的任何知识，Android开发的难度超出了我们的想象，需要从0学起，但是通过人员分配调度对前端的项目进展起到了较大的帮助。
后端组的意外和风险：初始训练数据的不足导致音乐算法推荐精度不高。 -
2.2.7 在计划中有没有留下缓冲区，缓冲区有作用么？
我们在计划上预留下了两天左右的时间缓冲区，这个预留的缓冲区对我们项目的最终完成起了很大的作用。 -
2.2.8 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划中将会留下更多的时间缓冲区用以解决发生在意料之外的情况，以及更好地完善产品；进一步改善任务的分工安排，优化团队间的合作， 提高团队的工作效率，避免不必要的“加班”。 -
2.2.9 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在这次团队冲刺中， 我们团队协力完成了Alpha版本的发布，在这一过程中，我们不仅在各自研究的前后端领域学到了全新的知识，还认识到了好的计划调度和团队合作对整个项目进度的重要性。如果历史重来一遍，我们会事先做好更加完善的计划，在前端组或许不会选择Android开发而是选择更为便利高效的微信小程序，并在项目进行中根据实际情况及时对计划做出修正。
2.3 资源
-
2.3.1 我们有足够的资源来完成各项任务么？
1.资源稍有不足。
2.在前端开发上大家还没有开发经验，开发人员全力以赴学习，但对于各方面的实现较为缓慢。
3.在后端开发上有较好的基础，对Python语言较为熟悉，对机器学习算法有一定经验，后面将进一步推进与前端对接。
4.在Alpha阶段，尽力完成了app雏形与后端推荐算法，美化界面、优化算法计划Beta版进一步推进。 -
2.3.2 各项任务所需的时间和其他资源是如何估计的，精度如何？
对于不同任务根据人员学习能力，编程能力估计时间、资源。精度不太准确，实际开发中，在前期的环境搭建上遇到一些问题耗费一定时间，导致部分功能实现缓慢。 -
2.3.3 测试的时间，人力和软件/硬件资源是否足够？对于那些不需要编程的资源 (美工设计/文案)是否低估难度？
1.测试的时间，人力和软件/硬件资源不足够。Alpha阶段的测试暂时由任务负责人员自行测试，还存在些bug需要花时间修缮。
2.没有低估难度，在不需要编程的资源 (美工设计/文案)上，有专门人员进行，同时文案设计上全组通力配合，进行顺利。 -
2.3.4 你有没有感到你做的事情可以让别人来做（更有效率）？
没有，在任务分工上人员分配合理，各人员在负责任务上有效的发挥自己长处。 -
2.3.5 有什么经验教训？ 如果历史重来一遍, 我们会做什么改进？
经验教训：及时的线下技术交流、功能实现讨论能进一步有效推进开发的进度，同时提高开发的完成质量。
改进：任务开发人员及时进行讨论帮助，加快解决相互之间的一些问题，减少在相似问题上所耗费的时间。
2.4 变更管理
-
2.4.1 每个相关的员工都及时知道了变更的消息？
每个相关组员都能够及时知道变更的消息。 -
2.4.2 我们采用了什么办法决定“推迟”和“必须实现”的功能？
我们根据产品完整性的需求来决定“必须实现”的功能，而将耗时长，且非核心的功能进行“推迟”。 -
2.4.3 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？
我们项目的出口条件是能够推荐出歌曲并播放出来。 -
2.4.4 对于可能的变更是否能制定应急计划？
对于可能的变更我们有制定应急计划，我们有先做出一个保底的成果，然后再在此基础上进行更进一步的学习与工作。 -
2.4.5 员工是否能够有效地处理意料之外的工作请求？
我们组员能够及时补足自己的知识缺口去应对意料之外的工作请求。 -
2.4.6 我们学到了什么? 如果历史重来一遍, 我们会做什么改进？
我们学到了如何将工作的轻重缓急给分配清楚，如果重来一遍，我们会更加及时的根据任务的重要性与难易程度来合理变更组员的工作任务。
2.5 设计/实现
-
2.5.1 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人吗？
1.原型设计工作是从制作原型设计开始的，最初版的设计是由柯圳浩同学制作，在项目开发的过程中，主要是由前端开发人员，大体模型按照原型设计制作，在制作过程中根据实际情况进行优化与修改迭代，所以时间与人员都是比较合适的。
2.数据库与算法设计是由后端开发同学，商量开发实现的，大体思路按照我们APP的需求进行跟进更新，所以时间与人员也都是比较合适的。 -
2.5.2 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
有碰到模棱两可的情况，团队一起商量一步一步统一想法进行解决。前端组讨论以后，决定页面调整以简洁清晰美观便捷为开发方向。后端组的成员也通过交流和讨论确定了数据库与算法的设计的方向，并进行了明确的分工。 -
2.5.3 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML，或者其他工具来帮助设计和实现？这些工具有效吗？
使用了uml来帮助设计和实现，效果不错。 -
2.5.4 比较项目开始的UML文档和现在的状态有什么区别？这些区别是如何产生的？是否要更新UML文档？
目前还是有一些区别的。在项目开发过程中，我们希望将项目更好的制作与呈现，所以对制作的成功进行初步优化，故需要进行更新，以更好的辅助开发。 -
2.5.5 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的Bug？为什么我们在设计/开发的时候没有想到这些情况？
在开发过程中，出现了许多bug，前端组在底部栏与页面之间的切换已经歌曲播放方面出现了bug，后端组歌曲搜索功能必须一模一样，没有模糊查询，设计开发的时候光想着功能主体的实现，细节没有考虑到，获取副歌片段有些歌曲会获取不到而导致算法会直接报错，以及前后端对接方面出现难题。因为大家都是第一次接触开发APP，许多知识需要学习，会有模糊与不懂的地方，对于前后端交互也比较模糊。 -
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 我们学到了什么? 如果历史重来一遍, 我们会做什么改进？
学到了Android的基础开发，移动端Android界面实现和接口对接，接口设计，后端算法实现。如果能重来，我们会重新分配好分工，安排更合理的开发与测试计划，不造成“资源浪费”。
2.7 团队的角色，管理，合作
-
2.7.1 团队的每个角色是如何确定的，是不是人尽其才？
1.项目经理这个角色是认为自己有管理能力并且能够积极督促团队成员的，有良好的与团队成员沟通的能力。
2.前端开发是根据成员的兴趣意愿、以及团队需求来确定的。
3.后端开发也是根据学习兴趣以及能力来确定的。
4.可以说是团队成员都是人尽其才，分配得体。 -
2.7.2 团队成员之间有互相帮助么？
互帮互助的情况经常出现，因为都是第一次学习app开发，大家共同学习，互相分享经验、教程，一起解决了很多安装、写代码上的问题。 -
2.7.3 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
当出现项目管理、合作方面的问题时，团队也会积极组织开会讨论，发表各自的看法，通过投票或其他方式确定最终的解决方案。 -
2.7.4 我们学到了什么？如果历史重来一遍，我们会做哪些改进？
我们学到了一些团队协作的精神，如果历史重来一遍，我们会在一开始给前端多分配一些人。
2.8 总结
- 2.8.1 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
团队目前已经达到了CMM/CMMI的第二级，可重复级。 - 2.8.2 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段？
团队目前处于磨合和规范之间。 - 2.8.3 你觉得团队在这个里程碑相比前一个里程碑有什么改进？
开发能力得到提升，团队之间的配合更加紧密，氛围更加融洽。 - 2.8.4 你觉得目前最需要改进的一个方面是什么？
目前最需要改进的方面是时间安排，因为考试即将到来。 - 2.8.5 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则？ 请列出具体的事例。
原则4:项目过程中，业务人员与开发人员必须在一起。
原则5:要善于激励项目人员，给他们以所需要的环境和支持，并相信他们能够完成任务。
原则6:无论是团队内还是团队间，最有效的沟通方法是面对面的交谈。
我们团队会在活动室共同开发、互相交流。
对于项目人员，我们会给予提高贡献度的奖励，以及提供相应的支持。
