688
社区成员
发帖
与我相关
我的任务
分享| 这个作业属于哪个课程 | 2023年福大-软件工程实践-W班 |
|---|---|
| 这个作业要求在哪里 | 团队作业——beta冲刺+事后诸葛亮 |
| 这个作业的目标 | alpha阶段问题总结 |
| 其他参考文献 | 无 |
1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
我们的网站为了解决用户想做菜但是不知道做什么、怎么做的问题。
定义很清楚,整个网站围绕做菜展开。
典型用户和典型场景:
1.厨房新手,想吃某道菜但不知道怎么做。
2.厨房新手,手里有部分食材,但不知道食材怎么处理、能做什么菜以及怎么做。
3.厨房老手,想分享自创的菜谱。
2. 是否有充足的时间来做计划?
有充足的时间做计划,在发布任务后以及alpha冲刺结束后不断抽时间与组员进行讨论开会,规划项目下一步计划。
3. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
组员提出不同的意见后,经组长权衡后做出决定。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
用户量, 用户对重要功能的接受程度略低于我们事先的预想,但我们离目标更近了。
5. 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
要勤于善于利用团队协同工具,直观的掌握每个组员的任务进度。如果再来一遍,我们会利用各种工具来管理团队项目,包括代码管理、任务进度管理等。
1. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
部分组员未能完成全部任务,原因是组员本身技术的学习进度过慢占用了冲刺时间,所以未能在规定时间内完成所有任务。
2. 有没有发现你做了一些事后看来没必要或没多大价值的事?
在项目的美化上花费了大量的时间,事后发现美化还是要找专门的美术搞,我们花了很多时间效果并不是很好。
3. 是否每一项任务都有清楚定义和衡量的交付件?
每一项任务在项目计划阶段都有明确的定义,即使实在后期做了相关的调整,也会及时与各组员进行沟通,明确任务的具体内容和交付件。
4. 是否项目的整个过程都按照计划进行?
项目的整个流程是在按照计划进行,但是组员的进度有快有慢,所以项目的进度会时有波动。
5. 在计划中有没有留下缓冲区,缓冲区有作用么?
在计划中有留下缓冲区,缓冲区用来解决一些突发情况以及项目的检查和优化。比如某模块出现较大bug难以修复,会需要较长时间来修复。或者项目完成后利用缓冲时间对项目进行更加全面的测试以及优化。
6. 将来的计划会做什么修改?
根据上阶段的任务完成情况,接下来的项目计划会更加侧重于前端的开发。
7. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
如果再来一次,我们会在任务分配机制上做一些调整,根据能力和任务难度进行划分。
1. 我们有足够的资源来完成各项任务么?
资源方面并不是很充足,我们没有足够的美术素材,没有足够的时间精力,也没有长期稳定的服务器。
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
各项任务根据负责的组员的能力以及该组员的课程量来估计所需时间,其他资源根据任务难度和任务期望完成度来估计。
3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间,人力和软件/硬件资源足够,对于那些不需要编程的资源 (美工设计/文案)没有低估难度,但由于没有擅长该部分的组员,所以还是遇到一点小问题。
4. 你有没有感到你做的事情可以让别人来做(更有效率)?
没有,或许别的组员有,但是效率高的成员也有自己的任务,不可能完成所有他擅长的任务。
1. 每个相关的员工都及时知道了变更的消息?
会及时通过线上或线下等途径让相关成员及时知道变更的消息。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据对项目的计划,讨论根据功能的重要性和实现难度决定“推迟”或“必须实现”。比如注册登录、查看发布菜谱等核心功能是必须实现的。
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
项目的出口条件是能够满足用户的基本需求,即可以登录后按照特定条件查找菜谱并查看内容。
4. 对于可能的变更是否能制定应急计划?
对于可能性较大的变更能够制定应急计划,但还存在部分可能性较小的变更未考虑到。
5. 员工是否能够有效地处理意料之外的工作请求?
组员在日常生活中能够合理安排调整自己的时间,能够有效地处理意料之外的工作请求。
1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
在选题之后开始逐步设计,由组长主导,和组员一起讨论设计。是合适的时间和合适的人。
2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
没有,在设计过程中遇到问题都会进行讨论,得出一个确切的结果,否则会影响项目后续的开发。
3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
在实现过程中有运用一些测试工具来帮助实现,这些工具非常有效,在开发过程中利用这些工具能够帮助我们及时发现bug并以较小的代价修复它。
4. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
发布功能产生的bug最多,因为它的难度较大,需要发布视频。在发布之后没有发现很重要的bug,因为我们会在开发过程中不断的进行测试,很多bug在出现早期就已被发现并解决。
5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
代码复审是前后端负责人与代码编写者一起进行,严格执行了代码规范。
1. 团队是否有一个测试计划?为什么没有?
有提前制定测试计划,并且在开发过程中执行。
2. 是否进行了正式的验收测试?
安排测试人员进行正式的验收测试。
3. 团队是否有测试工具来帮助测试?
不同的测试阶段利用不同的测试工具进行测试。
4. 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
安排测试人员利用工具测量并跟踪软件的效能,从实际运行的结果来看,测试暴露了我们网站的部分之前未发现的问题,应该针对暴露的问题进行改进。
5. 在发布的过程中发现了哪些意外问题?
部分接口对接过程中出现较大bug,导致项目进度受到较大影响。
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我觉得团队目前的状态处于第四级:已管理级,为软件产品和过程都设定了量化的质量目标。
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我们的团队经过alpha冲刺处于规范阶段,但是由于组员的变动,部分组员还处在磨合阶段。
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
团队的协作能力得到较大提升,且团队对项目有了更加清晰的认知,在编写代码以及修复bug上更加得心应手。
4.你觉得目前最需要改进的一个方面是什么?
我认为最需要改进的方面是任务的分配,保证不同能力强度的组员的能力都能得到充分的利用。