成双成队——Alpha阶段问题总结随笔

成双成队 2024-05-22 23:03:42

这个作业属于哪个课程	软件工程实践-2023学年-W班
这个作业要求在哪里	团队作业—bate冲刺+事后诸葛亮
这个作业的目标	Alpha阶段问题总结
其他参考文献	《构建之法》

一、设想和目标

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

我们的软件要解决的问题是给同学们带来一个安全且实时的分享平台，解决当下同学们在使用“表白墙”等自媒体号时遇到的痛点；我们的软件定义的还是比较清楚，描述的比较清晰的。
是否有充足的时间来做计划?

时间还是比较紧张的，但是应该能够在限定时间内完成计划。
团队在计划阶段是如何解决同事们对于计划的不同意见的？

我们将不同的意见进行分类汇总，然后经过所有成员的投票，选出最终的方案。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

我们暂时还没有将产品发布给用户体验，但是我们已经了解并实现了大部分用户的基本功能需求。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

要学会挑重点，在项目初期我们规划了比较多的功能，但是没有考虑到项目期限的问题，到最后还是被迫砍掉了一部分，所以历史如果可以重来，我们会优先了解用户的主要需求和在现有产品使用上的痛点，做出有针对性的产品设计。

二、计划

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

原计划的工作最后基本都完成了，但是可能存在部分细节没有处理好的问题还没有解决。
有没有发现你做了一些事后看来没必要或没多大价值的事?

有的，因为功能解决方案选择的问题，我们选择的方案并不能按照预期顺利完成实现，导致我们花费了很多的时间在方案试错上，这浪费了我们比较多的时间，同时还没有结果产出。
是否每一项任务都有清楚定义和衡量的交付件?

并没有，对于主要的功能模块部分，我们有比较严格的复核与功能检查，也定义了比较明确的交付标准，但是对于一些比较小的功能我们的管理就比较宽松，没有非常明显的错误即可，其余的问题留到测试环节。
是否项目的整个过程都按照计划进行?

因为中途发生了一些小插曲，项目并没有很好地按照计划进行，有一些延误。
在计划中有没有留下缓冲区，缓冲区有作用么?

有的，有作用，因为第一次尝试，我们的计划安排不够合理，缓冲区给我们留下了一定的容错空间。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）

在将来的计划中我们会更加注重留出项目进展不够顺利的容错空间，同时将多个项目的完成时期错开，保证计划的合理性，尽量避免通过加班来赶上任务进度。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

在这次的任务中，我们没有考虑到可能产生的任务冲突的问题，同时有多个任务需要完成，导致我们团队的开发时间比较紧张，如果历史可以重来一遍，我们会提前安排好任务时间的分配，保证团队可以专心于一个项目的开发。

三、资源

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

资源比较紧张，首先是时间有一定的限制，其次是技术栈的原因，团队成员基本都在一边学习技术一边开发，然后服务器等设施也比较短缺，存在一定的限制与压力。
各项任务所需的时间和其他资源是如何估计的，精度如何?

按照任务复杂度和可能需要的学习时间成本进行估计，精度尚可。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

人力和软硬件资源基本足够，时间有点紧张，我们确实低估了那些不需要编程的资源的难度。
你有没有感到你做的事情可以让别人来做（更有效率）?

有的，比如UI设计等方面，这方面的任务交给专业的人选会更加有效率，并且效果也会更好。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

本次任务中人员分配不够合理，前端开发的人员分配过少，任务也比较多，导致前端的开发人员压力较大，如果历史重来一遍，我们会考虑对前后端开发人员比例进行重新分配。

四、变更管理

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

我们采用了开发文档协作编辑，项目git管理的方式，保证团队成员都能第一时间看到变更。
我们采用了什么办法决定“推迟”和“必须实现”的功能?

系统必要的功能优先且必须实现，没有也不影响用户使用，但能带给用户更好体验感的功能推迟实现。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

有的，对于主要的功能模块部分，我们有比较严格的复核与功能检查，也定义了比较明确的交付标准，但是对于一些比较小的功能我们的管理就比较宽松，没有非常明显的错误即可，其余的问题留到测试环节。
对于可能的变更是否能制定应急计划?

能，如果时间比较紧张，我们会采用一种能暂时解决问题的方案，然后在下次迭代中进行修改完善。
员工是否能够有效地处理意料之外的工作请求？

是的，对于项目的变更，我们团队的成员都能很快地做出响应并进行修改。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

在项目开发中产生变更是常态，要能够及时对变更做出响应，要学会处理突发情况，如果历史重来一遍，我们会在计划时考虑的更加周全，减少变更产生的数量，同时对变更采取更好的处理方式，避免多次修改。

五、设计/实现

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

设计工作在项目开发前进行，由所有项目成员共同完成，我们团队认为时间比较合适，但是因为团队成员都没有完整项目的开发经验，可能不是很擅长项目的设计工作，人选不一定很合适。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？

有的，我们在尽可能保证理解和满足用户需求的基础上，选择出一项比较完备的设计方案。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

是的，这些工具还是比较有效果的，提高了我们的开发效率。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

资源和投稿模块的bug最多，因为关于文件上传和下载的操作我们团队不是很熟悉，所以在一步步的试错中逐渐完善，发布之后发现的大多是一些细节上处理不到位的bug，主要是在设计阶段没有考虑周全。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

在开发时尽量保证符合规范，阶段性完成后对修改过的代码进行规范性检查，基本都严格执行了代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

良好的软件设计方式会让项目的开发计划和目标更加明确，如果历史重来一遍，我们会将软件设计方法更规范地贯彻到我们的项目设计中，并在开发中严格遵守。

六、测试/发布

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

有，我们在开发的过程中会同步进行单元测试，在模块开发完毕后进行集成测试，最后各模块整合进行整合测试。
是否进行了正式的验收测试？

还没有进行，因为项目尚未完成开发。
团队是否有测试工具来帮助测试？

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

后端采用白盒测试，保证基本功能可以正确执行，前端采用黑盒测试，发现前后端可能存在的问题和异常情况，这些测试工作还是比较有效的。
在发布的过程中发现了哪些意外问题？

在发布过程中暂时没有遇到问题。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

测试也是开发环节中重要的一环，如果历史重来一遍，我们会更加重视测试环节的任务。