第08组 Alpha冲刺 总结

一、基本情况

  • 队名:在学了在做了
  • 组长博客:点这里
  • 作业博客:在这里
  • 组员人数:9人
  • github仓库链接
  • 答辩总结
    该次阿尔法大家都很积极,有问题大家一起提出来一起解决,虽然走了一些弯路,但是也较为实际的体会了一次阿尔法的特点
  • 全组讨论的照片
  • 工作占比
姓名 占比 分工
周天 6.5% UI设计、博客园编辑
陈曼 23% 前端、数据库
陈昕滨 2% 视频制作
李少荣 4% 前端页面
林荣胜 36% 前端页面、数据库
王梓鹏 5% 前端页面
杨立芬 20% 前端页面
张晓晗 3% 前端页面、燃尽图
郑瀚曦 0.5% 博客园编辑

二、总结思考

2.1设想和目标

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

  • 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?
    基本达到目标了:Alpha版本预计的聊天、发单、接单、登录认证、任务车和在线客服等基本完成,但部分操作仍有bug;时间上来说按照原计划交付时间提交了;对于Alpha版本我们并不对用户数量做高要求,用户量还需在Beta版本完成后进行推广获得。

  • 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
    Alpha版本并无预期,因为目前的用户就是开发人员,对于当前版本的一些操作我们以用户的角度来看还可以接受。

  • 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
    时间相当不够用;如果重来一遍,一定事先确定好整个流程,能避点坑是点坑。

2.2计划

  • 是否有充足的时间来做计划?
    相对一般,有时候可能计划赶不上变化。

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

  • 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
    没有,客服部分有点点问题没有解决

  • 有没有发现你做了一些事后看来没必要或没多大价值的事?
    还好,没有很多

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

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

  • 在计划中有没有留下缓冲区,缓冲区有作用么?
    有,给自己放半天假,大家不是铁人,当然是有用的。

  • 将来的计划会做什么修改?(例如:缓冲区的定义,加班)
    基本无修改,仍然是努力打工,可能只能给自己放俩小时假,总之冲冲冲就对了!

  • 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    学到了如何破解《人月传说》;如果历史重来,我们会当李白提高督促效率,把任务给快速搞好。

2.3资源

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

  • 各项任务所需的时间和其他资源是如何估计的,精度如何?
    由于没有以前的开发经验,所以估计的内容是边做边估计的,精度较为一般,仍然遇到了一些坑而且有bug出现。

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

  • 你有没有感到你做的事情可以让别人来做(更有效率)?
    有的,大佬做页面比我快很多

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

2.4变更管理

  • 每个相关的员工都及时知道了变更的消息?
    大多数时候是及时的,大家有更新就在群里问在群里说,极少时候消息更新的不够及时。

  • 我们采用了什么办法决定“推迟”和“必须实现”的功能?
    根据当前的工作量和进度,以及对Alpha要做的内容权衡。

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

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

  • 员工是否能够有效地处理意料之外的工作请求?
    能,虽然大家还是在练习中,效果还是不错的。

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

2.5设计/实现

  • 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
    原型设计是在需求分析那段时间由杨立芬和王梓鹏和完成的,数据库的设计在冲刺期间主要由陈曼和林荣胜完成;以目前的成效来看,时间以及人选都是合适的。

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

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

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

  • 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
    聊天功能产生的bug最多,因为聊天通过需要实时监听数据库的变化,并将数据显示在界面上,而且,为了实现一对一聊天,我们考虑得到两个用户的学号来设置独特的id,但由于数据库设计不合理,所以id的获取花了很大功夫。在发布后,发现地图的打开出现了bug。因为在设计时一直是以授权的状态来打开地图的,所以没有添加授权的代码来提示用户授权地理位置,导致发布后用户点击选择位置不能打开地图。

  • 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
    当时是花晚上的时间在活动室进行复审,部分执行了代码规范,剩下的需要改进的会在Beta部分进行解决。

  • 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
    学到的主要还是设计和实现的流程过程,大家对于分工和需求都有了更好的认识;如果重来,我们会在设计阶段做的更细致,以便后面开发少遇到模棱两可的情况。

2.6测试/发布

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

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

  • 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
    利用测试版进行效能测量;实际运行来看,这些测试工作可能对于后面Beta或者说发布会比较有用;需要改进的是响应速度和交互体验感。

  • 在发布的过程中发现了哪些意外问题?
    严格来讲,目前项目并未发布;倒是因为小程序的一些条例,让我们测试版推迟了一点时间,测试时发现了部分登录后的bug等。

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

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

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

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

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

  • 每个成员明确公开地表示对成员帮助的感谢 (并且写在各自的博客里):
    非常感谢组里的每一个成员,因为我和他们不是一个专业的,其实一开始没有很熟,但是大家都非常非常nice,很感谢他们。

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

2.8总结

  • 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
    处于初始级(initial):
    工作无序,项目进行过程有计划的更变,可能会暂时性放弃。因为大家撞上了各种考试,方便做的就做,复杂的部分方便做的也在做,其他的预计是Beta部分进行完善。希望Beta冲刺期间可以达到(2)可重复级(Repeatable)。

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

  • 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
    目前(Alpha)和上一个里程碑(需求分析)相比,整个团队沟通得更加好了,而且大家的技术能力都有更好的提升,团队协作能力和时间管理能力++

  • 你觉得目前最需要改进的一个方面是什么?
    最需要改进的还是技术方面吧,毕竟都是新手起步,还要努力升级。

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

三、测试组问题回答

  • 1、 学生认证手动审核吗

答:学生认证我们使用人工审核。我们没有学生信息库,所以对于随意编造姓名和9位学号的用户,我们不能通过于信息库匹配的方式实现认证。而且,就算该用户使用的姓名和学号确实匹配,但也存在别人冒用的情况,毕竟知道别人的学号和姓名不是难事。所以,为了保证认证的可靠性,我们要求上传学生证,再进行人工审核,毕竟目前面向校内学生,基数小,且审核一个人只是几秒钟的事,所以对于目前的情况,我们认为人工审核是可行的。

  • 2、 打赏费用有格式限制吗,eg:1.078

答:打赏费用的格式限制,我们会使用和微信发红包时输入金额时一样的格式限制。

  • 3、 支付是线上还是线下支付,线上的话是用什么方式,有没有安全机制

答:带货带人是线下支付。打印是线上支付,通过微信小程序提供的接口实现支付给商家,微信小程序的支付应该很安全了吧。

  • 4、 投诉后台如何处理, 投诉结果没有反馈?

答:投诉至后台后,人工审核,客服会将投诉结果反馈给用户。用户也可以直接发送消息向客服投诉。

  • 5、可以对接单人增加限制吗 比如出于安全考虑指定接单人性别

答:这个问题和alpha总结答辩柯老师提出的限制一定分数信誉积分的人才能接单、需求分析答辩时第十组提出发单人选择车型的建议相似。我们可以在接单者接单时,系统将进行判断,该接单者是否满足发单者的要求,不满足要求的接单者将不能接单。当然我们会加入更多的选项让发单者选择。

  • 6、 如果我接单后因其他原因无法完成,能否取消接单,或者超时完成如何处理

答:当一方提出取消订单后,另一方收到对方想要取消订单的请求,如果双方达成协商,则正常结束订单关系。如果只是单方的取消订单,且另一方长时间没有响应,系统将提示该方是否举报,举报后将人工审核,实行一定的惩罚机制。对于超时的情况,我们同样会结合用户的评价来给接单者打上tag。

posted on 2020-11-22 23:19  zxh2001p  阅读(113)  评论(0编辑  收藏  举报