HairTeam Alpha阶段事后分析

设想和目标

我们的软件要解决什么问题？是否定义得很清楚？

我们开发的软件为一款3D手机游戏，旨在与市场上已有的“自走棋”类型的游戏竞争，一来利用移动端优势凸显手游的轻量化，使得用户可利用碎片化时间游玩，二来通过游戏内的局域/广域网联机功能使用户可以享受到快速方便的社交功能。但相比于其他团队，上述中玩家的痛点并不明显或重要，软件整体相比于同类游戏竞力有限。
是否对典型用户和典型场景有清晰的描述？

对于用户分析，我们在分析阶段列举出了四种典型的玩家群体，分别为大、中、小学生与专职游戏主播。典型用户的构造有以下问题：1.用户特点中主要考虑的是用户的游戏时间/支付能力，而用户对“自走棋”的游戏机制与策略游戏的可接受度，是分析时有所忽略的 2. 四种用户群体交集过小，典型用户跨度大而单类用户描述不够详尽，以致参考价值有限。在发布阶段中，团队推广时面向的群体也基本是校内大学生群体，无法说明其他典型用户的潜在比例。
原计划的功能做到了几个？按照原计划交付时间交付了么？

在原计划中，游戏整体将具有以下功能：游戏对局内战斗，卡牌管理，难度等参数设置，局域网联机，特殊卡牌等功能，而α阶段中的目标与实际完成的为前三者。交付按时完成，但形式上有变化，原计划5月5日在华为应用商城，Taptap等平台上线游戏，由于一切中国大陆游戏必须进行获得游戏版本号，平台不允许软件上架，故团队制作了网页的发布平台与反馈博客。
原计划达到的用户数量达到了么? 用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了么？

目标用户数量为："α阶段软件发布一周后软件下载量大约在100人左右，活跃用户量预计只有20-50人"（NABCD分析），实际中截至5月14日前，游戏服务端统计到软件累计注册人数为82人次，下载量估计大于等于注册人数。而活跃用户量（即在首次游玩后又在5天内重新登录的用户）达到了43人次，原计划中的用户数量已基本达到。根据用户反馈，主要意见为“游戏内容过少”，一方面α阶段无联机功能，游戏性有一定折扣；另一方面α阶段中游戏元素较单一，仅有召唤物卡牌，场景仅5张地图。

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

在有限时间内作更加充分的调研，开发前收集更多的用户需求反馈，合理评估项目/软件的价值。
更理性评估开发技术栈，α阶段中大部分成员是跨自身技术栈开发，如果历史重来一遍，团队将从项目质量保证与开发工作量两方面权衡技术选型。
突出差异化功能，α阶段没有准确定位软件及其核心差异化功能，导致开发工作缺少重心，较竞品软件特点不突出。

计划

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

事实上，我们做计划的时间是比较紧的，没有特别充裕的时间来做计划。

首先在选题阶段，由于我没需要在3天时间，就完成选题，完成基本需求分析，以及拍摄项目介绍视频，在这个阶段我们没有考虑项目计划；

然后是进一步需求分析形成技术规格说明书和团队贡献分分配原则，虽然给了一周的时间，但完成这个作业我们查找了许多资料，参考了许多的往届博客，开展了讨论，进行了调研；这个阶段我们也没有太多时间做计划。

好在我们英明的PM-lcy同学，考虑到了我们alpha阶段的计划部署，为我们拟定了初步的计划，并根据意愿优先原则做了初步的分工，到了我们alpha阶段的第一次meeting，我们已经形成了初步的计划框架，经过了1h左右的进一步讨论，我们敲定了alpha阶段项目的计划，包括在什么平台进行开发，到测试阶段前的任务分解和分配，软件后续发布和推广的基本拟定，还找到了我们项目的模型素材和基本框架。
团队在计划阶段是如何解决同事们对于计划的不同意见的？

我们在敲定计划的阶段比较顺畅，基本没有什么分歧，若有不同意见，我们会采用如下流程：
- 意见双方各自发表自己的观点；
- 其他成员各自发表自己的观点；
- 若还不能解决分歧，则组内进行投票表决，或是由PM裁定。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

我们计划的工作基本做完了，但是由于交接工作的不到位，部分任务存在delay现象。
有没有发现你做了一些事后看来没必要或没多大价值的事?

在使用Unity内置的Plastic SCM进行版本控制后，还要用git进行重复的操作，而且不如Plastic直观便捷，没有实际意义。
是否每一项任务都有清楚定义和衡量的交付件?

对于前期我们计划中的分工任务，我们都有定义和一定的交付标准；

对于后期我们根据实际情况改变和增加的任务，我们没有明确在书面上做出定义和交付标准，因为时间确实比较紧急。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

整个项目基本按计划进行，但是在我们测试和发布阶段，发现由于交接工作的不到位，音乐组件出现一些问题，这造成了一定的加班和延误。

同时这也是我们没有考虑到的风险，因为当时已经在测试的末期，产品即将发布，若出现临时问题导致发布需要延迟，一定程度上影响用户反馈和意见收集，以及我们后续阶段的工作部署。
在计划中有没有留下缓冲区，缓冲区有作用么?

计划中留下了一些缓冲区，在测试阶段若还有工作没有完成，可以先忽略这一部分。

缓冲区作用似乎并不大，因为我们最后发现出现问题的时候，已经是测试阶段的末期了。
将来的计划会做什么修改？

总的来说，alpha阶段我们的开发基本顺利，出现的一些问题是由于交接工作的不到位造成的；在beta阶段我们会加强交流工作，不仅是任务小组内的交流，还有任务小组间的交流。

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

在alpha阶段，我们进行了团队合作和软件开发的体验，我们学会了软件项目，不仅仅是电脑前敲代码，还有团队交流，相互帮助解决困难，还有产品的发布和推广，收集用户意见进行改进，以及总结和展示成果。
如果历史再来一遍，我们会加强交流工作，任务小组内部先交接好，保证各模块没有问题，再和其他任务小组的模块进行交接。

资源

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

只要肯找，资源总是有的。从结果来看，确实有足够的资源来完成各项任务。
各项任务所需的时间和其他资源是如何估计的，精度如何?

基于难度与现有开发经验进行估计。对于技术学习、游戏逻辑、布局框架等方面的估计还是比较准确的，但细节方面(如UI的调整等)则低估了需要的时间。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

测试的时间和人力基本足够，但硬件资源不能说足够。主要原因为安卓机型五花八门，不同机型可能有着很大的区别，想要测试完全几乎不可能。
你有没有感到你做的事情可以让别人来做（更有效率）?

大家基本没有这种想法。由于大家基本都没有接触过unity，每个人的学习路线基本都被任务分配给特化了，因此不存在这种情况。

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

团队成员之间的沟通是非常重要的，发现问题要及早提出；另外，测试也非常重要。如果重来的话，我们会预留更多的时间来进行测试。

变更管理

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

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

首先根据Alpha阶段指定的的功能规格说明书中所明确的必须实现的“主干功能”，如“游戏对战demo”，“对战逻辑”，“登录注册模块”，“卡牌管理模块”，是无论如何都要在Alpha阶段完成的，并且需要进行多次迭代，PM则根据例会中各组的进展汇报来进行下阶段迭代中“必须实现的功能”相关工作的部署。

而对于“非主干功能”，如“音乐音效设置”，“UI细节设计”等，则由PM根据工作燃尽图与各组队员目前的主干任务完成情况来进行斡旋抉择，即是否“推迟”。
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

采用ISO/IEC 25010:2011国际软件工程产品质量标准来对Alpha阶段的软件项目是否满足出口条件进行评估，评判指标主要分为功能适用性、性能效率、兼容性、易用性、可靠性、安全性、可维护性、便携性八个方面进行评估，具体参见Alpha阶段总结 - 软件质量评估模块
对于可能的变更是否能制定应急计划?

能，对于可能的变更制定应急计划的能力依赖于不同小组间交流协作能力，与PM的统筹安排能力。
员工是否能够有效地处理意料之外的工作请求？

我们在需求分析与任务划分初期将整个项目分为：前后端链接、UI设计、对战demo设计三大板块，每个板块由不同组的同学负责，并且由于在Alpha阶段启动初期，所有同学花费了一周的时间对自己负责板块的基础、拓展知识与技术栈进行了全方位的学习，因此当遇到意料之外的工作请求时，每个同学都能有效地对其进行处理。

设计/实现

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

计工作是在alpha开发阶段的开始制定的，由PM组织大家商量、由有玩过多种游戏经验的严宇皓和对于功能相似的游戏比较熟悉的李辰洋主要设计，其他人负责补充完成的。由于我们在一开始就设计好了游戏，因此后面不需要重构，开发过程也较为顺利；主要设计者对整体的架构掌握较好，因此他们是合适的设计人选。
设计工作有没有碰到模棱两可的情况，团队是如何解决的？

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

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

在用户登录界面产生的Bug最多，因为这部分涉及到的逻辑较多，包括前后端交互、界面跳转逻辑等。在发布以后，由于我们的密码是以明文传输的，因此会被截获，造成用户的信息泄露。由于一开始设想是单机游戏，并没有考虑登录，是课程要求统计访问量以后才新加的，测试不够严密，开发比较匆忙导致了这种情况的发生。
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

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

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

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

测试/发布

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

团队测试计划见Ghost Tactics测试报告
是否进行了正式的验收测试？

在发布前进行系统的验收测试。
团队是否有测试工具来帮助测试？

Unity中使用NUnit进行单元测试，后端使用Django自带的测试框架进行自动化测试。

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

用Unity Test Runner运行性能测试，仅进行测试，由于在各种机型上游戏运行流畅，因此不大需要对性能结果进行分析。
在发布的过程中发现了哪些意外问题？

发布中apk包名错误，icon缺失，且在一款特定机型上出现花屏，可能原因是该机型显示驱动不兼容的问题，该问题更多的应由ROM厂商负责。

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

平台兼容性测试要尽量寻找更多的真机进行测试，然而，普通开发者团队并不能寻找到十分全面的机型，这时，就需要展开公测，面向大众进行测试，这样在测试的覆盖面上将会更宽更广。
另外，我们的后端并未进行压力测试，其中原因主要为本阶段对后端的服务访问量不大，然而在下一阶段，需要同在线玩家共同联机游戏，这就可能造成大量的访问量，而压力测试也就必不可少了。

团队的角色，管理，合作

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

在角色分配之前，通过面对面的开会讨论，确定最终的分工情况，首先要满足每个人的最大兴趣，兴趣是最好的老师，而消极情绪一定会带来低效率的工作，让大家每个人选择自己最愿意的分工，正式其中的要义。
团队成员之间有互相帮助么？

团队成员经常性的交流沟通，让问题及早的发现，也让成员间遇到问题能够共同解决，通常，在一个模块的开发有困难时，其他成员都很乐意进行帮助。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？

最好的办法就是沟通，并且，最重要的是，平等，不要因为这个部分你懂而他不懂，就趾高气昂，大家在交流、在开发中，都是平等相处的。

每个成员明确公开地表示对成员帮助的感谢（并且写在各自的博客里）：

成员	感谢信
lcy	我感谢yyh，因为某个具体的事情：在对接卡牌管理时十分的耐心和细致我感谢qy，因为某个具体的事情：在场景设计上，对于我不是那么成熟的建议，保持着肯定的态度我感谢zzx，因为某个具体的事情：在联网开发中，提出了设计中存在的隐患，感受到了他的真知灼见我感谢wcf，因为某个具体的事情：在项目声音效果出现问题时，立马放下自己的事情着手进行解决
zsk	我感激lcy，充分做好了Alpha阶段一个PM该做的事，合理管理、分配了整个团体的任务我感激yyh，同为UI设计小组的队友，他用自己精湛的技术和一丝不苟的工作态度将我折服。我感激qy，在场景与UI对接遇到问题时能及时找到问题所在，是不可或缺的优秀队友。
yyh	我感谢lcy，因为他担任PM，整个团队在其管理下得以有序运行我感谢zsk，因为他与我共同出谋划策、共同开发，完成了UI部分的编写我感谢zzx，因为他承担了答辩的大部分工作，而我只是相应地在旁边提供应援
zzx	我感谢qy，因为他主动担任了场景开发组内的领导者角色，并承担了大部分游戏场景/脚本的开发工作我感谢yyh，因为在α答辩日时我所作准备不足，在提问时无法对一些问题给评委合理的解释，是他及时帮助我完成应答我感谢lcy，因为他是在进行服务端开发时兼任PM，工作量占比最大。同时在α阶段中完整详细制定开发计划，并保证进度的落实
wcf	我感谢lcy，因为他管理能力出色，将整个团队的工作梳理得非常有条理我感谢zsk，因为他勇于担当，出现bug了总是第一个上去修复我感谢zzx，因为他检索素材又快又准，总是能够找到合适的图标和音频我感谢qy，因为他设计的地图精美而巧妙，给予了我开发过程中较大的帮助我感谢yyh，因为他的代码书写规范，接口定义清楚，与他对接时总是十分顺利
qy	我感谢zzx，因为他在转会期间挺身而出，在大家都不愿意冒风险，离开当前上手的项目，去接受一个新的项目和环境的情况下，主动成为我们组转会的人。

总结

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

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

团队现处于磨合阶段之后，且刚刚踏上规范阶段的路途。各个规范的制定尚且没有一个确定的形式，只是为了项目开发中的方便而进行口头约定。
你觉得目前最需要改进的一个方面是什么?

目前团队内部不够活跃，在讨论中大家还是有话不好意思说，需要更多的团队凝聚力。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 尽早并持续的交付有价值的软件以满足客户需求。
  
  在Alpha阶段的开发中，我们致力于尽早完成能够开始基本游戏的场景和demo，并在听取周围同学的意见上，美化卡牌展示UI、增加多个地图场景等功能，以此更好跟进用户的需求。
- 以有进取心的人为项目核心，充分支持信任他们。
  
  充分支持团队中的创新声音，对于好的点子，即使多一些工作量，也要去完成。
- 无论团队内外，面对面的交流始终是最有效的沟通方式。
  
  遇到问题，遇到项目进度阶段性变化，遇到需求的调整，以开会面对面商榷的形式进行沟通交流，保证信息的流通和交流的充分。
正如我们前面提到的，软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
1. 代码管理的质量具体应该如何提高？代码复审和代码规范的质量应该如何提高？
  
  在源代码管理上，我们将继续在Unity前端部分使用PlasticSCM版本控制软件进行管理，他的优势在我们的Alpha阶段已体现的淋漓尽致，从场景模块的冲突处理，到素材文件的快速PUSH、PULL，相较于gitlab有着更高的使用价值。
  
  对于代码复审，将继续由团队中同一组的其他组员对待审核人的代码进行复审。
  
  对于代码规范，依旧依照Unity开发手册进行。
2. 整个程序的架构如何具体提高？如何通过重构等方法提高质量，如何衡量质量的提高？
  
  下一阶段，前端将引入多人战斗模式，这一模式需要将AI和在线玩家进行抽象归类，这一部分需要对程序结构进行微调，以达到更低的耦合性。
  
  对于后端，在基于Django的框架下的开发已经能够保持较好的模块性。
3. 其它软件工具的应用，应该如何提高？
  
  对于Android IDE的使用，需要更加熟练对多平台模拟器的建立，从而更好的对多平台下的兼容性进行测试。
4. 项目管理有哪些具体的提高？
  
  规范项目文件命名，依据不同功能进行归类和排布。
  
  规范git commit，依旧存在无意义commit msg的情况。
5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
  
  目前我们通过记录用户登陆时间和次数进行用户数据跟踪，接下来计划引入用户游戏时长的计算来更好的跟踪用户游戏数据。
6. 项目文档的质量如何提高？
  
  项目文档也需要文档复核，将交由PM对描述不清晰、不到位的地方进行追加补充。
7. 对于人的领导和管理，有什么具体可以改进的地方？
  
  目前实行的团队内小组分工制的管理结构是较为高效且合理的，PM只需要对小组之间进行协调，小组内自行进行分工调整和进度跟进。因此此处暂无需要调整的地方。
8. 对于软件工程的理论，规律有什么心得体会或不同意见？
  
  软件工程不只是算法和程序的结合，软件=程序+软件工程，这个公式在团队开发中发挥着巨大的作用，在多人合作中，做到1+1=2是一件很难的事情，管理正是解决多人合作中诸多低效因素的最佳手段。

posted on 2021-05-22 14:52 HairTeam 阅读(136) 评论(7) 编辑收藏举报