标签：完成 任务 冲刺 Beta 计划 测试 alpha 团队 我们
| 这个作业属于哪个课程 | 2021春软件工程实践|W班 (福州大学) |
|---|---|
| 这个作业要求在哪里 | 团队作业六——beta冲刺+事后诸葛亮 |
| 团队名称 | unity从入门到入土 |
| 这个作业的目标 | 完成Beta冲刺 |
| 参考文献 | 《构建之法》 |
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件主要是为了提供一个符合现代人节奏，开发益智的unity架构游戏，针对的用户是需要提供社交手段的年轻人和为消磨时间的青年人群。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
大部分功能基本完成，但是总体实现的接口尚未完成，所以暂未达成目标。完成了所有功能，按照原时间交付了，但是2个接口未完成，准备在beta阶段继续完成。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
软件工程的质量提高了，我们有更合理的任务安排和任务细分。我们将本来不够具体的内容继续细化成更小粒度。提高的部分从模块的数量来讲，与最开始计划的增加了一倍。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
我们暂未完成我们的软件发布，功能暂时只在内部进行测试。（有人玩就算成功！
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
凡是一定先做计划，后完成任务。组内成员之内的交流十分关键，我们要照顾整体的进度，不能因为一部分的难题克服不了，就延误其他部分的完成，成员之间不仅要汇报自己的进度，还需要了解与自己对接的成员的状况与代码规范以及代码的整体结构，凡事要根据编写的文档来完成项目。历史重来，我们会转变一个思路，不一定做桌游了orz，逻辑太难了，ui太难变好看了，原生开发真的是摸着石头过河！
计划
1. 是否有充足的时间来做计划?
我们在alpha冲刺结束时，就认真规划好我们这一阶段的任务。基于上次的经验，我们相信，这次我们的项目会更有计划，更加完善。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们会通过会议的方式，通过组内讨论投票，针对提出的不同意见，选择其中最合适我们的选项，来改进或者完善我们的项目。
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
原计划的工作中，因为对工作量的错误估计，一部分i项目尚未完成，返回值之间的逻辑判断，需要做更多方面的考虑。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
暂时没有，我们的每一步都是按照我们原本的计划进行，在最后总结时，也认为我们这次冲刺的每项任务都是我们项目中需要完善需要完成的地方，倒是一些地方，在我们设计时没有想到，在冲刺里补充完善的部分。
5. 是否每一项任务都有清楚定义和衡量的交付件?
每一项任务都有清楚的定义 ，这也是我们再进行单元测试和其他测试时的主要依据，根据我们之前各类设计书和需求书的原则下，每项任务都是有出处的。
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
大部分按照计划进行，只是留给测试的时间太少，一些unity操作不当或者运行内存过大导致的“死机”行为给设计同学造成了较大困扰。风险的产生一方面时灭有很好的进行时间安排，没有对工作量完成一个好的估计，另一方面，确实是一个软件的入手难度比我们想象中大一点，熟练掌握需要更多的尝试与探索。
7. 在计划中有没有留下缓冲区，缓冲区有作用么?
缓冲区我们留在了冲刺中间的一段时间，这部分的时间，我们会对前一段完成的任务进行整理，对其中不足的地方进行修改，对下一阶段的任务进行准备与思考。缓冲区的作用，正是给人以反思总结，养精蓄锐，提高干劲的！
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
未来的计划，会对上一个阶段的一些错误进行反思——测试留多一点时间，组员内多多交流，在完成预期计划前，我们是按部就班完成我们的任务的。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
合理的计划是成功的前提，如果历史重来，我们一定会重新修订我们的计划，合理分配我们的任务，争取再多拿点分qaq
资源
1. 我们有足够的资源来完成各项任务么?
时间人员方面，我们的资源是完全够的。大部分计划基本都按时完成，美工资源还算足够，但是有更多可借鉴的资源会更好。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
根据我们项目的规模和之前软件工程实践作业的经验估算的，基本上与我们估计的时间和资源差不多。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间留的少了一些，其他资源是足够的，美工设计的难度确实很高，想要做出好看的ui不仅仅需要审美水平，还需要有一定的绘画功底。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
我们大致分配了我们的任务需求，虽然一部分同学可能在项目方面更有经验，但是任务只让他一个人完成肯定是不行的，我们已经在可调动范围内做到了最好的人员安排。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
合理调动资源，对资源的分配依照我们的计划进行安排，要保证所有的资源都有作用，不应该产生不必要的浪费，提高我们的资源利用率。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
是的，我们在每项任务的发布与变更都会事先与组内成员进行商议，每个组员都会及时了解任务的状况。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们将我们的任务分成主次两个部分，次要的功能，是指不影响用户体验的功能，而主要功能是指在我们项目里必须要完成的部分。在主次不明显的功能的情况中，我们会考虑我们的时间资源的安排，加上小组成员的讨论，决定它是否是一个必须要做的功能。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
实现所有主要功能，能够正常的运行并完成所有值钱预定好的操作，测试无误。
4. 对于可能的变更是否能制定应急计划?
我们在每日的站立式会议中会记录当前项目的进度，针对计划以外的特殊情况，如果影响了我们的项目进度，我们会让该天项目任务完成的同学去寻找解决办法。
5. 员工是否能够有效地处理意料之外的工作请求？
是的，我们是一个十分具有团队精神的队伍，组员在完成自己任务的同时，会帮助其他还未完成任务的同学，在出现意外状况时，大家在讨论后，会一起帮助这位组员完成这项任务，保证我们项目的正常进行。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
对变更和特殊情况的出现，我们要预留一部分时间资源，针对解决这部分的情况。
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作主要是由前端的同学完成的，根据我们的原型设计来完成我们的设计任务。主要的ui设计和素材收集，是由我们的美工同学和前端同学共同完成的。这些同学审美能力好，而且有一定的web基础和绘画功底，我们认为这几名同学已经完成的十分优秀了。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
我们会采取组内投票的方式，在讨论过后，选取大家都认可的版本。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
单元测试使用的是IDEA的junit，uml的完善使用的是staruml，还有原型设计工具axure，api测试postman。这些工具很好的帮助我们完成了这几部分的任务，提高了我们项目软件工程的质量，经过小组的进一步探讨，一些活动图的功能进行了完善，类图的设计修改的更为合理，这些都是在小组完成项目时发现更好或者更符合我们当前项目设计的修改，已经在设计阶段和总结阶段完成了我们的uml文档。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
逻辑判断的判断bug较多，这是因为我们在刚开始编写代码时，一些逻辑的实现思考的不够深入，针对一些逻辑的判断没有想到所有的可能出现的结果。发布时，前端unity的地图出现了警告，但是不影响正常使用，这个问题是对软件的使用不够熟悉，一些实现没有考虑周到造成的。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
根据接口文档统一规范变量名与返回值。在整合代码时，进行了代码复审，保证了这些代码严格执行代码规范。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
要考虑到任何可能出现的情况，保证项目代码的健壮性，对软件的使用要更加熟练。
测试/发布
1. 团队是否有一个测试计划？为什么没有？
因为作业要求里有要求，所以我们制定了一个测试计划。
2. 是否进行了正式的验收测试？
使用整体的测试和人工进行了对整个项目的验收测试.
3. 团队是否有测试工具来帮助测试？
| JProfiler 9.2 | 用于后端进行性能测试，查看运行时项目的运行状态，检测在运行时的异常。 |
|---|---|
| IDEA Junit | 用于后端进行单元测试，检查功能的返回值是否有误。 |
| Postman | 用于接口测试，对接口的post/get请求进行检测 |
4. 团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
使用JProfiler 9.2测量并跟踪软件的效能与压力测试。测试中尚未出现问题，可能是测试的数据模拟不出十分具体的操作。
5. 在发布的过程中发现了哪些意外问题？
发布的过程中正常尚未发现问题。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
测试会加大力度！代码编写完成时，立刻进行单元测试，这样在发布的时候就会节省不少时间。
团队的角色，管理，合作
1. 团队的每个角色是如何确定的，是不是人尽其才？
是的,每个角色都是根据自己擅长的方面进行调度的,每个人都很好地完成了自己的工作。
2. 团队成员之间有互相帮助么？
有的，在组员需要帮助时，其他组员会去帮助其解决问题。完成任务的同学也会帮助还未完成的同学，协助他完成任务。
3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
我们会再开一次会议，将所有问题摆在纸面上，每个问题逐步分析是否有好的办法解决这个问题，当遇到难题难以攻克或者资源调度不够合理的状况，组员们也会谅解和帮助一同攻克难关！
总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
属于CMMI第二级。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段。
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
前一个里程碑属于一个开荒的阶段，本次更像一个全面武装再去攻克难关的过程，因为我们更有经验，也更有能力，所以我们相信会做的更好。
你觉得目前最需要改进的一个方面是什么?
美工确实是难以再进步的一个问题，我们的美工已经十分优秀了，但是与竞品相比，其庞大的美工团队是我们无法睥睨的。
标签：完成,任务,冲刺,Beta,计划,测试,alpha,团队,我们 来源： https://www.cnblogs.com/kakasong/p/14867756.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。