可遇可球——Alpha阶段问题总结随笔

可遇可球-Fzu 2024-05-20 23:53:32

这个作业属于哪个课程	软件工程实践-2023学年-W班
这个作业要求在哪里	团队作业—bate冲刺+事后诸葛亮
这个作业的目标	alpha阶段问题总结
参考文献	现代软件工程讲义 11 项目管理 - 事后诸葛亮会议
团队置顶集合随笔链接	可遇可球——Alpha阶段置顶集合随笔可遇可球——Beta阶段置顶集合随笔

一、设想和目标

Q1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
A：1、我们的项目定义的很清楚，目的是打造一个集台球赛事信息展示、台球技术与新闻论坛、约球等功能为一体的台球网站。
2、要解决的问题：①赛事信息获取难题；②校园台球社团缺失；③寻找实力相当的对手。
3、典型用户和场景：
用户A：作为福大的一名学子，希望在大学能遇到志同道合的球友，但是福大上百个社团中，竟然没有台球社团的存在，他非常希望在这个开放包容的校园中，找到和他志同道合的伙伴
用户B：作为一名喜欢台球的年轻人，希望能遇到实力相当的对手。台球对战中如果实力水平相差太多，高手索然无味，新手备受折磨。身边的朋友不少，可是打台球的伙伴不多，一个实力相当的对手就更加难得了。
用户C：作为一名台球爱好者，时刻关注台球赛事的信息，却苦于台球赛事官网基本为国外网站，存在加载慢或干脆连接不上等问题，导致赛事信息查看，非常不顺畅

Q2. 是否有充足的时间来做计划?
A：有的。在项目正式开始前，我们分配出足够的时间来制定计划，为后面项目的顺利开展打好基础。

Q3.团队在计划阶段是如何解决组员们对于计划的不同意见的？
A：首先给每个人表达观点的机会，尊重各种意见，确保所有成员了解团队的整体目标和计划目的，然后进行深入讨论，努力找到各方都能接受的解决方案或妥协点。

Q4. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
A：1、合理分配任务：避免早期投入过多在复杂的安全模块，因为第三方登录由于域名备案问题需要其他方式绕开官方会导致耗费时间较长，进而导致耽误其他模块的开发。
2、代码规范：制定并遵循代码规范，提高代码质量，避免出现组员间相互看不懂代码的问题。
3、文档：应该尽早编写并更新接口文档，确保团队同步，当未知的问题出现的时候也能及时发现和修正。
4、敏捷开发：引入敏捷方法，提高项目灵活性和响应速度。

二、计划

Q1. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
A：经过两周的开发，已经完成了大部分功能，但是由于过程中会遇到技术难题障碍、数据库设计与功能设计与此前的设计环节存在冲突与缺陷、时间资源紧张等原因导致了没有达到预期的效果。

Q2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
A：目前没有。

Q3.是否每一项任务都有清楚定义和衡量的交付件?
A：是的。我们保证每一项任务都有清楚定义和衡量的交付件，这样不仅有助于项目的顺利进行，还能提高团队成员的工作效率和质量意识，推动项目的成功完成。

Q4. 是否项目的整个过程都按照计划进行?
A：虽然我们项目团队努力按照计划进行开发网站的工作，但由于各种不可预见和可控的因素的影响，项目的整个过程往往无法完全按照计划进行。然而，通过有效的项目管理、团队协作和风险管理，已经最大限度地减少不利因素的影响，确保项目能够按时、按质完成。

Q5. 在计划中有没有留下缓冲区，缓冲区有作用么?
A：有。关键功能的开发预留了一两天缓冲时间完成，这样能尽量减轻团队成员的压力、并作为风险管理策略来应对项目中的技术难题等不确定性因素。但是由于接口文档较晚编写，缓冲区时间被占用了。

Q6. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
A：做好合理安排，早日开始工作，多留几天缓冲时间来面对可能出现的问题，尽量不让队员加班

三、资源

Q1. 我们有足够的资源来完成各项任务么?
A：目前来说，大部分资源都是有的，遇到技术能咨询同学请教老师或者网上搜索免费的学习资料，时间资源可能有点欠缺，上一阶段暴露的问题还需解决，人力资源是够的，大家都主动积极配合组内工作。

Q2. 各项任务所需的时间和其他资源是如何估计的？
A：基于别人的开发经验，在加上组内讨论，根据实际情况一起得到的结论。

Q3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
A：测试的时间不太足够，人力和软硬件资源是足够的，因为开发时间有点晚了，给前后端的任务有点重，再加上过程中遇到些技术障碍，留给测试的时间就很少。不需要编程资源的难度和预估的差不多。

Q4. 你有没有感到你做的事情可以让别人来做（更有效率）?
A：没有。大家目前的工作都比较适合自己，也都是当时根据自己的想法来选择和安排的。

四、变更管理

Q1. 每个相关的员工都及时知道了变更的消息?
A：是的。所有组员通过qq群消息都知道变更消息。

Q2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
A：首先要做个优先级排序，明确每个功能的重要性和目的，以此作为之后判断的依据。然后在实际开发过程中，通过每天开会讨论总结，根据目前的进度情况，决定哪些功能可以在当前阶段实现，哪些需要推迟。

Q3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
A：有。界面还原度和原型设计基本匹配，界面交互性良好，逻辑正确。

Q4.对于可能的变更是否能制定应急计划?
A：遇到的时候，会紧急开会讨论，制定应急计划确保项目的顺利进行。

Q5. 员工是否能够有效地处理意料之外的工作请求？
A：在自己力所能及的范围内，大部分是能够处理的。

五、团队的角色，管理，合作

Q1. 团队的每个角色是如何确定的，是不是人尽其才？
A：评估每个团队成员的技能、经验、兴趣和潜力。通过了解他们的专长和兴趣，可以确定他们在团队中最能发挥价值的角色，然后进行成员自我评估，了解他们认为自己最适合担任哪些角色，最后综合考虑分配工作。

Q2. 团队成员之间有互相帮助么？
A：有。大家相处都很和谐友好，提出的问题都会有组员积极回复和帮助。

Q3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
A：及时沟通，一般都是鼓励大家说出自己的想法，评估各种方案的可行性，最后找到一个合适的解决方案，也会根据实际情况进行调整和修改。

六、设计/实现

Q1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
A：设计工作是在正式开始冲刺前就完成的，由整个小组共同讨论参与的，是合适的时间和人。

Q2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
A：有。因为每个人想法和理解能力会有点偏差，但是会通过沟通找到合适的解决方法。

Q3.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
A：
1、微信第三方登录产生的BUG最多。由于本项目组没有购买域名并备案，因此需要通过测试公众号与微信服务器进行数据传输，并且需要内网穿透。导致本地开发时出现BUG，部署上服务器也出现BUG（natapp的官网转发设置）。
2、发布后发现了前端浏览器总是拦截回应信息的BUG。由于JWT拦截器在WebMvcConfig的CORS配置前生效，导致启动拦截后前端浏览器接收到的信息总是被拦截（开发阶段后端在服务器前端用本地所以触发CORS预检）。之后将CORS配置调整到corsFilter中才解决这一问题。
3、根本原因在于前后端联调时间较晚，一直使用的ApiFox模拟网页请求，因此没有出现有关跨域跨源的问题，所以一直没有发现这个BUG。
Q4. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
A：两天进行一次代码复审，与互相测试同时进行。由同开发方向小组组员互相测试功能，确定功能无误后查看代码，根据注释理解代码工作流程并审查代码是否符合代码规范。如遇到不合规问题或可优化问题当场进行修改，确认修改完成并可运行后进行项目部署。

七、测试/发布

Q1.团队是否有一个测试计划？为什么没有？
A：有测试计划，会对当天完成的功能进行测试，以便及时发现问题。

Q2. 是否进行了正式的验收测试？
A：目前还没有，因为时间不太够

Q3.团队是否有测试工具来帮助测试？
A：后端使用Apifox进行数据mock和接口文档生成，并通过代码中注解的配置生成默认mock值进行测试。并编写有部分自动化测试完成对服务器的日常检验。

八、总结:

Q1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
A：初始级

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

Q3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
A：首先大家的沟通能力和协作能力都提高了，其次
对任务分配更合理了，提高了效率。

Q4.你觉得目前最需要改进的一个方面是什么?
A：将前后端联调融入到日常开发中，每两天联调一次而不是最终联调解决BUG。

...全文