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. 因此，在这一轮的工作中，我们将特别加强测试环节。我们将明确项目进程中的关键节点，在每个节点上都必须进行充分的测试。同时，项目组长需要及时发布和分配测试任务，确保每个团队成员都明确自己的测试职责和任务。通过这种方式，我们可以更有效地发现和解决问题，确保项目顺利推进并达到预期质量标准。