zoukankan      html  css  js  c++  java
  • 第08组 Beta冲刺 总结(组长)

    一、基本情况

    • 队名:在学了在做了
    • 组长博客:点这里
    • 作业博客:在这里
    • 组员人数:9人
    • github仓库链接
    • 答辩总结
      该次贝塔大家都很积极,增加了新的内容,美化了界面 good
    • 全组讨论的照片

    • 工作占比
    姓名 占比 分工
    周天 4.5% UI设计、ppt制作、博客编辑
    陈曼 18% 前端页面、数据库
    陈昕滨 4% 视频制作
    李少荣 5% 前端页面、ppt汇报
    林荣胜 40% 后台管理、前端页面
    王梓鹏 10% 前端页面
    杨立芬 17% 前端页面
    张晓晗 1% 博客编辑
    郑瀚曦 0.5% 博客编辑

    二、总结思考

    2.1设想和目标

    • ①我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
      想要解决当代大学生对于时间需求高的问题,通过充分调动大学校内资源让大家生活更加高效;是,定义的很清楚;有,典型用户就是大学生,典型场景就是食堂带饭、电动车载人和打印店打印等。

    • ②我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?
      基本达到目标了:Beta版本预计的评价与星级、后台管理、正则判断、界面美化等都完成了,但是TAG还未加入、信誉积分部分未完善,消息界面也仍在进行中;时间上来说按照原计划交付时间提交了;对于Beta版本我们并不对用户数量做高要求,用户量还需在正式发布后进行推广获得。

    • ③用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
      Beta版本预想基本一致,因为目前的用户就是开发人员,为了能达到发布后且适用的效果,还需要进一步完善;显然离目标更近了。

    • ④有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
      完成度没达到最好;如果重来一遍,试着每个板块都去派负责人去安排。

    2.2计划

    • ①是否有充足的时间来做计划?
      充足,但变化来的可能比计划快。

    • ②团队在计划阶段是如何解决同事们对于计划的不同意见的?
      大家积极交流,各抒己见,最后大家一起分析取舍,让一个计划最终敲定的更为合适。

    • ③你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
      否,因为画图遇到困难了,麻了。

    • ④有没有发现你做了一些事后看来没必要或没多大价值的事?
      有,比如我画的有的图压根儿不会被实现。

    • ⑤是否每一项任务都有清楚定义和衡量的交付件?
      显然不是,有时要根据变化来交代要干啥。

    • ⑥是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
      基本按照计划进行;意外主要是踩坑,大家睡眠严重不足;目前暂时没有未估计到的风险,决定该项目之前大部分风险都已考虑到,选题答辩时听取同学的意见,风险估计更加完善了。

    • ⑦在计划中有没有留下缓冲区,缓冲区有作用么?
      不急做的就放一放,先搞需要的,缓冲还是有用的。

    • ⑧将来的计划会做什么修改?(例如:缓冲区的定义,加班)
      能修改的和其他班一样吗?

    • ⑨我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      如何发现所需解决所需;如果历史重来,建议换班。

    2.3资源

    • ①我们有足够的资源来完成各项任务么?
      基本足够,队员肝的能力和效率是猛的。

    • ②各项任务所需的时间和其他资源是如何估计的,精度如何?
      由于没有以前的开发经验,所以估计的内容是边做边估计的,精度较为一般,还是有些bug。

    • ③测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
      测试的时间,人力和软件/硬件资源不怎么足够;对于不需编程的资源未低估难度,确实还不错。

    • ④你有没有感到你做的事情可以让别人来做(更有效率)?
      说不定,毕竟未知数太多。

    • ⑤有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
      协调好每个人的职责,尽量保持资源利用的高效,让整个项目能够稳步进行。

    2.4变更管理

    • ①每个相关的员工都及时知道了变更的消息?
      及时,大家积极交流,有啥问题或者变动都在群里说了。

    • ②我们采用了什么办法决定“推迟”和“必须实现”的功能?
      采用了本组预期加上老师意见以及测试组建议综合考虑法。

    • ③项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
      有,测试无bug、操作逻辑正确无误就是了。

    • ④对于可能的变更是否能制定应急计划?
      可以的,大家还是很积极的。

    • ⑤员工是否能够有效地处理意料之外的工作请求?
      在学了在做了,可以的没问题。

    • ⑥我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      我们学到了如何做一名合格的打工人;如果重来,我们会更积极的推进计划,定好细致的需求。

    2.5设计/实现

    • ①设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
      一些界面的图是冲刺期间由周天完成的,数据库部分的设计是由林荣胜和陈曼在alpha冲刺期间完成的;以当前成效来看是合适的时间及人选。

    • ②设计工作有没有碰到模棱两可的情况,团队是如何解决的?
      有,比如部分跳转逻辑有些许问题;大家一起讨论后敲定怎么做就去着手解决了。

    • ③团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
      有用过UML,有一定效果,主要起参考作用。

    • ④比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
      区别并不多;产生原因主要是实现效果和预期内容有一定差异;仍需要更新以便更好的开发。

    • ⑤什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
      小程序端发起认证审核,后台接收用户传来的审核请求,同意请求后再对用户进行微信通知,这个功能bug最多。因为自己在测试的时候,使用的是同一个openid进行测试,但由于该通知为一次订阅消息,所以在第一次正常发出通知后,后面的通知发送都是随机事件。
      在发布后,发现备注的长度过长,会在很多地方产生界面冲突的问题。因为在测试的时候都是简简单单的写几个字作为备注。

    • ⑥代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
      当时是花晚上的时间在活动室进行复审,部分执行了代码规范,剩下的需要改进的需要在后面继续完善。

    • ⑦我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      学到的主要是发现并且完成需求,大家对于分工和需求都有了更好的认识;如果重来,我们会时间穿梭直接猛学,让完成度能足够高。

    2.6测试/发布

    • ①团队是否有一个测试计划?为什么没有?是否进行了正式的验收测试?
      并没有一个测试计划,因为大家都是直接体验开发的成效,没有去额外制定一个确切的计划;没有进行正式的验收测试,目前仅是简单的操作测试。

    • ②团队是否有测试工具来帮助测试?
      我们并没有用测试工具来帮助测试。

    • ③团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
      利用测试版进行效能测量;实际运行来看,这些测试工作可能对于后面的跟进修改会比较有用;需要改进的是一些bug和功能。

    • ④在发布的过程中发现了哪些意外问题?
      严格来讲,目前项目并未发布;倒是因为小程序的一些条例,让我们正式发布遇到了点困难。

    • ⑤我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      不同的队员学到不同的内容,大家小程序云开发的能力都有了一定的提升;如果重来,我们会提前制定一个时效性的测试计划,同时加快进度完成任务。

    2.7 团队的角色,管理,合作

    • ①团队的每个角色是如何确定的,是不是人尽其才?
      角色是按照讨论时大家的意向进行决定的,个人对某个板块了解的比较多的也会影响决定因素;显然并不是人尽其才,因为仍有些地方比较吃力,并非套话,我是相信队伍的本事不止如此的。

    • ②团队成员之间有互相帮助么?
      有的,一个人可以走更快,一群人可以更远;线上线下讨论、私聊等都起到了不错的效果。

    • ③当出现项目管理、合作方面的问题时,团队成员如何解决问题?
      大家都很积极认真,这点提高了一定的效率,对于项目管理、合作方面的问题都是讨论可以解决的。

    • ④每个成员明确公开地表示对成员帮助的感谢 (并且写在各自的博客里):
      我感谢 每一位 对我的帮助, 因为任务推进的过程中大家都提出了建设性意见,而且认真推进。

    • ⑤我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
      这次冲刺中,我们在团队的分工、协作、管理等方面学到了不少:分工的过程中要根据每个人的想法
      能力进行分工,只有各尽其才,团队才会走得更快更好;如果重来一遍,我们的团队于组长的视角来看是没问题的,即使这样的话大家在部分地方仍然会吃亏吃力。

    2.8总结

    • ①你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
      处于初始级(initial):
      工作无序,项目进行过程有计划的更变,可能会暂时性放弃。Beta所完成的是提出的一些要求,但是还有少部分未完善,其他的预计是后面可以继续跟进修改。希望发布/测试期间可以达到可重复级(Repeatable)。

    • ②你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
      处于规范阶段:经过整个Beta冲刺,大家磨合的都还可以,对于每个人负责的细致部分,还是有一定的规范。

    • ③你觉得团队在这个里程碑相比前一个里程碑有什么改进?
      目前(Beta)和上一个里程碑(Alpha)相比,推进的内容更多,而且大家的技术能力都有更好的提升,团队协作能力和时间管理能力++

    • ④你觉得目前最需要改进的一个方面是什么?
      技术方面,因为Beta预计实现的内容并没有完全搞定。

    • ⑤对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
      a.简明为本——它是极力简化不必要的工作量的技艺。
      大家在讨论每个功能和需求的时候,都会再次讨论这个功能是不是我们完全所需的,我们会把真正需要的给确定下来。
      b.业务人员和开发人员在项目开发过程中应该每天共同工作。
      同一个专业,同一片天空。

    三、测试组问题回答

    1、如果时间选择2030年呢?
    首先,时间选择不到2030年,最多2023年。既然我们加了时间不能选择过去的正则判断,也能加时间不能超前选择太多的正则判断。

    2、送取货地点不能填到具体位置吗(只能定位到区域吗)?
    发单人可以保留隐私,而且具体位置可以接单后再沟通。

    3. 管理后台必须要安装Python环境不能放到网页端吗?
    把GUI打包成exe就不用装python了。团队没有熟练掌握前端的组员,就做GUI了。

    4. 管理后台可以加上一些酷炫的图表吗(比如当前各种状态的订单,展示待审核和在线的用户扇形图等等)?
    用户量大的时候,可以使用pyecharts生成。

    5. 打星评价为什么评价的输入框标着服务投诉?
    过于匆忙,疏忽了。谢谢提醒。

  • 相关阅读:
    第十章学习笔记
    MyOD(选作,计入平时成绩)
    学习笔记第九章
    第一、二章学习笔记
    团队作业(一):团队展示
    C语言实现Linux下od -tx -tc XXX的功能
    第七、八章学习笔记
    Sort 在 Linux
    Linux C语言编程基础
    MyOD
  • 原文地址:https://www.cnblogs.com/skyjay666/p/14050168.html
Copyright © 2011-2022 走看看