其他分享
首页 > 其他分享> > 10组-Beta冲刺-总结

10组-Beta冲刺-总结

作者:互联网

组长博客链接

一、基本情况

现场答辩总结

  1. 项目总体进展充分
  2. 应该更深度地去挖掘爬取下来的大量数据潜在的含义
  3. 在柯老师的建议下、会专门写一篇博客分享慢慢买网站的爬取克服过程。

全组讨论的照片

本次作业贡献比例评估

成员名 本次作业具体工作 贡献度
苏伟煌 团队选题报告PPT审核、博客撰写 12%
林泽熙 修改报告、完善需求分析 9%
黄艇淞 报告排版处理 9%
陈本源 成果展示整理(答辩用) 10%
陈硕 成果展示整理(答辩用) 10%
翁敏 PPT制作 10.03%
石致彬 统计组员心得感受 9.97%
林志煌 统计组员心得感受 8%
王毅萍 原型设计制作、类图整理 9.98%
唐劲霆 修改报告、完善需求分析 10.02%

工作流程

二、总结思考

2.2.1 设想和目标

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

    我们的软件需要收集药品的数据,对药品的价格进行分析可视化,尽量让药品的价格信息变得透明。目前来看,我们的定义主体上还是比较清楚地,边界比较明显。对于典型用户和典型场景也有比较清晰的描述。

  2. 我们达到目标了么?(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)

    我们的目标大部分完成了,还剩下一些部分需要进行完善,原计划的功能基本都完成了,比如要求的数据的爬取,前端的可视化图展示等。目前还没有进行部署,用户数量为0,暂时没达到原计划用户数量

  3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

    用户量目前为0因为还没部署到服务器,和我们预先设想的暂时不一致,用户对重要功能的接受程度因为还没上线暂时无用户所以还无法调查,但是我们小组成员在进行运行时大部分功能实现的效果还行,我们认为我们正逐渐在靠近目标

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

    会将分工进行细分,具体职责分配到位,以提高开发的效率,推进项目进程。并且要适当提高开会的频率,跟进项目的进度。

2.2.2 计划

  1. 是否有充足的时间来做计划?

    是。虽然有许多组员课程很多考试也很多并且都挤在一块了没什么时间,但是也有几个组员时间较为充裕且愿意为小组花时间来做一些规划。

  2. 团队在计划阶段是如何解决组员对于计划的不同意见的?

    团队成员意见不统一时,我们会多征求意见,集中思考解决方案,尽可能得到一个总体上大家都能接受的结果。团队成员大家都可以相互理解相互体谅,因此也没有出现不可解决的矛盾,大家都能和气地商量解决

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

    没有全部都做完,因为大部分人都需要从头开始学习,学习成本很高,再加上其他课程的学习和考试,导致最后在项目开发的时间较少,暂时没有全部完成所有功能的具体实现

  4. 有没有发现做了一些之后看来没必要或没多大价值的事?

    有。主要是爬取时候的技术方面。

  5. 是否每一项任务都有清楚定义和衡量的交付件?

    是,每一个任务都有最少完成的指标。

  6. 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?

    不是都按照计划进行,出的意外就是服务器配置太过垃圾,而且没有估计到的一个风险是流量消耗太快,因为以前没有过服务器的使用经验所以没预估到

  7. 在计划中有没有留下缓冲区,缓冲区有作用么?

    有。缓冲区可以让项目更有容错率,虽然不能搞定所有但是至少能在ddl前解决一些问题

  8. 将来的计划会做什么修改?(例如:缓冲区的定义,加班)

    将来的计划就是组内大家再冲一波,加个班,在ddl前尽最大努力完成

  9. 学到了什么? 如果历史重来一遍, 会做什么改进?

    学到了在项目过程中分工明细很重要,如果再来一遍会更加细致地进行分工,设置好各个部分的负责人,共同推进项目的进展

2.2.3 资源

  1. 我们有足够的资源来完成各项任务么?

    有,人力物力都有基本保障。

  2. 各项任务所需的时间和其他资源是如何估计的,精度如何?

    所需时间和其他资源是根据分配的任务量以及与对应的任务负责人所商量的结果来估计的,精度到以天为时间单位

  3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

    测试的时间和人力和软件/硬件资源较为足够,大家都会尽量挤出时间来进行测试,我们小组人数也够,开发所需的软件硬件资源也是有的。对于那些不需要编程的资源没有低估难度,都会指定一个人来负责

  4. 你有没有感到你做的事情可以让别人来做(更有效率)?

    没有,我们的给每个人分配的任务都是尊重个人意愿且衡量过个人能力来进行分配和调整的

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

    我们应该加强时间观念,还有对项目进展的跟进。再来一遍的话要改进管理方式,多多注意项目的进展,不浪费一分一秒

2.2.4 变更管理

  1. 每个相关的员工都及时知道了变更的消息?

    是的,我们一旦有了变更都会通过腾讯会议来进行通知每一个人

  2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

    根据我们项目需要实现的最基本功能来决定,必要的先做好,锦上添花性质的功能就是在先做完基本要求的前提下再谈

  3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?

    有,就是在前端能够展示出我们想要的数据图表

  4. 对于可能的变更是否能制定应急计划?

    能,小组会积极地进行会议,集思广益指定应急计划。

  5. 组员是否能够有效地处理意料之外的工作请求?

    是的,组员都很尽力,即使熬夜也会尽量完成

  6. 学到了什么? 如果历史重来一遍, 会做什么改进?

    一开始指定计划的时候应该尽可能的考虑充分,让计划尽可能的周全,最大限度地避免在项目的进行过程当中做变更,也应该做应急方案,以防万一。

2.2.5 设计/实现

  1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
  1. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
  1. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
  1. 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
  1. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
  1. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
    • 由组内大佬审查,严格执行了代码规范。并建议其他组员如何修改自己的代码。
  2. 学到了什么? 如果历史重来一遍, 我们会做什么改进?
    • 设计对于后续的开发工作时有很大的帮助的,会减少走弯路的时间。不是题目一拿来就开始敲代码的。
    • 改进:对开发会更加注重设计,尽量做到兼顾一些细节问题。

2.2.6 测试/发布(3分)

  1. 团队是否有一个测试计划?为什么没有? 是否进行了正式的验收测试?
    • 有一个测试计划,由前后端共同测试。进行了非正式的验收测试。
  2. 团队是否有测试工具来帮助测试?
    • 有,我们利用postman来测试接口
  3. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
    • 测试软件是否能够正常运行,是否能够搜索出正确的结果。运行速度如何,正确性如何。
    • 有用
    • 运行出来的结果应该更加优化一下界面,提高用户的体验感。
  4. 在发布的过程中发现了哪些意外问题?
    • 在发布的过程中,我们只在web端部署了一下,因为考虑到相关政策、只允许查询基本的功能。在后续我们会根据发布体验进行优化。除了这个,暂时没有其他问题。
  5. 学到了什么? 如果历史重来一遍, 会做什么改进?
    • 在软件的开发的过程中,软件测试是极为重要的。即使是测试过很多次后,仍可能会出现很多问题。这需要我们不厌其烦的测试。
    • 改进:更加花时间地去测试。

2.2.7 团队的角色,管理,合作(3分)

  1. 团队的每个角色是如何确定的,是不是人尽其才?
    • 每个人先表明自己已经基本掌握的技术特长。再根据团队项目的根本需求来决定每个人该做什么,该学什么。最后确定团队的每个角色。
    • 是人尽其才。
  2. 团队成员之间有互相帮助么?
    • 自然是有的,无论是前端还是后端,还是其他小组。在开发过程中,遇到自己实在解决不了的问题,都会进行讨论研究。
  3. 当出现项目管理、合作方面的问题时,团队成员如何解决问题? 每个成员明确公开地表示对成员帮助的感谢

2.2.8 总结(4分)

标签:学到,10,什么,冲刺,Beta,组员,苏伟煌,团队,感谢
来源: https://www.cnblogs.com/TJThunder/p/15616821.html