Alpha阶段终于告一段落，我们的团队也完整经历了从提出设想、用户需求分析，到开发、测试，再到部署上线、推广的流程。“葫芦娃不想写代码”团队还是较出色地完成了Alpha阶段的工作，4月25日晚，我们也一起坐在新主楼F座二楼的沙发上，第一次召开了一个超过一个小时的会议。本次会议没有疯狂地提需求和push，大家根据课程组提供的模版，细细回想过去的两周多时间内，有哪些做得好的或不好的地方，选出了我们的super star去完成不得不做的转会任务，也对Beta阶段的工作做了大致的规划。具体会议记录如下：
设想和目标
- 我们预期的功能是否都实现了？按计划交付了么？
由于我们的学习成本较高，开发人员对django和pytorch等内容不是十分熟悉，因此我们在Alpha阶段前期花了较多的时间去学习相关内容，计划只实现核心功能——拖拽搭建模型并返回相应代码。核心功能我们是顺利实现了的，除此之外，我们还实现了网站的访问量、模型生成量统计功能。可以说，Alpha阶段我们顺利按计划交付，还超额完成了任务。
- 原计划的用户数量达到了么？新的目标是什么？
我们的目标是1000的访问量、400的生成模型数，而截至2019.4.26，网站的访问量为1078、生成模型数为398，几乎可以说是达到了目标。
- 有什么经验教训？
在产品设想方面，我们小组的Alpha阶段估计的还是比较准确的，抓住了用户需求所对应的核心功能，在第一个版本提供了可用的产品，而暂时搁置了一些开发优先级没那么高的功能，利用好了团队资源，也希望我们在Beta版本中，继续对功能的优先级进行精确的排序，首先开发优先级较为靠前的功能。
计划
- 是否有充足的时间来做计划？
由于Alpha阶段的初期，开发人员在学习相关知识，同时PM就有了较为充足的时间来做计划。而Beta阶段的计划，在Alpha阶段后期我们团队的两位PM就开始进行相关规划，因此Beta阶段的计划设计时间也较为充足。
- 源计划的工作是否最后都做完了？
如上文所说，我们对Alpha阶段估计较为准确，因此所有计划中的工作均完成了。
- 有没有发现做了一些事后看起来没必要或没多大价值的事？
我们询问了开发与测试人员，大家均觉着所做的工作是必要的，并未浪费精力。
- 是否项目的整个过程都是按照计划进行，项目出了什么意外？
在Alpha阶段的初期，前端开发与后端开发沟通出现了些不顺畅，前端不清楚后端的具体接口，导致无法推进。我们在当天召开紧急会议，明确了所有的接口，并约定如出现调整，及时做好沟通，也保证了项目的顺利推进。
- 在计划中有没有留下缓冲区，缓冲区有什么作用？
不得不承认我们在Alpha阶段确实没有留机动时间和资源，万幸的是一切都按部就班的进行，才保证项目的顺利完成。在下一阶段，我们会考虑这个问题，留下机动的时间，以免有突发情况导致满盘皆输。
- 如果历史重来一遍，我们会做什么改进？
前端如是说道：如果历史重来一遍，会对模型进行某些处理，然后将各个部件之间的关系存在数据库中，然后生成代码的时候通过关系返回代码，而不是硬编码，直接将生成的代码存在数据库中。
资源
- 我们有足够的资源来完成各项任务么？
由于我们在有7位组员，因此人力上是比较充足的。而华为云又为我们提供了部署网站的服务器，因此物力上也是比较充足的。
- 各项任务所需的时间和其他资源是如何估计的，精度如何？
各项任务所需时间和各项资源确实就是团队成员在最开始计划的时候，大家一起商讨确定的，并没有什么可靠科学的方法，而这些我们也在项目开发推进的过程中实时调整。
- 测试的时间、人力和软硬件资源是否足够？美术设计和文案等难度是否低估？
是足够的，但各项文档的难度着实......超乎我们两位PM的想象......确实低估了这一部分的工作量。
- 有没有感到自己做的事情可以让别人来做更有效率？
询问了各位成员，大家均觉着自己较适合自己的工作，安排还是较为合理的。
变更管理
- 每位相关的员工是否都及时知道了变更的消息？
我们平时的研究、商讨会采用开会或在微信上交流的形式，比较重大的决定或变动，会在github上发布issue，因此如果有变化大家都可以及时知道。
- 我们采用什么方法来决定“推迟”和“必须实现”的功能？
对要实现的功能做优先级排序，在Alpha阶段仅实现核心功能，在Beta和Gamma阶段会陆续完善其他的功能。
- 项目的出口条件（Exit Criteria）有清晰的定义么？
Alpha阶段的出口条件就是可以返回正确的、能够运行的模型代码。
- 组员是否能够有效地处理意料之外的工作请求？
对于突发情况，我们小组成员都是比较积极的，谁手头没有很急的任务，且能够解决突发情况，就会主动承担下。
设计/实现
- 设计工作在什么时候，由谁来完成的？
设计工作是在Alpha阶段初期，团队成员开会共同讨论完成的。
- 团队是否运用单元测试、测试驱动开发，或者其他工具来帮助开发？
在项目初期，我们画了了原型图，来更好地帮助前端设计。但在后面开发的过程中，确实没有做单元测试，主要问题出在Alpha阶段没有明确好这部分工作的归属上，开发以为这部分由测试来完成，但测试对代码不了解又没法进行。在Beta阶段，我们明确了由开发进行单元测试，测试人员进行综合测试，不会再出现类似的错误。
- 什么功能产生的Bug最多，为什么？
- 前端：放在画布内的组件进行拖拽时，popover弹出框会出现各种各样的问题，比如无法跟着一起拖动，甚至出现错误，主要原因是框架不支持跟着一起拖动。后来我们机智的开发人员，想出了一个解决办法，就是在鼠标进行拖动的时候，就会触发弹出框隐藏，从而达到跟随移动的效果。
- 后端：没什么大的问题，开发还比较顺利。
- 代码复审是如何进行的？是否严格执行了代码规范？
代码复审并不是十分严格，下一阶段会考虑增加相应的制度，进一步保证工程的质量。
测试/发布
- 团队是否有一个测试计划？
有关单元测试确实没有相应的计划，原因如上文，下一版本我们会改正这一点。综合测试的计划还是有的。
- 是否进行了正式的验收测试？
由测试人员完成了正式的验收测试。
- 有哪些测试工具来帮助测试？
pycharm、postman、fiddler
总结
- 代码管理的质量具体如何提高？代码复审和和代码规范的质量应该如何提高？
- Beta阶段要把代码的管理碎片化，我们组的开发人员习惯完成一大块功能统一进行commit，但这样并不利于开发，下一阶段我们会统一要求开发人员在每天进行工作后，哪怕是很小的一个功能，也要进行commit。
- 同时我们会严格按照代码规范执行，因为已经撰写了相应的文档，我们会按照文档进行代码规范的管理。
- 整个程序的架构如何具体提高？如何通过重构等方法提高质量？
我们组认为通过重构的方法来提高工程质量，是一种不得已而为之的方式，耗时耗力，还会大幅度地延缓项目进度。局部的重构是可以接受的，但项目整体的框架，是一开始就设计好的。
- 其它软件工具的应用，应该如何提高？
我们组目前开发在使用：pycharm、sublime和postman，测试在使用：pycharm、postman、fiddler，这些工具都足以支持我们开发。在下一阶段，如果时间充裕的话，我们还会对前端进行美化，可能还会用到其他工具。
- 项目管理有哪些具体的提高？
之前我们发布的issue还不够十分具体，有些issue工作量较大，在下一阶段，我们会将任务拆解为工作量小一些的小任务，也便于PM及时掌握开发进度。
- 项目跟踪用户数据方面，计划要提高什么地方？例如如何知道每日活跃用户等。
目前我们是在一个统计页面展示每天的访问量，但我们认为这样不是十分美观，我们打算在Beta阶段将其改为折线图的形式。
- 项目文档的质量如何提高？
我们认为在现有的基础上，要更加详细地撰写文档，我们一起学习了红太阳团队的文档，找到了自己不足之处，也会在未来一点点改正。
- 对于软件工程有什么心得体会或不同意见？
- 大娃：首先alpha版本已经结束了，心里也是松了一口气。整个阶段完成下来，也算是收获满满，印象最深的还是懂得了时间调控以及设计规划的重要性。我参与的是后端开发，大概就是对前端返回的数组进行特定的操作然后返回。其实这是一个很简答的事情，如果只是为了完成功能的话可能只需要一两百行代码就能解决，但是考虑可扩展性、可读性以及软工所要求的代码规范的要求，这就变成了一个很复杂的工作。我和另一个后端开发的小伙伴计算了一下，我们花在设计和思考上的时间大概占了70%，真正完成代码这个过程相对不是很耗时间。这是一个很重要的收获。
- 二娃：经过一段时间小组成员们的努力，终于让ALPHA版本的Visual Pytorch上线了。虽然这个版本还有一些缺陷，但是核心功能基本上是完美地实现了。在整个开发的过程中，我们深刻意识到了团队协作和例会的重要性。在开发网站的过程中，前后端的交互是极其重要的一部分，每次例会的召开都可以让我们的主PM很好的把握前后端的进度以及遇到的问题，我们会一起商量出具体的解决方案。虽然我们小组成员都是第一次合作，但是效果比预计的要好。相信我们在后续版本的开发中，会继续努力取得更好的成果。
- 三娃：软件工程这门课程让我第一次对自己感兴趣了很久的一个工作：PM，有了初步的了解。不出意外，确实与自己想象中有一些差距，或者说，自己想象得到的只是PM的一部分工作。PM不仅限于策划、提需求，还要对项目有整体的把握，要对项目进度有足够的了解，同时还要在前后端之间、开发与测试之间起到沟通和协调的工作。可以说，软件工程让我有了实操经验，这是十分宝贵的。在下一阶段的工作中，我会与另一位PM一起，总结Alpha阶段完成的较为出色的地方，对于我们自己做的不满意的地方，我们会想出解决办法，争取越做越好。
- 四娃：1、每个成员的开发能力大同小异，经验不太一样。
2、尽量选取学习成本低的架构或者解决方案，但是要保证可用性和可维护性，可拓展性。
以前端的对于每个网络的参数设置为例，采用的是bootstrap popover插件并自己改写了一部分，缺点是可拓展性较差。目前的代码如果网络层在10个左右还可以维护，当网络层数过多时非常不好，难以维护。
3、restful api蛮好的，虽然在开始时设计有些难度但是构造的接口无论是测试还是请求，维护都方便。
4、git分支管理方面完成一个小模块就应该合并到主分支一次，不要一次合并多个commit。
5、团队成员多交流，一个人做容易进死胡同，大家都是非常优秀的同学，吸收别人的意见还是非常重要的。- 五娃：Alpha阶段已经结束，可以说团队已经进行了首次较为成功的合作，从这次经历中，学到了很多知识，也发现了自己的一些不足。
- 万事开头难。面对将开发的项目，眼前是迷茫的，因为很多东西都是新的，需要从头去学习，也不知道从哪里下手。不过幸运的是我不是一个人，我可以和队友一起努力去克服这些困难，合作的时候也许就不会感到那么难了。
- 代码需规范。当一个项目是以合作的方式进行的时候，不规范的代码就会体现出很多问题了，Alpha阶段我们去了解了代码规范，并且尽量去按照要求完成开发，期间确实感觉到自己以前写的代码都极丑无比了（一星期后怕是我自己都不认识了）。
- 沟通交流是良药。合作最需要的就是良好的沟通。比如，前后端的一些约定，以文档的形式进行有效的交流，并且有问题及时解决改进，更新文档，这样就尽可能的减少在代码合成的时候出现不一致的问题。
- 摸索前行，小步快走，及时更正，也许是十分有效的开发模式了。
- 现在该准备下一阶段开发工作了，希望我们组能做的更好，觉得有一句话说的挺有道理的：一个人也许走的很快，但一群人会走的更远。
- 六娃：在我们团队中，我担任的是测试人员这一角色，这也是我第一次在一个项目中专门进行测试工作。这次Alpha阶段给我最大的感受就是切身体会Learning by Doing。初次做关于网站的测试，需要学习一些关于测试的知识，随着开发组的更新，测试工作也要齐头并进，有时候会因为测试工作不顺利而烦心，影响工作效率。在今后的工作，我会调整好心态，利用第一阶段积累的经验，做好后面的工作。通过这一阶段的测试工作，我学到了一些重要的知识，通过亲自动手实践学到的知识显得更有价值并且刻骨铭心。
- 七弟：对我来说，我是借着软件工程这门课才第一次体会到了团队协作编程，过去自己所做过的工程基本都是靠自己一个人完成，而这一次的工程是我们组成员通过大家的协作来完成的，工程量和难度都是之前所做过的工程所不能比拟的。其实在ALPHA阶段中，我个人认为自己的贡献比例还是相对较小的，一个原因是由于很多知识之前没有接触过，需要花费很多时间来学习，由于与其他开发同学的能力水平的不同步，因此只能做一些相对简单的工作。在后续阶段的开发中，自己应以将所学知识用于实践为主要目标，以提高自己的开发能力。