8组-Alpha冲刺-总结

https://www.cnblogs.com/xiao-qingjiang/p/15575571.html

一、基本情况

现场答辩总结：
根据老师的指导和建议，我们充分认识到了我们的不足。
首先是工作量不足，在这次冲刺中我们并没有很好的完成这个项目，前端效果还需要进一步改善，后端的接口还需要尽快和前端交互，还有展示的形式上也需要改进，需要展示出产品使用的情况，而不是空洞的PPT，非常感谢老师和同学们的建议。

全组讨论的照片

评估团队中每个人对本次作业的贡献比例，描述为本次作业的工作流程、组员分工、组员工作量比例（禁止一锅端平的情况，如果没有评估，组长得分减 50%）

姓名	分工	预计贡献比例
肖清江	产品经理	7%
刘璐瑀	策划组	8%
赵威威	策划组	6%
黄慧卿	策划组	8%
刘凌斌	后端	11%
李忱轩	后端	13%
陈松庆	后端	11%
黄海涛	前端	13%
田剑心	前端	10%
杨潮湧	前端	13%

二、总结思考

2.2.1 设想和目标（4分）

• 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述 ？

  • 解决的问题及定义：为有强烈使用需求的外地务工人员及其子女，以及缺乏学习环境和学习指导的在外闽南青少年提供学习闽南语的辅助平台
  • 典型用户：有强烈使用需求的外地务工人员及其子女，以及缺乏学习环境和学习指导的在外闽南青少年
  • 典型场景：使用者打开软件便可看有关闽南语的推文了解闽南文化，也可以打开闽南乡音歌曲感受闽南风情，还可以读出自己不理解的闽南语进行查词学习其中文意思，闲暇之余还可模仿闽南歌曲等进行个人作品录制，录制之后可以得到其有关读音准确性的评分。

• 我们达到目标了么?（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
  目标尚未完全完成，需要下一阶段进一步完成。原计划功能全部完成，只是在界面切换的流畅性，数据库访问的速度、云的部署等不尽人意，需要进一步优化代码。
  有按照原计划交付时间交付，原计划达到的用户数量尚未达到，因为还未完全上线，所以用户数量尚未达到原定目标。

• 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
  由于产品未上线，还未推广和产生用户，难以评估是否用户对重要功能的接受程度和我们事先的预想一致。
  离目标更近了，功能实现和预想的没有太大偏差，很快应该就能够上线。

• 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
  UI设计较为手忙脚乱，如果历史重来一遍，会在一开始的时候先确定好界面设计的风格，再有所针对性地去寻找相关素材以便后续进行相关设计。

2.2.2 计划（5分）

• 是否有充足的时间来做计划?
  有，计划的时间还是比较充足的，可以进行相对细致的规划。

• 团队在计划阶段是如何解决组员对于计划的不同意见的？
  经过协商讨论，如果认为某计划不可行，欢迎提出理由和新的方案，其他成员共同思考，最终得到能让大家认可并愿意执行的计划。

• 原计划的工作是否最后都做完了? 如果有没做完的，为什么?
  原计划的工作成功完成，没有未完成的，但完成质量不够高，接下来还需要进一步的优化。

• 有没有发现做了一些之后看来没必要或没多大价值的事?
  有些需要大家共同参与的博客都是让成员发文档给负责人，也许直接发聊天框可能更方便哈哈，就不需要打开文件了（懒人操作）。

• 是否每一项任务都有清楚定义和衡量的交付件?
  每一项任务都有清楚定义，并给了每项任务的审核指标，完成任务需要达到审核指标。

• 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
  项目的一些子任务的交付时间和原计划有出入，主要是由于当时没有考虑到这两周考试很多（零零总总加起来有四门考试，大部分同学都有一到两门），因此考试的备考时间没有考虑到计划里，导致后期的进度比较赶。

• 在计划中有没有留下缓冲区，缓冲区有作用么?
  留下了一天的缓冲区用于debug，但这个缓冲区被考试备考时间占用了，似乎没有发挥原有的作用，但缓冲了考试备考时间。

• 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
  结合接下来时间的考试、其他课程的作业安排以及同学们的比赛或训练情况等进行进一步更细致化的规划，留出合适的缓冲区，在紧急时候可能会开展加班。

• 学到了什么? 如果历史重来一遍, 会做什么改进?
  配置云服务器的难度预估不足，导致预留的时间不足，出现了一些意外之外的配置问题，如果历史重来，会留出更多的缓冲时间以免出现意料之外的问题。

2.2.3 资源（3分）

• 我们有足够的资源来完成各项任务么?
  有，我们的任务所需的资源都是可获取且容易获取的，可能比较紧张的资源就是组员们的时间资源了，毕竟这学期课多考试也多，还有其他课程有大作业。

• 各项任务所需的时间和其他资源是如何估计的，精度如何?
  会根据每项任务先进行评估，评估的指标包括完成这项任务是否需要学习未掌握的技术、学习的时间成本、完成的时间成本、以及完成任务需要哪些资源（如框架、接口以及其他成员需要提供哪些资源（如接口）等）。

• 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
  人力和软件/硬件资源是足够的，而测试时间比较紧张，测试并不是特别完善。
  不需要编程的资源 (美工设计/文案)都分配了比较充足的人员进行完成和审核，总体还是比较合理的。

• 你有没有感到你做的事情可以让别人来做（更有效率）?
  可能让其他人做效果会更好，毕竟我的文字功底挺一般的。

• 有什么经验教训? 如果历史重来一遍, 会做什么改进?
  一开始的云服务器没有先去处理，直到需要部署才开始去找，导致了进度有点紧张，再加上部署过程遇到了一点问题，如果历史重来，会在部署前做好前期准备工作，预留充足的时间进行部署。

2.2.4 变更管理（4分）

• 每个相关的员工都及时知道了变更的消息?
  有，每次都会通过qq群进行通知，对于没有看到的同学会私聊提醒。

• 我们采用了什么办法决定“推迟”和“必须实现”的功能?
  根据紧急程度和依赖关系进行决定，比如某个功能的实现必须在前一个功能实现的基础上开展（即该功能依赖前一个功能），那么该“前一个功能”就是必须实现的；
  如果某个功能与其他功能无关且并不紧急，便是可以“推迟”。

• 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
  针对每个小功能做出了清晰的功能出口条件，但对整个项目的出口条件还未给出明确的定义。

• 对于可能的变更是否能制定应急计划?
  理论上是能的，但在执行过程中似乎这个应急计划并不是很有效，因为我们这次的工作便不是完成的很好，希望在接下来的工作里能够做好更合理更有效的应急计划。

• 组员是否能够有效地处理意料之外的工作请求？
  这取决于组员们的时间安排，如果最近有考试的话就有点难度，如果没有都是可以有效处理意料之外的工作请求的。

• 学到了什么? 如果历史重来一遍, 会做什么改进?
  做好应急备用计划，以免不时之需。

2.2.5 设计/实现（4分）

• 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
  设计工作有产品经理，前端、后端、UI的负责人在充分吸取组内成员的意见后进行讨论完成的，在alpha冲刺的第一天完成总体规划，第二天完成较为细致的规划。
  是合适的时间，也是合适的人。

• 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
  有，经过讨论后确定采纳一种确定的方案。

• 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
  有的，起了很大的作用，使得我们的工作更加规范。

• 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
  有一定的区别，区别主要是在实施过程中有一些之前设计没有考虑周全的事情，在实践之后才发现的。需要部分改动并更新UML文档。

• 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
  部署阶段产生bug较多，因为大家对部署的原理不是很了解，主要是参考网上教程和博客进行部署，而网上的质量参差不齐，所以出现了比较多的bug。
  还未成功发布，非常抱歉。
  设计/开发时这会比较简单，跟着教程依葫芦画瓢就可以，但事实上还是有一定难度的。

• 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
  进行功能测试和代码测试，有严格执行代码规范。

• 学到了什么? 如果历史重来一遍, 我们会做什么改进?
  一个成功的项目需要在设计阶段就做好规范和细节考虑，如果历史重来，我们会更好地做好规范（包括代码和文档格式）和细节考虑（包括一些具体的技术和功能可能遇到的问题），做好预备。

2.2.6 测试/发布（3分）

• 团队是否有一个测试计划？为什么没有？ 是否进行了正式的验收测试？
  这个暂未考虑，因为我们还没有成功部署，暂时没有考虑到测试的详细计划，还未进行正式的验收测试。

• 团队是否有测试工具来帮助测试？
  有选取几个比较主流的工具，但还未开展工作，还未确定最终选取哪个工具。

• 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
  团队还未完成软件，很抱歉还没开始测试。

• 在发布的过程中发现了哪些意外问题？
  很抱歉还未成功发布，目前前后端交互还未完全完成，我们接下来会抓紧完成工作的。

• 学到了什么? 如果历史重来一遍, 会做什么改进?
  更好地规划时间，加快进度，做好测试工具的选择和测试方案，防止测试阶段出现差错。

2.2.7 团队的角色，管理，合作（3分）

• 团队的每个角色是如何确定的，是不是人尽其才？
  根据大家所拥有的技术栈和以往的实践经验，以及大家未来想要发展的岗位来进行确定角色，做到了人尽其才，也复合大家未来发展的需求。

• 团队成员之间有互相帮助么？
  有的，当有同学进度难以赶上时，空闲同学会主动伸出援手。

• 当出现项目管理、合作方面的问题时，团队成员如何解决问题？ 每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

肖清江：
我非常感谢赵威威对我的帮助，因为11.12晚上我有考试，而那天晚上也要提交软工博客，感谢她帮我分担了那一晚上的软工博客的撰写工作。

李忱轩：
我十分感谢陈松庆同学对我的帮助，在云服务器环境配置出问题的时候，他与我攻克难关，一同寻找解决办法，让我的工作压力瞬间少了很多，同时感谢刘凌斌和陈松庆同学在团队分工上的配合，让后端小团队工作进展顺利。

陈松庆：
我十分感谢忱轩同学对我的帮助，我对许多东西都是十分迷茫的，他给我指引了方向。让我有了比较明确的工作目标。

刘凌斌：
我很感谢李忱轩同学对我的帮助，这是我第一次参与到后端的工作之中，对后端应该是一直处于一知半解的状态，感谢李忱轩同学，帮助我走进后端的世界。

杨潮湧：
我感谢黄海涛对我的帮助。
因为某件个具体的事情：在最开始写静态界面时，由于第一次上手wxml和wxss，我其实没什么头绪，后来去请教了海涛，才顺利完成了最初的编程设计。

黄海涛：
我感谢刘璐瑀对我的帮助。在我们的相互交流修改前端界面时，避免ui设计和前端界面不符。

田剑心：
我感谢杨潮涌对我的帮助，因为某个具体的事情：在项目开始之前，杨同学把整个前端的具体工作罗利出来，帮助成员做了规划，如果没有他的安排，我感觉可能做出来的成果会更加糟糕。

赵威威：
我感谢肖清江对我的帮助，因为在制作PPT的过程中，有一些部分不知道在怎么部署，他详细地为我解答，十分感谢。明白了考虑事情要全面。

刘璐瑀：
我感谢黄慧卿对我的帮助，我们一起寻找素材、确定界面设计风格、研究怎么使用PS。

黄慧卿：
我感谢刘璐瑀对我的帮助，我们一起做ppt，一起寻找素材以及一起设计界面。

• 学到了什么? 如果历史重来一遍, 会做什么改进?
  时间和进度安排不够合理，如果历史重来，会更好地进行规划和推进进度。

2.2.8 总结（4分）

肖清江：
这次的alpha冲刺中，我产品经理的角色其实不是很合格，没有做好前期的规划和规范，在接下来的工作中，我会更好地做好规划和规范，并在过程中实时反省是否哪里还需要改善以提高效率和效果。

李忱轩：
由于之前有过一些经验，以为配置云服务器特别简单，但是在实际上遇到了大量的环境配置问题，在本地成功运行的代码，放到ubuntu服务器上就一直报错，在Alpha冲刺中，我学了很多东西，对云服务器ubuntu配置和gunicorn的部署有所了解，并且成功实现了部署，比较重要的是了解了以前以为很简单的东西，好在团队整体实力偏强，让我在团队合作中总能寻求帮助并且获得解决。

陈松庆：
由于我自身的心态，直接或间接地导致一些工作进展受到了限制，我在以后的生活里应该有所改变。在Alpha冲刺中，我学了很多东西，了解了后端的开发流程，加深了对数据库可视化工具的使用理解，更重要的是意识到了自己心态方面的不足。好在队友们比较猛，能填住我自己失误挖的坑（砰砰砰）。

刘凌斌：
首先，我要和我的队友们说一声对不起，因为考试还有学生工作的原因，再Alpha冲刺阶段，在软工方面投入时间大大减少，我们小组没法按时交付Alpha冲刺成果，负责数据库的我有不可推卸的责任。但是，在Alpha冲刺中，我学到了很多东西，对数据库的操作原理更加熟悉，也更能灵活运用数据库完成一些功能，也学会了提高个人的工作效率，两天一次的冲刺还是极为惊险刺激，6次的ddl的生产力也是惊人的。最后，还是要感谢我的队友们。

杨潮湧：
第一次写小程序，虽然一切都是新的，但在同组同学的帮助和自身的努力下，还是在这次冲刺里学到了不少东西。同时，我也对于前端的这个角色以及前端与UI、后端之间的关系有了更清晰、更深层次的理解。同时我也发现，人的精力是有限的，但有的时候，你不逼一逼自己，就永远没法想象，自己敲代码赶ddl熬到一两点，会越来越精神（逃）。当然，虽然我很感激这段“充实”的生活，但是但是，熬夜是真的伤身体，希望我以后能继续提升自己的学习效率，该休息的时候，真的还是好好休息为好。

田剑心：
通过本次阿尔法冲刺，完成了前端大部分的功能，但是由于考试等因素，导致时间上预估有所出入，因此前端部分细节做到不够好。其次，在前后端交接上，一下接口参数上没交接好，导致工作进展的很忙。总体而言，感觉自己做得不够好。对于个人能力而言，或多或少的得到了提高。在后续的工作中，应努力做的更好。

黄海涛：
第一次这样和很多队友做一个大作业，大家前期交流都不太放得开，进度不快，但是慢慢就加快了。然后我是前端的一员，感觉自己前端完成的不算太好，因为之前学期都没有学过HTML，css和js。所以得先花挺多时间来学新技术，感觉这样的过程很折磨，不能一蹴而就的完成分配的任务，虽然动力十足，但是压力更大。

赵威威：
ALPHA冲刺阶段的时间我上网复习了剪视频的技巧，重新捡起大一的基础，看了许多教程，自己上手后发觉还可以，并没有自己想象中那么难。以及在网上找了一些PPT的模板，还算比较满意。由于时间比较紧，因此本次汇报的视频剪得比较粗糙，汇报PPT中一些其他因素也没有考虑到，希望这些问题都能在BETA汇报阶段解决。也希望BETA汇报的PPT做的更加全面，更加有趣。

刘璐瑀：
只在上次结对编程作业中接触了UI设计，刚开始设计此次团队编程作业时也是手忙脚乱的。一开始设计出来的界面不尽人意，后面多次推翻重来，最终设计出了自己感觉比较满意的页面。在周六答辩时，被柯老板“一顿痛批”，说一看就知道是学生作品，不够成熟，以为又要重来，幸好后面给他看了我们的设计图，通过了柯老板的检查，但是就要麻烦负责前端的同学再次加工润色了。在与前端人员的沟通交流上存在一定的问题，应该要和他们及时沟通交流，保证一定的还原度。

黄慧卿：
原先不太会使用ps，只会最简单的填充颜色，经过这次ui设计，对ps的使用更加熟练。虽然大部分界面都并不复杂，但是如何让界面看起来更协调，更舒服也并不太容易，体会到了每个角色都有辛苦的地方。周六答辩时我们的界面被柯老板痛批”过于粗糙“，我们以为还要再返工一次，一整个大慌张，幸好最后柯老板认可了我们的ui部分，只能辛苦前端队友提高还原度了。