AiApe问答机器人Alpha阶段事后分析
Alpha阶段事后总结
总体
项目开发速度看似远超出预期，但实际并不。并不是说issues没有按时完成，而是缺少了应用测试的一步。可以理解为：骨架都有了，但血和肉太少。这一点是我作为PM有所失职的地方，我并没有正确的估计任务量，或是正确的安排issue。
也正是因为前期专注于搭建骨架，我们低估了添加血和肉的成本。这一点集中体现于“引入真实知识问答数据库”后，各类文本渲染的问题。同样，作为PM我应该对此负主要责任，团队成员之间的交流沟通太少，这一点需要在Beta阶段加强。PM也需要在Beta阶段开始前，对项目做更加具体的规划。
前端作为用户体验的最重要保障，在Alpha阶段的工作并不让人满意。主要原因在于，我们并没有在设计阶段对前端进行完整地、细节地设计，而只是想象了一个大体的框架。这导致，前端似乎可以很快完成框架，但是用户体验并不好。我们在Beta阶段会重视这一点。
设想和目标
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
对于后端，原先的问答流程设计是用户先问问题，然后我们尝试为他解决，并进行相关引导。但在实现的过程中由于初期后端需要完成较多其他工作，导致这一部分核心功能所分到的时间就比较有限，在比较有限的时间下，对于初期设想的流程，很多地方就没精力实现，导致最后完成的问答是基于设计好的给定流程进行的，这就导致了问题范围的缩小以及用户体验上的不佳。
利用NLP模型进行对话的功能本来是最重要的功能，但是却被放进了“缓冲区”里，作为有余力再进行的任务，而先实现了详尽的其余功能，如精确的数据层报错、完整分层次的日志记录、数据层的高并发控制等等。这样安排任务顺序的时候，考虑的是这一部分功能是前端展示资料所必须的数据源，尽早实现有助于前端进行开发，但目前看来并没有达到这样的效果，但却导致了Alpha阶段的产品特色不足，用户体验很糟糕；
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
这一点其实和上一点相关，由于功能实现的差异，所以用户较低的接受程度也是有所预期的。尽管核心的功能实现上确实有点遗憾，但就目前的状态来说，后端的其他功能已经实现的差不多了，在之后的过程中我们可以更关注于核心功能的实现。所以总体上还是更接近目标了。
计划
团队在计划阶段是如何解决同事们对于计划的不同意见的？
大部分
就后端来说，由于两个人平时住的比较近，所以在设计上如果有任何问题都第一时间进行商量讨论出一个两个人都能接受的结果。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
如果只是看初期规划的issue，后端同学大致完成了自己分配到的任务。当然，现在看来这个规划对于机器人问答这一核心功能涉及的很少，这就导致了目前其功能还需在整体上做较大的改进。
是否每一项任务都有清楚定义和衡量的交付件?
由于在初期就对整体项目框架有所设计，所以每一项任务基本对应到了要实现的某一个功能，也就对应到了框架中要实现的某一代码部分。
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
虽然看起来整个项目都在按着计划进行，但从最后的结果也可以看出，得到的效果并不是特别好，所以必然是其中出现了一些问题。
就后端来说，我认为大致有以下几点：
- alpha阶段受后端精力有限、任务较多的影响，再加上我们对任务的重要性估计有误，导致了真正关键的功能没有得到很完善的实现。
- 后端与前端的交流不够充分。一开始我们是认为只要前后端对接的接口实现好了，就可以各自干各自的活，但就目前的情况来说，前端实现的内容与设想有所出入，说明确实需要更深入的进行交流。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
关于用户反馈，我们得到的大多数信息与用户体验有关。团队将在Beta阶段着眼于UI设计和用户体验上，这一部分的重心将在前端。而对于后端，我们将完善问答社区的功能，提升整体产品功能丰富度和用户体验。将NLP技术引入到问答机器人中，可以让问答机器人更加高效而准确的查找信息，从而反馈更为精确的回答。
资源
我们有足够的资源来完成各项任务么?
就后端的普通功能，我们实现起来确实没什么困难。但对于关键的机器人问答部分，要达到预期的效果的困难程度要比之前想的大的多。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
目前来看，在给定的时间内要完成完善的开发与测试确实有点困难了。甚至在后期我们还在纠结于完成测试，现在想来这部分时间不如投入到开发机器人相关的功能上（就我个人来说）。
做的还行的地方
- 后端在初期就做了比较详细的规划，所以整个开发过程基本上就是按照初期的规划进行的，即使在开发的过程中遇到了一些困难也基本上能按照进度完成任务。对于Beta阶段，仍然希望能够在事先做好详细规划的情况下，按照规划来完成任务。
- 后端的沟通交流也比较频繁。由于后端是两个人共同进行开发，即使每个人都分配到了不同任务，但在任务中也有大量对接，所以经常需要进行沟通交流。经常沟通交流带来的好处就是每个人都对整个后端目前的情况都有所了解，能为不断的开发打好基础，弄清方向。
需要改进的地方
- 从目前的结果来看，后端需要调整的地方就是开发的重点，即我们需要专注于机器人问答部分的实现。但这个转变其实是注定的，因为alpha阶段被后端其他功能所拖累，导致在这个功能上的花费的精力就比较小，而经过alpha阶段，我们已经把其他大部分功能都实现完了，所以在beta阶段可以专注于机器人功能的完善。
- 与前端人员的沟通。在alpha阶段，虽然与前端人员保持了一定程度上的沟通，但基本局限于接口上的对接，导致我们实际上对于前端的进度并不是特别了解。希望能在beta阶段多进行些沟通，推动前端的效果能够得到完善。
- 开发顺序上，这次选择了先开发上层模块，同时确定下层模块的接口，然后在根据接口开发下层模块，即先完成调用者和被调用者的接口，然后完成被调用者的实现。这样导致了一个问题：在实现被调用者的之前，往往无法考虑完全被调用者可能需要抛出怎样的异常，而实现被调用者的时候，才发现有些状态下无法完成任务，必须通过异常或其它方式来通知上层，尤其是涉及数据库的时候，这种情况尤甚。但是由上至下的开发顺序也带来了一定好处：由于先确定了调用方如何使用这些函数，先确定了这些函数的行为，再进行实现时，一方面不会做无用功，实现一些不会被使用到的功能，一方面也减少了后续再增加接口的情况。因此，我任务由上至下的开发顺序值得保留，但是开发被调用者的时候，如果新添了可能抛出的异常，应当记录下来，以便筛查，而不是直接修改接口类；
- 单元测试方面，由于测试需要学习创建Mock对象的
Moq库，由于以前并没有接触过mock的概念，而且对于涉及到Web的测试并不熟悉，所以并没有随着开发进行单元测试，导致开发基本完成的时候，很多WebAPI前端无法正常调用； - 集成测试，由于单元测试有一些局限性，比如单元测试使用的
SQLite.InMemory数据库，无法再插入时自动更新创建时间和修改时间，比如某些配置服务器的代码无法进行单元测试，某些工作于响应的pipline的中间件无法进行单元测试； - 关于WebAPI的文档，为了方便查看其改动，而将其放在单独的分支来进行，Alpha阶段评审会议的时候，看到其他组通过Wiki功能来方便查看WebAPI文档，我认为是一种值得尝试的方式；
