护林员——Alpha阶段问题总结随笔

forest_rangers 团队 2024-05-21 17:27:28
这个作业属于哪个课程福州大学-202302软件工程实践
这个作业要求在哪里团队作业——bate冲刺+事后诸葛亮
这个作业的目标撰写Alpha阶段问题总结随笔
置顶集合随笔护林员——Beta阶段置顶集合随笔
团队名称护林员
团队项目福大树洞

目录

  • 一、设想和目标
  • 二、计划
  • 三、资源
  • 四、变更管理
  • 五、设计/实现
  • 六、测试/发布
  • 七、团队的角色,管理,合作
  • 八、总结:

一、设想和目标

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

    1. 解决问题:在当前的大学校园环境中,学生们经常面临各种压力和挑战,包括学业、人际关系以及个人成长等方面的问题。但可能是为了避免被他人取笑,亦或是不敢主动开口分享,很多大学生不愿意在实名的环境下分享和讨论这些问题。
    2. 软件定义:一个面向福大学生群体的匿名交流平台,不论是成长中的烦恼、学习中的经验、恋爱时的故事都可以分享,无需担心自己隐私的暴露,因为别人不会知道你是谁,所有人在这里都是平等的。
    3. 典型用户:福大学生中,想要解决自己烦恼的人、想要分享学习经验的人、想要讲讲恋爱故事的人···
    4. 典型场景:
      场景一:张三想询问学长学姐相关情况,然而因为留学人员较少,找到的学长学姐中,大多都是考研或是保研,对留学方面的信息和政策不是很了解。
      场景二:李四因为一个误会与男友发生了语言上的冲突,事后得知事情真相后希望弥补但又不懂怎么办,想询问但又不想自己的事暴露给他人。
      场景三:王五选修课只需要选一门就可以修满学分了,然而在众多课程中不知道自己适合哪一门,而学长学姐并未选择部分课程,无法获取到相关的消息
  2. 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)

    原计划的前台功能已经大体完成
    因为对进度的把控问题,前端未能写完所有接口的路由,但主要功能是写完了的,故算是按照原计划时间交付

  3. 和上一个阶段相比,团队软件工程的质量提高了么? 在什么地方有提高,具体提高了多少,如何衡量的?

    和上一个阶段相比,团队软件工程的质量有了大幅的提高

    1. 因为有了明确的分工和站立式会议,组内信息的流通性得到了提高。对比以前线上会议,经常可能遇到同时开麦导致无法听清、网络原因需要调试等等,在时间的利用率上提高了23%。
    2. 放弃了接口文档上传群文件的形式,我们将大部分流程搬到了apifox上,让修改可以实时同步,让前后端对接可以更加的顺畅。对比以前以word文档的形式上传接口文档,避免了接口无法实时更新,开发时接口后开发后接口版本不一致的问题,优化了开发流程,总体效率提高54%。
    3. 充分利用了apifox的测试功能,前端可以mock数据,后端可以测试接口,让代码可以尽早的得到验证。对比以前只能等上线到服务器再一个一个接口测试,通过线上逐个测试的方法,节省了前后端集成时的时间开销,总体效率提高56%。
  4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

    目前项目仍在开发阶段,暂不上线,内部测试时,开发人员均认为重要功能的使用时间可以接受的
    从无到有必定是离目标更近了,目前Beta是从有到优的过程

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

    1. 后端方面尽早展开技术交流会,让后端大佬实时开发一个接口并讲述思路,为其他后端人员提供开发流程的大体框架。
    2. apifox的使用应该尽早掌握,因为在早期开发过程中对接口文档的重视度较小,导致后期需要修改的地方过多。
    3. PM不能只关心后端的进度,前端的进度也需要大致掌握,让项目可以按质按量的完成。
    4. 合理规划好时间,留出更多的缓冲区。后期测试时因为时间紧迫,导致气氛有些紧张,好在平稳落地,顺利完成Alpha冲刺。

二、计划

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

    当然是有的,Beta冲刺前也有让各个组员去考虑自己对应工作的相关技术,例如前端的推送通知和信息本地存储,后端的图片上传和华为云的部署。在Beta冲刺开始前也有总结了各个成员的工作情况,并对接下来的Beta冲刺进行了时间上的安排。

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

    团队内气氛融洽,持有不同意见时并不会剑拔弩张,而是由PM、前端主要负责人、后端主要负责人进行协商,这也是前期这样团队分工的好处,在出现问题后可以不用七嘴八舌的争论,而是各方出代表坐下来好好谈。然后根据技术、环境、时间等因素综合考虑,选择一个最佳的方案,并在群内通知各个成员,保证讨论结果的顺利传达。

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

    Alpha的前台主要功能基本完成,仅剩下一些查漏补缺。
    部分接口没有完成的原因,一个是技术问题,前期大多数时间耗费在技术栈的学习上;一个是进度控制问题,PM对前后端进度把握不平衡,导致部分任务会有延迟完成的现象。

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

    暂无,组内分工明显且任务明确,所有的工作都是为了确保项目的完成,暂时还未发现有做一些没必要或没多大价值的事。

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

    在Alpha前期因为接口文档为word的形式,导致前后端的接口开发不匹配问题。但已经在Alpha冲刺中进行调整,目前前后端接口的开发较为顺利。

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

    出现的意外就是后端的技术学习比想象中要缓慢,导致后端接口完成时间的延缓。
    这是早期低估了自学SpringBoot的难度造成的,因为很多同学都是在期末考试前临时抱佛脚,我认为同学们自学能力一定非常强大,所以才会错误SpringBoot的学习难度。
    不过已经经历了Alpha的"摧残",Beta阶段的技术问题将大大减小。

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

    有留下缓冲区,但缓冲区较小。不过,缓冲区对项目的完成还是有很大作用的,因为即便后期后端进度的延缓,最后仍然完成了前台的主要功能,成功完成了答辩和展示。

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

    1. 要增加更多的缓冲区,以便在遇到意外时可以从容应对,不用着急赶进度,提前享受社畜生活。
    2. 尽量做到合理安排计划,不把任务都拖到最后一天去加班完成,要加班也应该是PM加班,可以说是对没有认真做好进度规划的惩罚。
    3. 不把做PPT等相关的工作放入冲刺的阶段,这样会导致最后一天还在改代码,PPT制作者也需要加班才能完成。
  9. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

    1. 凡事预则立。要做好Beta阶段的规划,未来在实际工作时才能按部就班,顺利完成任务。
    2. 尽早征求组内拥有项目经验大佬的建议或意见,像是apifox或是线下讨论会都是有这位大佬才能成立的,应该好好的利用这个优势,发挥大佬的价值。

三、资源

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

    当然有。

    1. 时间:我们有七天的时间进行编程,同时最后一天是为了做PPT、写博客等任务,也可以适当作为缓冲区。
    2. 金钱:使用华为云可能会需要花一些钱,不过好在学校可以给报销。
    3. 激情:团队内大部分都是只有课内知识的同学,但是他们也都努力学习新技术,虽然可能会因为是新手导致部分问题,但我们都会去努力的解决。
  2. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

    测试的时间和资源都是足够的。毕竟有开发人员自己的测试还有专门的测试人员。
    说实话,我有写低估文案的难度,好多博客堆起来写还挺痛苦的。

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

    确实有,后端代码如果都由那位大佬写的话,想必后端进度会快吧,但是其他后端人员就无法得到锻炼,而大佬也压力过大,所以不会这样做。

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

    任务分工方面还是可以优化一些,尽量让每个人的工作量相当,不会让某人压力过大。

四、变更管理

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

    是的,比如人员更换后组长会立即在群里进行通知。类似的变更也会及时的再群内通知,不会让某个人无法掌握现状。

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

    在Alpha的进行过程中,如果有部分功能无法完成,PM、前端主要负责人、后端主要负责人会进行讨论,综合考虑成员技术、剩余时间、功能的重要性来综合考虑,判断是否要推迟到Beta完成。

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

    1. 主体功能前后端已实现,并完成了集成
    2. 软件各个功能经过完备的测试
    3. 软件能够通过验收,达到客户的满意
  4. 对于可能的变更是否能制定应急计划?

    当然可以。在遇到不得不变更的问题时,我们会总结当前任务进度、剩余任务总量、剩余工作时间,弄清变更影响的工作、解决需要的时间、计划的变更情况,基于成员的技术能力、任务的难易程度、缓冲区的大小,来进行制定适宜目前团队情况的应急计划。

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

    当然,就像我在问题4中阐述的,我们会基于成员的技术能力和时间来决定如何进行变更,让意料之外的工作请求变成意料之中,因为如果成员无法有效处理的话,我们是会更改应急计划的。

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

    1. 变更是不可避免的,但是是可以尽可能减少的,合理的规划和完备的分析可以减少变更的产生,让成员工作时可以更加专注,减少他们处理意外情况的可能性。
    2. 留足缓冲区,让成员面对变更时也能从容不迫的解决。

五、设计/实现

  1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?

    需求分析是由全体成员完成的;系统设计是由前端团队完成;数据库设计是由后端团队完成。
    需求分析是需要集所有人的才智在一起才可以完成;系统设计大部分为接口的设计,故由前端团队完成更为合理;数据库设计大部分是对各个表各个属性的设计,涉及后端代码的撰写流程,故由后端团队完成更为合理。这三部分都是有专门的时间段进行完成,所以时间上十分充足,不会因为着急写代码而让设计出现重大的纰漏,导致后期修改过多。

  2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?

    因为我们是先开会讲解每个页面的功能和显示内容,所以各个成员对我们要实现的项目都较为清楚,很少会有模棱两可的情况。如果有的话也可以直接在群内提问,其他成员会及时解答。

  3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?

    我们团队在进行相关工作时,使用了apifox、Xmind、墨刀等工具,极大的提高了工作效率,助力我们顺利完成任务。
    apifox进行单元测试,前端可以mock数据,后端可以测试接口运行情况;Xmind用来梳理总体的思路、时间的计划、功能的汇总等等;墨刀用于完成前后台的原型的实现,能够将需求具象化,让我们每个成员对项目都有更加清晰的理解与掌握。

  4. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

    因为团队内有使用apifox进行测试,所以后端Bug会相对较少。前端显示Bug最多,比如没要考虑到计算可能会得到很多位小数,测试数据较为简单等等。
    因为前端成员花费了更多的时间在Vue的学习和撰写上,所以测试用例相对较少。

  5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

    代码规范在编写代码前就已经确定,所以每位成员都是在对代码规划较为理解的基础上才开始撰写代码的。
    代码复审目前是我们团队较为欠缺的部分,因为代码复审将会占据很多的时间,对于进度会拖延较多。

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

    尽量安排时间进行代码复审,这样一些开发者很难发现的问题,其他人可能可以迅速地发现,让代码的健壮性、鲁棒性和有效性提高。

六、测试/发布

  1. 团队是否有一个测试计划?为什么没有?

    团队是有测试计划的,具体内容可以参考我们的护林员——Alpha冲刺测试随笔

  2. 是否进行了正式的验收测试?

    有,全体成员进行黑盒测试,来确保满足验收所需要的效果。

  3. 团队是否有测试工具来帮助测试?

    有,我们使用了apifox这个测试工具,进行了接口的单元测试,自动化测试等等,相比于之前的等到部署后再测试,效率显著得提高了。

    img


    img

  4. 团队是如何测量并跟踪软件的效能(Performance)的?压力测试(Stress Test)呢? 从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?

    我们当然有进行压力测试等进行对软件评测,保证在高并发下用户可以正常使用。不过后端有做同一IP短时间内访问次数的限制,以保证受到攻击时可以及时封禁相关的token,所以压力测试的次数没有过大。

    img

  5. 在发布的过程中发现了哪些意外问题?

    一个是前端那边没有考虑到数字可能会有多个小数,另一个是在网页上显示正常的页面,在手机上可能会显示有问题,需要对不同型号的手机进行兼容性处理。

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

    尽早地做前后端集成的测试,让一些开发时没有注意到的问题早些暴露出来,这样就可以在早期就对问题进行修改,而不是累积一堆Bug,等到后期再一个一个痛苦地修改。

七、团队的角色,管理,合作

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

    我们在分配角色前,会去问卷调查每个人的期望的技术栈,然后通过人数上的平衡来进行角色分配,所幸前后端人数相当,所以可以按照每个人希望学习的技术栈进行分配前后端。而后会去考虑每个人的技术能力,后端有项目经验的大佬自然是当做后端主要负责人,前端由一位责任心、求学心都十分出色的成员进行担当,PM由组长担当,所以可以说是人尽其才,每个人都按照各自的兴趣和能力分配了角色。

  2. 团队成员之间有互相帮助么?

    这是当然的,举个最明显的例子就是,后端前期技术学习上出现困难,寻求了后端大佬的帮助,本来想着可能会不太愿意来讲,没想到竟然会爽快的答应召开后端线下讨论会,顺利地解决了问题,平常有Bug时也会直接去找他,所以互帮互助方面,我觉得我们团队做的是很好的。

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

    遇到问题后,分析问题原因、解决方法、需要成员、耗费时间等,然后根据各个因素确定解决方案。比如说前后端对接时的问题,因为接口文档有改动时很难同步到每个成员那里,所以我们决定将接口文档从word移植到apifox上,只由前端那边来解决的话可能会导致时间上的不足,考虑到后端成员也需要用apifox来进行测试,故拿出一天的时间,全员进行apifox的学习和word到apifox的转换工作,虽然一天时间内,我们都项目进度没有明显前进,但是大大提高了前后端开发的效率、减少了集成时的Bug数量。遇到问题时难免的,只要合理规划,同心协力,总是有办法解决并顺利度过的。

八、总结:

  1. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

    规范阶段

  2. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?

    成员们的技术得到了充分的提高,接下来就是完善我们的功能的阶段了。同时,因为Alpha阶段的合作十分紧密,团队的凝聚力也得到了提高。

  3. 你觉得目前最需要改进的一个方面是什么?

    继续提高沟通上的效率,有时出现问题后仍然需要找PM做传话筒,问题是可以得到解决,但是效率还是可以进一步提高的。可以直接到对应的群里去讨论,比如后端的问题到后端群,前后端集成的问题到大群中反馈,这样在其他成员遇到相同的问题时,可以直接到具体的群内找消息记录,让相关人员无需对同一个问题进行多次回答。

...全文
66 回复 打赏 收藏 转发到动态 举报
写回复
用AI写文章
回复
切换为时间正序
请发表友善的回复…
发表回复

121

社区成员

发帖
与我相关
我的任务
社区描述
FZU-SE
软件工程 高校
社区管理员
  • LinQF39
  • 助教-吴可仪
  • 一杯时间
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧