【HelloKitty团队项目】Alpha阶段事后分析( 二 ) _测试

我们会保持在本阶段中对缓冲区的定义与使用。另外，在如果发现某个方案在讨论时有较多不确定因素，也要做好缓冲准备，可以多准备一份方案以防万一。我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们学到了在会议讨论中定期对任务进行分工和规划。如果重来一遍，我们会在制定计划前增加一些调研，比如计划完成某个功能所需用到的各项技术与可能出现的问题，以此来更精准的评估一项任务的复杂程度，进行更加合理的分工。资源
我们有足够的资源来完成各项任务么?
我们使用了腾讯云的美国硅谷服务器来实现调用的服务，确保完成了项目的核心功能设计。感谢@ 提供的Plus账号 :）
各项任务所需的时间和其他资源是如何估计的，精度如何?

文章插图
我们在alpha阶段设计时对整体任务的人员分配与时间分配进行了预估，具体开发时我们每两天召开一次例会，在例会上总结这两天的开发进度并动态调整任务分配，决定后两天的具体开发任务。实践时按两天的粒度分配与调整任务较为精准，大部分情况都能按时甚至提前完成例会上安排的任务。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
我们前后花费了4天的时间进行测试，采用前端同学进行场景测试与兼容性测试，后端同学进行单元测试和压力测试的形式进行测试，测试较为充分，人力和软件/硬件资源足够。
美工设计和宣发工作由@吕元秋完成，为我们的项目在美工方面行了风格统一，吸引了大量用户并建立测试群，总的来说较为顺利，没有低估难度。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
alpha阶段设计时初步设计的任务分配与实际开发还是有一定的差别，有些部分设计的不够具体，会导致任务分配预估不准、不够均匀等情况。如果再来一遍我们会进行更充分的任务分配设计，减少例会上重新分配任务的情况。
变更管理
每个相关的员工都及时知道了变更的消息?
是的，我们采用文档、微信群通知与例会讨论的形式通知变更的消息，根据变更的涉及范围和具体情况选用不同的通知方式，能够使每个相关的员工及时收到变更的消息。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们会根据alpha阶段的功能设计、功能的重要性与其他功能的关联性、具体实现的技术难度来决定“推迟”和“必须实现”的功能。如果这个功能实现较为复杂，但又不是我们的核心功能与创新功能，我们会根据开发进度酌情选择“推迟”该功能的开发。如果该功能是我们的核心功能与创新功能或者与其他功能的联动性较强，我们就会决定其为“必须实现”的功能。
项目的出口条件（Exit– 什么叫“做好了”）有清晰的定义么?
有，我们要求项目的功能性、兼容性与安全性达到我们的测试标准才算达到项目的出口条件。详情请见【-】Alpha 阶段测试报告
对于可能的变更是否能制定应急计划?
是的，因为在具体开发中我们对开发工作采用了解耦的方式，每个人负责的功能部分相对独立，在面对变更时我们会让对应的成员进行负责，如果涉及较为复杂的前后端对接，则会让对接的同学面对面进行沟通调整，能较好的制定应急计划。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
团队成员保持沟通很重要，能及时沟通能够加快整体的开发。如果重来一遍，在涉及复杂功能开发与变更时我们会让负责的同学直接面对面进行交流与调整，这样能进一步提高开发效率，及时解决问题。