alpha阶段总结

设想和目标

总体目标

实现一个微信小程序，能够使得用户：

1.轻松地通过输入图像的方式产生对联，供朋友圈装x
2.能够在机器生成对联基础上进行修改、机器根据修改输出优化后的对联
3.利用我们的小程序在微信群中斗图、根据上联和输入图像输出下联，从而实现对图和对对联的结合

通过设计这样的一个工具，使得用户的创作变得容易，从而激发大众的文学创造欲、增加我们的访问量以及用户数量

alpha 阶段目标

1.搭建微信小程序初步框架
2.实现 “输入图像、输出对联+图片” 的功能

目标实现情况

实现进度：我们的目标没有按期实现，因为ICP原因拖延了3天。

实现质量：

一、搭建小程序初步框架已经实现，在质量上，有以下问题：

1.后端处理速度过慢，每个用户需要等待30秒左右。当多用户同时发出请求时，会更慢
2.前端界面在安卓手机上新出现了显示bug

这些问题确实在影响我们在用户中的受欢迎程度：在我们的一些测试用户中，很多因为处理速度不够快导致不想使用我们的产品。

二、“输入图像、输出对联+图片” 的功能也已经实现，在质量上，有以下问题：

1.处理速度较慢，间接造成后端处理速度缓慢
2.学习存在过拟合、从tag到上联的query结果在搜索空间上聚堆，增加了生成对联的单一性。

上述问题只有在使用次数很多的用户中出现，但是从长远来看不利于我们的产品。

计划

我们留有充足的时间进行计划：首先，在最初，PM提出一个大体的分工，根据讨论结果标注大体的时间分配与人员分配，在冲刺开始之前，要求每个成员对自己的那部分分工细化分块，标注详细时间。

在项目进行当中，会发现临时的突发问题，如有同学有考试、需要回学校体测等问题，一方面相关人员能够自觉提前完成缺席部分的计划，另一方面，对其余人员的计划进行及时调整，两方面的解决方案保证项目顺利进行

在决定临时调整计划时，大多数时间能够达成共识，只有中途一次一位组员认为计划没有必要，但是由于其他人都赞成该计划，投票决定执行该计划。

原计划在预定期限内剩余少量未做完，超出预定期限3天完成，原因是对于微信小程序的了解、调研不够，不知道ICP备案等问题会造成拖期风险，也没有相应的预案。

在计划任务的定义方面，最初的定义有4项是笼统的，这是因为没做到那里，无法细化。但是每次开会推进细化任务时，都是明确的，有清晰的输入输出要求。

在计划中留有1天的缓冲时间，但是发现仍然造成项目拖期，原因是由相当多的问题在计划结束之前一天才暴露出来而且主要是由于对那些不是我们写的API的了解较少导致。这表明，在整合代码时，如果存在依赖外部协议的情况，必须提早对这些外部协议进行简易的“整合试验”，而且应该在这部分计划时间过去一半之前进行。

另外一点属于PM的疏漏：在最初计划时只是确定了各部分接口的格式，但没有确定统一使用哪个版本的python，导致在最后3天出现整合上的python3编码突发问题。这是因为PM最开始低估了python2、python3的链接难度。

资源

资源的估计：所需时间资源的估计依赖于初期各个组员在其领域的调研，事实证明各位组员都稍微高估了所需时间。但是后来的突发问题仍然导致拖期。

alpha阶段欠缺的是对测试时间的估计与安排。没有专门的测试人员，所有组员都是自己写自己那部分的测试代码。在美工方面，我们安排了一定的时间，但是并不是特别多，实际用时也与计划基本一致。因为我们组没有专门的美工人员，上限有限。

在人力资源方面，大家都是挑自己最擅长的那一部分去做，像Tao, He本来就有做前端的经历，自然做前端很顺利、Dacheng, Weijie在后端架构上有经验，因此负责后端。Yichong平时就训练NMT模型，安排他做模型设计和训练最合适。Xiaoqiang和Kai没有相关的经验，但是上手很快，能够迅速完成相应的任务。整个项目中不存在有人在做的事别人做反而更快的情况。

变更管理

由于每次会议都会讨论出下一步的打算，并投票通过，所以任务变更能够通过会议传达到每个组员。平时遇到的问题可以通过微信群讨论。

每次会议会根据共识决定任务的紧张程度，进而变更任务。

在项目执行过程中，存在任务变更，详见第六天冲刺博客，Xiaoqiang对变更的任务应对非常迅速，按时完成。

设计/实现

总体设计主要由PM完成，包括前端纸上模型设计、后端资源申请、数据库结构设计、生成效果图设计、模型选择等。设计工作在实现之前，所有设计工作在冲刺前5天内完成。

在前端设计过程中，Tao, He, Kai参与设计，在后端资源申请、数据库结构设计、生成效果图设计过程中，PM 与Weijie 共同设计，类似结对编程。模型主要由Yichong训练，由PM和Yichong 讨论决定使用哪个模型。

最初的设计或多或少存在模棱两可的情况，在第二次讨论时彻底细化。

团队在实现过程中都是自己测试自己那部分代码，关键部分由PM监督测试。

bug最多的地方在于前后端交互的部分，这是因为我们对于微信编程的不了解导致。

在代码复审方面，前后端都有超过一个人，在完成任务过程中都是类似结对编程，边写边审、互相复审。Yichong和Xiaoqiang两个部分没有复审。

测试/发布

在alpha阶段，各组员只进行了以减少bug为目的的测试，没有进行效能分析。这是需要beta版本的准备阶段着重要做的。

在发布的过程中遇到大量意外，包括使用用户权限问题、域名备案、https的证书问题，这导致本来应该提前一天完成的计划拖期了3天。

各成员评分：

根据各个成员对alpha阶段的贡献程度投票，得到下面排名及分数

序号	成员	评分
1	Tao	115
2	Dacheng	110
3	Weijie	105
4	Yichong	100
5	Xiaoqiang	95
6	He	90
7	Kai	85

经开会决定，在Beta阶段，Kai将离开我们，我们组员都很不舍得，因为我们的组里本来就没有划水的人，都是有实际贡献的，大家都是不可替代的！

会议照片