• beta冲刺——问题汇总


    1、设想和目标

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

    • 让用户能高效获取热点话题及解决方案,成为学生的校园锦囊,并保证讨论的自由性和隐私性。

    • 用户典型场景:
      1.用户想获取校园生活中碰到的问题的解决方案,可以通过搜索或通过标签来找到目标信息。
      2.用户可以对他人抛出的话题进行解答或者评论。
      3.在首页展示热度高的话题,减少用户的检索频率。
      4.用户还可收藏话题或新闻方便以后查看
      5.用户可以按课程或教师查询课程

    • 项目达到目标了么(原计划的功能做到了几个?在原计划之上是否有所拓展)

      原计划功能已完成项:

    • 用户端:
      用户登录;带标签的话题的发布、查看;话题的评论,以及对评论进行回复;
      按课程名或教师名两种方式查询课程;评价课程;
      收藏话题或新闻,并可以管理收藏夹

    • 管理员端:
      登录;话题的审核;评论及回复的审核;
      课程管理;标签管理;
      原计划未完成项:
      用户头像修改
      在原计划上未做拓展

    • 设想用户量是多少, 用户对重要功能的接受程度和我们事先的预想一致么?

    面向的用户主要是福大在校学生,设想的用户量大约是300人。根据用户调查报告,用户对软件整体满意度为80.88%

    • 有什么经验教训? 如果历史重来一遍,我们会做什么改进?

    • 对扩展功能的实施计划不明确
      改进:小组复审相关模块设计文档,对其进行估计以及任务的分配
    • 前后端之间对接口的制定不够细致,导致交互时出现400或500错误
      改进: 前后端之间用接口设计文档对接,制定统一且细致的标准

    2、计划

    • 和alpha阶段相比,每天是否时间规划的更好?

    相比alpha阶段,时间规划上的进步有:冲刺前安排学习时间,冲刺提早开始,冲刺之初确定详细计划。不足之处有:忽视项目整合打包的时间,进度把控频次降低。

    • 你们原计划的工作是否最后都做完了? 如果有没做完的,为什么?

    用户个人信息修改未完成,因为对图片存储操作不是很懂,项目部署后图片的存储方式不确定。

    • 项目是否出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?

    出现的意外

    • 前端调试时,后台返回的数据重复且难处理,前端都需要对其重新包装,造成代码重复。
    • 软件部署出了服务器内存不足,项目打包后远程数据库无法访问等难解决的问题
    • 整合时发现功能不完整,导致工作量增加

    为什么没有估计到
    接口设计没有考虑周全
    只专注于开发而忽视了部署和设计调整

    • 我们学到了什么? 如果重来一遍, 我们会做什么改进?

    • 冲刺前对设计方案再讨论,再修改

    • 前后端对交互应该用更细化的接口约束

    • 对非编程的工作也要预留出足够的时间

    3、资源

    • 有足够的资源(可以是时间、开发资源等)来完成各项任务么?

      由于开始时间较早,以及除了有变动的成员,其他成员负责的模块与他们在alpha冲刺中做的相近。故在时间和人力上我们相当充足,
    • 各项任务所需的时间和其他资源是如何估计的,精度如何?

      对各模块的耗时估计主要是根据工作量及难易度粗略估计。
    • 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

      由于本轮冲刺在管理员端新采用了Element-UI,省去一些美工的时间,美工方面我们估计所用时间较少,但是发现仍有需要完善的地方。
      但是我们忽视了项目打包,部署,发布的时间估计
    • 变更的组员工作如何?如果未变更是否项目完成效率会更高?变更的组员学到了什么?对于可能的变更是否能制定应急计划?


      详细请看换组交接博客

    4、设计、实现工作

    • 项目是否经历重构?为什么需要重构?

      没有经历重构。

    • 比较项目开始的UML文档和现在的状态有什么区别?

    • 用例发生的变化:
      删除未考虑周全的附加功能:如用户删除自己发布的话题,实现就需要新增用户对自己已发布话题的管理功能模块。以及删除实际意义不大的用例:管理员回复。

    • 数据库设计的变化:
      优化设计使之更符合实际项目,比如我们删除了待审核的评论和话题表改为在评论表和话题表中新增字段原来标记审核状态。

    • 什么功能产生的Bug最多,为什么我们在设计/开发的时候没有想到这些情况?

      后台课程管理及收藏夹,因为数据库表关联较多,部分情况没有考虑清楚

    5、测试发布

    • 团队是否有一个测试计划?

      除了指定测试固定发负责人、负责单元和时间之外,根据项目的进展情况调整测试的人员及计划。

    • 团队是否有测试工具来帮助测试?团队是如何测量并跟踪软件的效能的?

      • 主要使用IntelliJ IDEA这个集成开发环境自带的工具http client以及postman进行接口测试。

      • 使用IntelliJ IDEA集成开发环境可以添加的插件JProfiler进行性能监控。

    • 我们学到了什么? 如果重来一遍, 我们会做什么改进?

      用多种测试工具进行测试;
      采用压力测试等多种测试

    6、团队角色、管理、合作

    • 团队的每个角色是如何确定的,是不是人尽其才?

      在alpha轮做什么工作内容,在beta轮就做相近的工作内容。
      结合每个人的能力和发展方向确定角色。
    • 团队成员之间有互相帮助吗?

    • 当出现项目管理、合作方面的问题时,团队成员如何解决问题?

      每当团队合作出现分歧时,主要通过集体讨论,并回溯设计图,结合项目现状解决分歧。

    7、组员自我总结

    • 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

      • 一级到二级的过渡区间
      • 团队状态处于刚刚度过磨合期
    • 组员自我总结请看总结博客

    8、软件工程的质量

    • 代码质量如何提高?

      学习并使用代码审查工具
      对输入和输出更严格的规范
      建立代码复审机制
    • 项目的质量如何提高?

      总结之前的经验教训
      制定粒度更细的计划
      为所有可能出现的风险(包括非编程工作)做出预估
      前后端之间的交互应当由详细文档约定
    • 管理与领导如何提高?

      充分利用项目管理工具
      定期组织例会,总结进展及制定计划
      严格执行计划
      引入奖惩机制(如奖励可以是小零食,惩罚可以是当众表演)
  • 相关阅读:
    共望明月
    游丽都公园有感
    创业天才尼尔曼迈向成功的十四个原则
    赵娜(帮别人名字作诗)
    小幽默也有大道理:哲理幽默15则
    夜游草堂
    成功就是简单的事情重复做、重复做
    千万别入错行 15条人生建议
    听一堂课值三十九万,把它看完,定会有收获!
    VIEW:X$KCCRSControlfile Record Section directory (8.0 8.1)
  • 原文地址:https://www.cnblogs.com/deadlinegods/p/13172271.html
Copyright © 2020-2023  润新知