Let‘s go!——alpha阶段问题总结随笔

这个作业属于哪个课程2302软件工程社区
这个作业要求在哪里团队作业—bate冲刺+事后诸葛亮
这个作业的目标Alpha 阶段问题总结
团队名称Let’s go!
团队置顶集合随笔链接
其他参考文献现代软件工程讲义 11 项目管理 - 事后诸葛亮会议

一、设想和目标

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

  1. 本产品从定位之初即立足在专注自习与计划列表的交叉上,旨在为学习者们提供更为丰富的自习、专注社交圈
  2. 典型用户:在校学生,备考者,长期学习者
  3. 典型场景:
    1. 在校学生 A 喜欢在人少的宿舍里学习,但是苦于宿舍没有自习室的氛围良好,总是无法进入学习状态
    2. 在校学生 B 喜欢玩手机,每次学习时,手机一有通知消息,就总是忍不住看手机,导致学习效率很低
    3. 高考生 C 的学习计划很多,但是缺少条理,导致最后完成情况很不乐观
    4. 校外考研二战的学生 D 希望能在自律的同时,找到与自己志同道合的同学一起备战考研

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

  1. 原计划的功能在大体上已经全部完成,详见 Alpha 总结随笔
  2. Alpha 冲刺已按原计划结束并通过答辩

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

  1. 与上一阶段相比,团队软件工程的质量提高了。
    1. 在 Alpha 冲刺方面,我们团队首先进行了明确的工作量的划分,每个人具体做些什么内容,与谁进行对接都进行了详细的说明,这使得团队内的合作交流加强。其次这次冲刺过程中,还配套了站立式会议,对于管理人员来说也能了解组内开发进度,方便进行项目管理
  2. 提高主要在分工合作方面,有很大的提升,因为此次开发,团队顺利地完成了任务,组内工作也比较愉快,从大家的反馈来看这是一次非常不错的合作,以往的话经常打拼到最后一刻才完成任务

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

  1. 认真审查设计文档。在实际开发过程中,我们发现设计文档中存在许多问题,这给我们的工作带来了不少困扰和额外的工作量,需要及时进行修改和完善。
  2. 合理分配工作量。需要深入调查每个人的工作量,了解他们的工作难点和复杂程度,避免随意分配任务,以确保工作的高效性和合理性,同时也要关注团队成员的工作负担和压力。
  3. 加强团队交流。前后端测试是一个复杂的过程,在团队讨论时容易产生激烈的争论,导致气氛紧张。需要通过有效的沟通和协调,确保团队在紧张的讨论中仍能保持合作和友好的氛围。

二、计划

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

  1. 在 Alpha 冲刺开始时就分配了每个人的分工和全后端组长,并且开了站立会议进行交流,总体来说开始后较为顺利。
  2. 但因为缺少项目经验,在有限的Alpha冲刺时间中,任务完成得比较仓促。

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

  1. 由于团队内部氛围非常好,分工由每个人自己挑选,有问题都会积极地提出,并获得组员的及时帮助和交流。

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

  1. 大部分计划都完成,有一些功能,由于一些组员缺少项目经验、对使用的技术不够熟悉,因此在完成任务上有些困难,但是经过组员之间的互相帮助,大部分计划基本完成。

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

  1. Alpha冲刺的最后进行了打包的尝试,但是一直出现问题导致最后没有打包成功。

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

  1. 前台接口交付存在一定的纰漏,由于后台处理的不小心,很多单元测试的样例我们测过了就直接删除,因此在和前端交互的时候出现了一些问题。

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

  1. 项目的最后半天进行打包时出现了一些问题,初步诊断为代码没有做app的兼容,因此导致打包时出现了问题,不能顺利打包完成。
  2. 对于项目测试的不够全面,主要是还是心理上对于测试的不重视。

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

  1. 计划中有留下缓冲区,但是由于在项目的中途,因为课程有限时编程的团队任务,占用了两天时间,导致Alpha冲刺的在最后一天才基本完成。

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

  1. 争取在beta冲刺中留下更多的缓冲区。
  2. 通过加强组员之间的交流与合作,提升团队的工作效率。

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

  1. 凡事预则立。在团队开发过程中,做好详细的计划是成功的基础,能够预见和避免许多潜在的问题。
  2. 重视软件工程的每一个环节。每个环节都至关重要,只有全面关注和认真执行,才能确保项目的高质量和顺利完成。

三、变更管理

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

  1. 知道。beta冲刺一开始的人员变更,组长及时在群里发布了消息,并询问每个组员的具体意向。

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

  1. 对于重要的决定,采用线下讨论或者线上会议的形式进行表决。
  2. 对于一些相对而言不是特别重要的决定,则在qq群里进行投票表决。

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

  1. 项目的界面上与原型设计进行匹配
  2. 项目名的功能上则完成系统设计说明书的相关定义

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

  1. 能。遭遇到变更后,组长会第一时间与组员门进行专门地讨论,组员一起制定相应的计划并实施。
  2. 在我们实际的开发过程中,对于变更都做到了很好的处理

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

  1. 团队的初期工作分配完成得十分顺利,因此意料之外的请求并不是很多,但是当遇到意料之外的工作请求时,组员们都能很好地即时沟通交流,相互帮助,很好地处理了相应的请求。

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

  1. 在需求分析阶段,往往难以完全穷尽所有可能的情况,因此需要特别关注那些潜在易变的需求,以便及时应对可能的变化。
  2. 对于负责开发的模块,需要保持正确的心态,意识到需求难免会发生变化。因此,需要灵活应对,并在开发过程中随时调整和适应新的需求变化。

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

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

  1. 首先由组长进行具体工作的分类,并绘制成群文档发布到小组工作群中。
  2. 在进行一次站立会议,组长介绍完每个工作分类后,由大家结合自己的技术和可分配时间,自行选择相应的工作。
    1. 擅长或有过后端开发经验的组员,选择了后端部分的工作,擅长或有过前端经验的组员选择前端部分工作。
    2. 最终选定了 4 人前端、 4 人后端的团队人员分配。
  3. 从最后的开发体验上来说,大家满意程度较高。

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

  1. 在前后端的对接工作中非常明显。
    1. 同一开发小组如果有对接经验会直接进行口口相传。
    2. 前后端的开发人员彼此之间也会互相交流,彼此进行审查。
  2. 当组员遇到一些自己无法解决的问题时,都会在群内提出问题,一般都会有组员即时地进行解答和帮助。

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

  1. 当项目管理遇到问题时,都会先在相应的前端或后端小组组内进行讨论和探讨。
  2. 组内讨论无法解决的,会与组长进行讨论解决。

五、设计/实现

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

  1. 设计工作在需求分析、系统设计与概要设计阶段由小组成员进行分工认领之后,共同完成任务。
  2. 由于每一项任务都有一周的时间来进行,且离 Alpha 冲刺比较远,有足够的时间,且为团队内部成员开发,人员合适。

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

  1. 因为在设计工作进行工作分配的初期,组长就进行了详细的工作分类和说明,因此组员的工作都相对具体明确。
  2. 当遇到不清晰的地方时,组员都会第一时间与组长进行交流。

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

  1. 团队中使用了 RIDE,Xmind,ApiPost,以及人工测试的方式来帮助实设计与实现
  2. RIDE 用于展开自动化测试,帮助我们进行回归测试。Xmind 用于思维逻辑梳理,团队交流合作。

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

  1. 因为缺乏测试经验,再加上项目本身设计的功能并不复杂,因此发现的bug并不是很多。
  2. 一些bug在代码的编写过程中就逐渐被发现,产生原因是组员的项目代码经验不足,因此忽视了很多细节造成的。

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

  1. 组员开发前会自行阅读代码规范后续才展开代码编写工作,对于代码的复审是展开的交叉检查的方式
  2. 在 Alpha 阶段对于代码规范的审查确实没有做好,组员们大部分时间都只关注自己所负责的代码部分,因此代码规范的审查进行得并不是很好,同时代码复审的具体执行清空也较为一般。

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

  1. 在开发过程中遇到的问题需要详细记录下来,不能仅仅依赖口头梳理。详细的记录不仅有助于后续的解决和跟踪,还可以为团队提供宝贵的经验教训,防止同类问题的重复发生。
  2. 对于代码复审和代码规范必须高度重视。严格的代码审查和规范可以提高代码的质量和可维护性。同时,测试工作也同样重要,必须确保每个模块都经过充分的测试,以保证项目的整体质量和稳定性。

六、测试/发布

1. 团队是否有一个测试计划?为什么没有?
1.团队有测试计划,详见测试笔记
2.但因为组员都缺乏测试经验,因此总体的测试效果一般。

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

  1. 有,团队成员在 APP 进行打包之后展开了多轮次的黑盒测试,以满足验收

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

  1. 使用了 RIDE、ApiPost 等自动化测试工作来进行测试

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

  1. 因为Alpha冲刺时间较为紧凑,因此对这一点有所忽略,我们会在beta冲刺的测试工作中着重进行这一部分的工作。

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

  1. 每一轮的黑盒测试都能发现不少的问题,比如:
    1. 返回界面跳转异常,跳转的界面并不是进入的界面
    2. 接口调用异常,形参不匹配

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

  1. 由于这是我们第一次使用 UniApp 进行开发,我们之前并不了解它在测试方面的一些限制。这导致了我们的测试工作不够全面和深入。这一经验提醒我们,在使用任何新技术时,不仅要关注其开发过程,还需要重视其测试方法和限制。只有这样,才能确保在开发和测试的各个环节都做到充分准备,从而避免出现意外问题。
  2. 因此,在这一轮的工作中,我们将特别加强测试环节。我们将明确项目进程中的关键节点,在每个节点上都必须进行充分的测试。同时,项目组长需要及时发布和分配测试任务,确保每个团队成员都明确自己的测试职责和任务。通过这种方式,我们可以更有效地发现和解决问题,确保项目顺利推进并达到预期质量标准。
  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值