HairTeam——Beta阶段事后分析

设想和目标

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

我们开发的软件为一款3D手机游戏，其游戏机制基于传统的“自走棋”玩法，同时融入了炉石传说等游戏内的卡牌机制，同时兼顾了游戏玩法的随机性与策略性。游戏利用移动端优势凸显手游的轻量化优势，使得用户可利用碎片化时间游玩，同时通过游戏内的在线联机功能，用户可以享受到快速的共同游玩的体验。

典型用户与典型场景大致按玩家年龄划分为四大类，详见β阶段的功能规格说明书
我们达到目标了么（原计划的功能做到了几个？按照原计划交付时间交付了么？原计划达到的用户数量达到了么?)

beta阶段原计划中主要新增了游戏内的教程功能，新增了一组英雄卡牌，并加入了联机房间、联机游戏场景，其中联机游戏模块暂时支持至多两名玩家同时进行游戏，原计划中的功能均在计划发布日（6.16）之前完成了开发，并按时进行了软件发布。原计划中用户目标为估计下载量150人左右，日活跃用户目标为20人，其中日均活跃用户为二次上线进行游戏的老用户。截至6月18日，累计老用户上线人数超过120人，同时我们统计了使用联机功能的次数。
和上一个阶段相比，团队软件工程的质量提高了么？在什么地方有提高，具体提高了多少，如何衡量的？

与α阶段相比，团队在软件开发中更加注重信息的安全性，将服务端/客户端交互使用的HTTP协议更换为对报文加密的HTTPS协议并在服务端实现了客户鉴权机制。同时团队内分工更加灵活合理，采用了自愿选择和组长安排相结合的方式，遇到分工冲突在协商后由组长安排；我们权衡了不同组之间和组内不同成员之间工作量和任务难度的差别，并据此在后续调整以保证成员平摊任务负担。
用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

根据在发布博客、微信端的用户反馈，我们统计到主要的意见为联机功能方面的，比如联机对战延迟存在问题，或对战没有聊天/好友功能。
新阶段的经验与教训

β阶段所做的代码测试工作不足，如果再重来一遍，团队会合理使用Gitlab的CI/CD功能，加强游戏客户端以及服务端的单元测试与自动化集成测试的工作，β阶段中服务端进行了单元测试，而客户端方面，游戏场景内脚本的测试仍大多使用传统的场景测试方法。

计划

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

beta阶段相对于alpha阶段，做计划的时间相对充裕。

首先在alpha展示结束后，我们有一周的时间进行反思与总结，我们可以在这个时间计划我们beta阶段的工作；其次，接下来的一周是转会人员的确定和转会和新人招募，我们同样可以利用这个时间进行beta阶段的计划。与alpha阶段相比，beta阶段我们计划的时间相当充裕，我们在这个时间确定了beta阶段的任务和分工。
团队在计划阶段是如何解决同事们对于计划的不同意见的？

我们beta阶段与alpha阶段的任务性质稍有不同，beta阶段我们的工作是完成相对独立的各个功能模块，所以模块内部的不同意见一般是由模块内小组商量解决的，如果无法解决则上报PM进行协商。

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

我们计划的任务基本完成，也就是说，我们gitlab上的每一个issue都能确认无误地进行关闭。

成员	具体任务	花费时长（h）	预期结束时间
李辰洋	房间创建、加入UI	6h	5月28日
	Photon服务器连接房间创建加入逻辑	6h	5月30日
	网络部分逻辑代码	16h	6月1日
	用户登陆、注册部分后端优化	4h	6月3日
	房间测试与验收	1h	6月5日
	战斗网络同步验收	1h	6月7日
	后端优化测试与验收	1h	6月9日


严宇皓	新增教程：主界面UI和卡牌管理介绍教程	12h	6月1日
	优化用户体验（游戏外操作界面）	2h	6月5日
	游戏外教程测试与验收	1h	6月7日
	卡牌测试与验收	1h	6月8日
	游戏打包测试与发布	2h	6月9日



张书恺	新增教程：游戏中规则静态介绍教程	8h	5月31日
	新增卡牌UI	8h	6月5日
	教程测试与验收	1h	6月7日
	卡牌测试与验收	1h	6月8日
	测试和优化卡牌生成逻辑	3h	6月9日


赵子轩	新增教程	8h	5月31日
	新增卡牌：在战斗中的实例化	8h	6月5日
	新增卡牌：在战斗中对其他角色的影响	8h	6月5日
	新增卡牌：在战斗中的生效时间	8h	6月5日
	教程测试与验收	1h	6月7日
	卡牌测试与验收	1h	6月9日

吴承沣	网络部分逻辑代码	16h	5月31日
	复刻联机场景至所有地图	1h	6月1日
	同步游戏流程阶段	4h	6月7日
	玩家间数据同步测试	2h	6月8日
	战斗网络同步验收	2h	6月9日

仇越	联机游戏流程逻辑框架	8h	5月31日
	主/从玩家交互逻辑框架	4h	6月4日
	游戏场景素材整合，内存压缩	1h	6月6日
	游戏内UI界面优化	8h	6月7日
	战斗网络同步验收	4h	6月9日

但是由于时间紧张，加之烤期压力，我们在这些任务的质量上有一些折扣，有一些期望的功能没有时间完全实现，比如虽然我们整合了场景素材，大大压缩了程序所占内存，但效果还是不够理想；还有我们虽然实现了扩充更多的卡牌，但是只是对角色卡牌的扩充，原本我们还想扩充功能卡牌，但是由于时间紧没能实现。

有没有发现你做了一些事后看来没必要或没多大价值的事?

beta阶段我们做的工作都是比较有意义的，都是完成任务的必要工作。

唯一可能没有必要的工作，就是在联机对战阶段我们为游戏对战逻辑单独创建了一个脚本，与原本单机对战的脚本耦合率高达70%，可以将两个脚本统一成一个，这样处理可能会造成一些风险，并且会增加任务负担，在稳定性和代码质量之间，我们选择了前者。

是否每一项任务都有清楚定义和衡量的交付件?

我们每一项任务都有比较清楚的定义和一定的交付标准。

任务	交付标准
房间匹配机制	创建方输入房间id创建房间，加入方输入房间id加入房间
联机对战机制	1.双方进入相同的对战场景 2.双方同步时间戳，游戏阶段，主体生命值，角色位置状态和动作 3.一方退出游戏，双方回到准备界面
卡牌扩充	1.扩充角色卡牌，具有不同的外观，属性，特效以及区分于其他角色的战斗特性 2.扩充功能卡牌，使用后具有一定的功能特效，能给己方带来战斗上的收益
......	......

是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

整个项目基本按计划进行，但是在发布阶段我们出现了一些问题，安卓apk运行与我们在电脑端调试模式和模拟器模式运行有一定的出入，经过核实我们认为是代码版本不统一的问题。
在计划中有没有留下缓冲区，缓冲区有作用么?

计划中留下了一些缓冲区，在发布阶段若还有测试工作没有完成，可以将发布延后。

事实证明我们的缓冲区是有效的，因为这个时间大家都在考期，真正有时间全组一起测试解决问题的时间也是在接近发布阶段的末期。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）

beta阶段我们的工作还是有许多不足，因为考期时间紧张，我们有一些希望完成但是没有完成或者说完成度不高的功能点，之后我们还会有计划进行团队项目的开发，我们希望我们能有更充裕的时间投入到项目中。

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

beta阶段我们虽然完成了计划中的功能模块扩充，但是存在一些望完成但是没有完成或者说完成度不高的功能点，如果有机会，我们希望能更好地规划时间，尽可能更多地投入到项目中，尽可能更多地安排共同空闲时间进行线下面对面开发。

资源

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

资源完全足够。就我们使用的unity来说，素材、教程等都不难找到。
各项任务所需的时间和其他资源是如何估计的，精度如何?

基于难度、现有开发经验以及其他人的完成相似项目的时间进行估计。有了alpha阶段的经验，本次时间估计给细节调整预留了充足的时间，因此时间估计较为准确。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

相较于上一阶段，本阶段测试的时间和人力有些欠缺，硬件资源一如既往地不够。主要原因一是临近考期，复习需要占用大家大量时间；二是安卓机型五花八门，不同机型可能有着很大的区别，想要测试完全几乎不可能。

由于做游戏美工等方面也是大头，故这些不需要编程的资源我们一开始就做好了慎重的估计，并没有低估其难度。
你有没有感到你做的事情可以让别人来做（更有效率）?

不会。本阶段大家的分工与上一阶段有很大关系，因此每个人对于其负责的部分了解程度不同，自己来干自己负责的部分当然更有效率。
我们学到了什么？如果历史重来一遍，我们会做什么改进？

时间分配、团队沟通都是非常重要的。在考期的影响下时间分配的难度会大大增加。如果重来，在时间分配的时候会更多地考虑考期地影响并做好风险管理。

变更管理

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

是的。
- 首先，我们beta阶段整个团队分成了三个不同的部门，分别为联机对战组、教程组、卡牌组，不同组建立了专门的微信群负责消息同步与整合。
- 其次，基于Plastic SCM与GitHub优秀的分支管理功能，我们为每个小组建立了不同的分支进行项目的提交与合并。
- 最后，我们规范了每次项目修改上传时的commit格式，要求必须清晰简明地列出项目修改的部分，同时每次更新后都需要通知PM，并由PM同学对需要了解变更内容的成员进行通知。
我们采用了什么办法决定“推迟”和“必须实现”的功能?

根据Alpha阶段老师助教与大众评审团提出的意见，我们收集到的用户意见，以及我们在项目立项时明确的目标，我们组beta阶段”必须实现“的功能为：联网对战与软件、游戏教程。其中由于联网对战模块难度与工作量较大，并且发布到平台后的未知情况较多，需要进行大量的传统测试，因此将其余功能都定位可以”推迟“的功能。
项目的出口条件（Exit Criteria）是否得到清晰的定义?

即实现”必须实现“的功能，满足功能的完整性(涵盖所有指定任务和用户目标)与功能的正确性(产品能提供正确的功能使用结果)，同时在测试阶段通过全部的测试。
对于可能的变更是否能制定应急计划?

这一点的实现主要依赖于PM同学的能力和对团队每个成员进度的跟踪程度。首先我们小组的PM为全栈工程师，本身即能处理大部分的问题，做到随叫随到，见缝插针。其次我们采用提交-更新GitLab issue的方式跟踪每个成员的项目进度，PM也能纵览大局，随时对可能的变更制定因”人“制宜的应急计划。
员工是否能够有效地处理意料之外的工作请求？

由于在Alpha阶段准备阶段我们小组全体同学均已掌握Unity、C#等技术栈的使用，且在转会期并没有人员变更，因此团队全体成员都有能力项目各个部分进行测试与修改，即能够有效地处理意料之外的工作请求。
我们学到了什么?如果历史重来一遍，我们会做什么改进？

可以适当更换每位成员在Alpha阶段与Beta阶段负责的技术栈，不仅每个人能得到充分的训练，并且在遇到应急情况，需要抽调其他部门人员进行补救时，也能应对的得心应手，而不是现学现卖。

设计/实现

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

设计工作是在beta开发阶段的开始制定的，由PM组织大家商量，主要依据前一阶段的用户反馈以及助教和专家给出的意见来进行修改和功能上的拓展。总体框架的设计由有开发经验的仇越和对于网络联机功能比较熟悉的李辰洋主要设计，其他人负责补充完成的。由于我们在一开始就设计好了游戏，因此后面不需要重构，开发过程也较为顺利；主要设计者对整体的架构掌握较好，因此他们是合适的设计人选。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？

在设计的时候我们积极撰写开发文档，对于功能的要求和预期情况都说明的较为清楚，在分工后会及时进行沟通和交流，明确需求和具体的设计内容，因此没有碰到模棱两可的情况。我们团队解决这类问题的最好办法就是把沟通和修改放在开发前面，强调并保证了沟通的有效性，从而避免这种情况出现。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

我们使用了单元测试。单元测试主要针对的是后端的逻辑部分，对于前端的UI界面展示以及调用第三方接口、插件实现部分的测试主要通过操作界面、验证功能是否正确来完成。我们还使用了UML来帮助我们进行设计和开发，它对于我们后续的开发具有重要作用。UML图很好的展示了整体项目的架构，帮助大家理解其他人的工作，找准自己在项目中的定位。此外，UML图很好的帮助我们理清了整体的思路，明白各项工作的前后顺序，使工作有条不紊的进行。项目开始时的UML文档只有项目总体架构，没有过多的设计具体的细节。现在的UML文档中包含了各个部分的UML文档，在初始UML的基础上补充和完善了大量的细节。这实际上是开发过程中一个必然的现象，UML图会随着功能完善而更加完备。我们的UML图在团队内部的石墨文档上有共享，每次会议讨论过后都会更新UML文档。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

在数据同步和交互上产生的Bug最多，因为这部分涉及到的因素较多，包括双方网络状况、进程调度、服务器压力等等，这也对于异常捕获和处理机制有较高的要求。在发布以后，发现有些用户在强制退出时数据同步会有异常。这一类问题属于不可控问题，当用户强制退出时我们无法知道手机操作系统是对进程进行挂起还是强制终止，不知道网络连接会不会受到影响，这是由于在测试和开发时无法全面考虑到所有可能的异常情况所导致的。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

代码复审是由负责同一模块功能的同学交叉审查来完成的。我们在审查过程中，首先查看代码的注释是否规范，函数依赖关系、调用关系是否清晰，整体功能和逻辑是否与预期相符；然后，再深入审查，逐行检查代码中是否有未考虑的情况，有没有未初始化的变量。总体而言，我们较好地执行了代码规范，组内同学对其他人的代码较为满意。
我们学到了什么？如果历史重来一遍，我们会做什么改进？

首先，我们学习到了沟通和交流的重要性，在任务开始之前尽早沟通，明确任务和责任的划分，对提高我们的代码开发效率、避免反复重构具有重要意义。然后，我们学习到了代码规范的重要性，多加注释、进行代码复审有助于我们在开发过程中尽早发现代码中的问题，缩短debug时间。如果能够重来一遍，我们会在一开始制定任务时更加合理的分配工作量和工作情况，尽可能减少组内有人完成了任务而无事可做、另一些同学由于任务量较大而无法完成对接的情况。此外，我们还会更加重视异常的捕获和处理，花更多时间搜集和调研用户反馈意见，更好地完善我们的软件。

测试/发布

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

团队中负责每个模块的成员在编写代码事前就制定了测试计划，测试计划的制定主要是依据模块目标和验收标准来制定的。团队测试计划见Ghost Tactics测试报告，测试计划中包括对后端Django部分的CI，以及前端Unity部分所做的传统测试报告。
是否进行了正式的验收测试？

在小组内部，每个成员的任务都由组内的另一名指定成员来进行验收，验收工作严格按照在开发之前制定的验收标准来进行测试，并且确保了逐条标准通过。
团队是否有测试工具来帮助测试？

Unity中使用NUnit进行单元测试，后端使用Django自带的测试框架与覆盖记录插件Coverage进行自动化测试。

而对于场景测试，平台兼容性测试，只能进行人工手动测试。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

用Unity Test Runner运行性能测试，仅进行测试，由于在各种机型上游戏运行流畅，因此不大需要对性能结果进行分析。

对于服务端的压力测试，由于登录注册API并不是我们产品的主要使用点，即需求量很低，故无需进行压力测试。

为游戏同步运行的服务端为Photon公司提供的服务器，限制了使用连接数，因此压力测试也变得没什么必要了。
在发布的过程中发现了哪些意外问题？

部分ROM厂商对网络模块存在冲突，无法进行联网（ROM厂商原因，我们无法解决，甚至无法定位，问题可能存在于非常底层的地方）。
我们学到了什么？如果历史重来一遍，我们会做什么改进？
- 我们学到了单元测试的重要性，单元测试能够很好地将错误局部化，在进行单元测试的同时本身就是对代码的进一步理解和反思。如果能够重来一遍，我们会邀请组外人员对我们的前端代码进行测试，增加不同型号的手机、不同版本操作系统的测试。
- 平台兼容性测试要尽量寻找更多的真机进行测试，然而，普通开发者团队并不能寻找到十分全面的机型，这时，就需要展开公测，面向大众进行测试，这样在测试的覆盖面上将会更宽更广。
- 就像在答辩中说的，我们的CI/CD存在一些不够合理的地方，会把这方面做的更好。但是我们依旧保证了一定的覆盖率，测试在作用上是有保证的，而且这一部分甚至是可以被替代掉的，过多的去批评这一方面，对其他方面的忽略，让人觉得有失偏颇。

团队的角色，管理，合作

团队的每个角色是如何确定的，是不是人尽其才？

以Alpha阶段的分工和表现为考量基础，对Beta阶段的角色进行确定。例如，QY在Alpha阶段中对游戏对战部分了解很多，因此把Ta作为网络功能搭建的主力军十分合理。
团队成员之间有互相帮助么？

团队的互帮互助常常体现在出现Bug的时候。在发布前夕，游戏突然不能正常运行，虽然当时已经过了十二点，但大家依旧纷纷出来寻找bug，虽然是虚惊一场，但真的感受到各位队友的热心。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？

首先是沟通协商，如果依旧存在争议，则PM进行最后的决定。

成员	感谢信
lcy	我感谢yyh，因为他效率很高，无论是什么任务，都能很早的完成我感谢qy，因为他对网络模块十分上心，在大家准备考试的阶段，他一人完成了较多功能的实现我感谢zzx，因为做事认真可靠，且总能发现项目中的小瑕疵我感谢wcf，因为他的测试报告十分细致全面，为我们项目的可靠上线提供了很多帮助我感谢zsk，因为他的演讲十分成功，让我在答辩中看上去还不错
zsk	我感谢仇越和严宇皓对我的帮助，beta初始阶段向我详细介绍了关于scene与shop的C#实现方式，对我beta阶段快速进入开发有很大帮助。我感谢赵子轩对我的帮助，beta阶段可靠的队友，遇到问题能立刻做出反应，修复bug。
yyh	我感谢zsk，因为某个具体的事情：承担起增加卡牌这一最艰巨的任务我感谢zzx，因为某个具体的事情：撰写了详细的教程并添加进UI中我感谢qy、lcy、wcf，因为某个具体的事情：为对接和测试花费了很多精力
zzx
wcf	我感谢lcy,因为他在调研可以使用的服务器和插件时工作到深夜。我感谢qy，因为他在写传输数据部分的代码时只用了三天就完成了基本框架，为组内其他人提供了遍历。我感谢yyh，因为他在完成自己部分内容的同时做了许多测试工作，我的代码有很大一部分都交给他进行代码复审。我感谢zsk，因为他通过仔细校对和核验完成了冲突分支的合并。我感谢zzx，因为他审核教程部分代码时细致耐心，考虑了许多意外情况，避免了游戏的崩溃。
qy	我感谢lcy对我的帮助，作为小组的队长和项目经理，在网络联机模块给了我很大的帮助，并且承担了所有的管理任务。

总结

你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

目前团队处于CMMI中的Managed Level，在团队的项目开发中，已有了需求管理，项目的计划、监督、控制，产品质量管理的基本项目管理手段和策略，但只有一个初步的过程标准化的概念，如项目源代码管理、文件树结构、代码结构等标准的一个初步规定，但尚未到达下一阶段。
你觉得团队目前处于萌芽/磨合/规范/创造阶段的哪一个阶段?

在这个阶段，团队处于规范阶段，大家对自己的职责都十分清晰，慢慢的有很多规则都在慢慢建立，开发和测试中，大家都能够有条不紊的进行了。
你觉得目前最需要改进的一个方面是什么?

缺乏对规范的规范，在开发中存在有很多口头约定，但这容易遗忘和确定不清，一个清晰无二义且全面的规范文档是团队所需要的。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 以有进取心的人为项目核心，充分支持信任他们。
  
  充分支持团队中的创新声音，对于好的点子，即使多一些工作量，也要去完成。同样，也鼓励每位成员为项目的功能提供更多的好点子。
- 无论团队内外，面对面的交流始终是最有效的沟通方式。
  
  遇到问题，遇到项目进度阶段性变化，遇到需求的调整，以开会面对面商榷的形式进行沟通交流，保证信息的流通和交流的充分。
- 每隔一定时间，团队会在如何才能更有效地工作方面进行反省，然后相应地对自己的行为进行调整。
  
  这也正是开每日例会的最大作用，每次例会中，需要询问每个成员的开发情况，对于延期，需要及时寻找问题的根源并及时纠正，这也是到Beta阶段后我们团队即使在烤漆，效率上也有着一定优势的原因。
正如我们前面提到的，软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
1. 代码管理的质量具体应该如何提高？代码复审和代码规范的质量应该如何提高？
  
  在源代码管理上，我们将继续在Unity前端部分使用我们在Alpha阶段已经十分熟悉的PlasticSCM版本控制软件进行管理，自从有了Plastic，版本管理变得不是那么可怕了，从场景模块的冲突处理，到素材文件的快速PUSH、PULL，都有着它独到的地方。同样，我们在GItlab中也进行着版本控制。
  
  对于代码复审，将继续由团队中同一组的其他组员对待审核人的代码进行复审。
  
  对于代码规范，依旧依照Unity开发手册进行。
2. 整个程序的架构如何具体提高？如何通过重构等方法提高质量，如何衡量质量的提高？
  
  网络对战功能的实现对项目的程序结构属实有着巨大的挑战，在这个方面，应该更好的去寻找各个功能、对象之间的关联性，将琐碎复杂的多个相互重复而又存在不同的类，以一个父类为基础，进行派生，从而具有更好的架构感。
  
  质量的提高在于，代码的可读性，功能的可扩展性，项目的可维护性，这一点上，应是未来我们的项目需要去努力的方向。
3. 其它软件工具的应用，应该如何提高？
  
  对于Android IDE的使用，需要更加熟练对多平台模拟器的建立，从而更好的对多平台下的兼容性进行测试。
  
  另外，对Nginx等服务器部署软件的使用，也需要进行加强。
4. 项目管理有哪些具体的提高？
  
  规范项目文件命名，依据不同功能进行归类和排布。
  
  规范git commit，和Alpha相比无意义commit msg的情况出现较少。
5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
  
  目前我们通过记录用户登陆时间和次数进行用户数据跟踪，并且，我们通过Photon记录的用户房间创建/加入次数，来统计用户在联机游戏中的使用次数。
6. 项目文档的质量如何提高？
  
  项目文档也需要文档复核，将交由PM对描述不清晰、不到位的地方进行追加补充。
7. 对于人的领导和管理，有什么具体可以改进的地方？
  
  由于组内工作的高度相似性和成员空闲时间的不确定性，我们组内的工作存在许多重分配的部分，并不是严格按照上图进行划分进行工作。我们吸取了alpha阶段不同组别任务工作量和难度不对等的教训，采用了自愿选择和组长安排相结合的方式，组长发放问卷收集组员的分工意向，遇到分工冲突在协商后由组长安排；我们权衡了不同组之间和组内不同成员之间工作量和任务难度的差别，并据此在验收阶段的文档写作中进行工作量的调整，尽可能保证组内成员平摊任务负担。
8. 对于软件工程的理论，规律有什么心得体会或不同意见？
  
  在开发中出现没有预料的困难怎么办？抽调人手？但增加人手不一定能够有更好的效率，反而可能因为人的增加产生更加负面的效果。任老师的想法十分新颖，摸着网线去寻找资源，比如我们项目中在使用Photon网络插件中存在困难，那么向该公司寻求帮助，或是挖掘资源，会是一个更好的选择。

posted on 2021-06-26 11:44 HairTeam 阅读(124) 评论(1) 编辑收藏举报