青屿送词队——alpha阶段问题总结随笔

青屿送词队团队 2023-05-23 22:33:32

这个作业属于哪个课程	2023年福大-软件工程实践-W班
这个作业要求在哪里	软件工程实践作业
这个作业的目标	beta冲刺+事后诸葛亮
其他参考文献	构建之法、Git

1、设想和目标

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

我们的软件要解决福大学子衣柜整理烦恼、单品分类记忆模糊和衣物闲置问题，定义清晰明确，对典型用户和典型场景有清晰的描述。

（2）是否有充足的时间来做计划?

在Alpha冲刺作业发布后一天内就整理并细分作业要求供成员按意愿和能力选择，有充足的时间做计划并计划基本周全。

（3）团队在计划阶段是如何解决同事们对于计划的不同意见的？

根据多数成员意见和由组长进行利弊分析后进行最终决定。

（4）用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

实际比预想的好，从最初的选品介绍遭受多方质疑和询问到这次产品开发至一半的alpha冲刺答辩，助教和老师表示想要使用，身边同学也更加期待，让我们团队更有动力坚持下去，继续完成剩下小半却也很重要的部分。

（5）beta冲刺的任务需进一步明确

我们在alpha冲刺前确认任务时便已初步确定两次冲刺分别需要完成的内容包括对应的功能实现，但没有在博客体现，是我们的失误。

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

不能因为同学个人意愿而让任务量分配不均，导致部分成员工作量骤增，不能更好的保证任务完美度，以及部署的效率比预期的低很多，我们需要尽快进行服务器部署，并且加大对工作量分配的重视程度并且注意交流内容能够最大化呈现给大家。

2、计划

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

我们在alpaha冲刺中部署上没有长期的服务器资源。

（2）各项任务所需的时间和其他资源是如何估计的，精度如何?

各项任务所需时间是根据每位组员已有能力和学习能力与积极性故居的，精度停留在组长对每个人的调查了解和之前的项目进行的完成度和质量。

（3）测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

不够，只有组长一人能够完成测试工作，对于美工设计最开始便给予重视，所以没有低估难度，衣物整理设计也没有低估难度，加大贡献度并让一组员大部分时间投入在此。

（4）你有没有感到你做的事情可以让别人来做（更有效率）?

没有，曾尝试这样的做法，导致我需要不断的提出修改意见，并且实际完成质量较低，但我能做的事情我一般会根据组员能力和态度去分担，毕竟团队的力量是强大的，我只需要负责我认为我才能做好的部分，其余组员加上大家的共同修改意见也能够做好任务。

（5）项目开发进展几乎与理想状态完全吻合？！是否有每日获得进展；

是的，除了服务器部署问题导致测试上的自动化测试工作推迟和完成，其他任务均已完成，所计划功能都已实现，只是功能上还需要继续优化，每日我作为组长都会确认每人进度，并且每人的任务量都在她们的已有能力和学习能力之内，我会进行督促和完成。

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

我们学到了任务尽早分配的重要性，如果历史重来一遍，我们会改进任务分配的具体度和先一步优化每人基础工作量。

3、资源

（1）多位组员的贡献度过于相似，请解释

我们在alpha冲刺前便将任务细分并按工作量和难度细分成对应贡献点，除一人均达到合格贡献点，部分组员选择难度高的任务，部分组员虽然选择轻松的任务，但是任务量很多，都达到了整体任务平均完成度，因此剩余可分配贡献点较少，只能以小数点区分。

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

我认为任务量细分的有些大，导致有组员所作的贡献较少，不应该以意愿为主，而是以每个人都需为团队贡献较多为主，如果历史重来一遍，我会根据大家能力将轻松的任务应有的量先行直接分配给能力较弱者，之后再做意愿任务选择。

4、变更管理

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

在每日的站立式会议下，每位参与组员都能够及时知道变更消息，因事不能到场的我也会代为总结转达与之有关的部分。

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

我们采用产品框架和各功能关联度去决定，最基础的产品框架是注册登录与首页，个人中心和衣柜相对产品整体关联性较高，所以上述优先设计，而拍照上传，自由搭配与加入穿搭夹关联性很高，因此放在下一阶段实现。

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

我们对此的定义是任何一名用户在正常网络下都能够正常访问我们的网页链接。

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

能够制定紧急计划，在这次的测试工作中，由于项目部署较慢，采取将自动化测试工作推迟，在前期采取参与前后端开发代码测试，以用户角度模拟数据在前端进行测试，尽量减少开发错误。

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

能，我们的数据整理人员最初能够定下也是因为该同学有一定的前端能力和认真学习的态度，因此能够接收增加开发一个前端首页界面的工作请求并完成较好。

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

我们学到了要有居安思危学会变通的思想，提前预估可能出现的困难并准备解决措施，如果历史重来一遍，我们会更加重视部署工作。

5、设计/实现

（1）设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

设计工作在选题确认后和需求分析一起进行，由负责之后前后端角色的组员设计，是合适的时间和人，因为在后续中设计的同学也都参与了前后端设计，对整体产品和功能关联更为了解。

（2）设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有遇到，是团队集中讨论并画出草图最后加班赶工设计。

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

有用到starUML绘制流程图，Axure 10绘制原型设计，request和robotframework框架进行自动化测试工作

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

注册登录产生的Bug最多，因为有验证码注册功能，因此对于验证码的实现遇到了比较多的问题，在发布之后遇到注册登录接口失效的问题，在开发的时候测试的次数和用户量不够导致没有发现。

（5）代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

代码复审是由后端人员与制定代码规范的组员共同审核确定，执行了代码规范。

（6）项目尚不能直接演示？

是的，由于项目部署过慢，前后端采取内网穿透获取接口，导致只有开发人员才能访问

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

我们学到了部署服务器在前后端任务清晰明确下也同样重要，之后我们会尽快部署，并在beta冲刺结束后争取能够直接演示，如果历史重来一遍，我会最先在任务安排时便询问部署情况和实现者，确保服务器的持有并部署。

6、测试/发布

（1）团队是否有一个测试计划？为什么没有？

有测试计划报告，并根据实际情况随时调整。

（2）是否进行了正式的验收测试？

由测试人员进行了正式的验收测试

（3）团队是否有测试工具来帮助测试？

有，采用request+robotframework测试框架来帮助自动化测试工作的进行

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

团队通过性能测试测量并跟踪软件的效能，从软件实际运行的结果来看，测试工作能够减少人工重复测试工作，但对于测试范围还需要扩大。

（5）在发布的过程中发现了哪些意外问题？

发现注册与登录的接口意外缺失，导致不用注册登录便能进入主页和其他页面。

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

我们学到了除了自动化测试其他测试也同样重要，如果历史重来一遍，我们会修改测试计划，也注重其他测试工作。

7、总结:

  你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
  你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
  你觉得团队在这个里程碑相比前一个里程碑有什么改进? 
  你觉得目前最需要改进的一个方面是什么?

1、我认为我们团队目前的状态属于CMM中的第4个档次——已管理级（Managed），我们已确定产品和过程需要达到的质量目标，并且在过程中我们每位组员和实际项目开发的质量和效率都有做数据显示，是可度量的，并且我会全程跟进与控制每位组员和整体项目的开发进度，并且进行一定的预测分析该产品的质量趋势是否能够达到我们的质量目标并作出相应决定。

2、我觉得团队目前处于创造阶段，我们目前都在齐心协力开发这款产品的后续功能与其他。

3、我觉得团队在这个里程碑相比前一个里程碑中，首先是沟通的次数大大增加，每日总结的出现让我能够确定每人贡献每日沟通，每日会议能够让团队进行项目各自遇到问题的交流，融合度大大增加。

4、我觉得目前最需要改进的一个方面是代码开发能力弱的组员该如何确认任务分配并保证整体项目运行质量。

...全文