AIApe问答机器人Beta阶段总结
设想和目标
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
lmx：我们的软件主要是用来解决使用者有关编程相关的问题，在需求分析中我们已经对典型用户、典型场景等有了清晰的定义。
hsw：我们的想要开发一个智能编程问答机器人，定义清楚，对典型用户和典型场景有清晰的描述
djj：我们的软件主要解决编程人员在编程过程中遇到困难后在网上难以查询解决方案的问题，定义得比较清楚。有对典型用户和典型场景的描述，如初学者遇到低级问题和编程老手遇到较为进阶的问题时的不同使用场景。
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
lmx：
第一点算是达到了目标，在 beta 阶段展示中，我们就典型场景的使用效果做了演示，效果还算令人满意。此外，出了机器人相关的功能，我们还提供了较为完善的问答社区以供弥补机器人的不足。
对于第二点虽然没有完成目标，但差距也不大，我们初期定的发布时间是六月十五号，但那几天由于其他任务较重就耽误了发布导致最终在十六号才完成发布。
对于第三点，目标并没有被完成。可能的原因是第一次开发软件，团队对用户数量没有太明确的概念导致指定的用户数量目标太高。
lhx：
首先，我们基本上完成了设计阶段提出的各功能的开发，并且在UI设计上更加完善。最后的展示效果还算不错。
我们预计是在15号凌晨发布，但是在打包上传到服务器的过程中，出现了没有预料到的问题。并且有些图片资源过大，导致网页加载过慢，在解决了这些问题之后才正式发布。
用户数量并没有达到预期的值，我认为我们对预期的用户数量进行了错误的估计，当然也有一部分是产品定位和发布后宣传的原因。
djj：
原计划的功能我们都做了到了，也按期交付了，用户数量上没有达到计划，可能是因为发布时间太短来不及宣传导致的。
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
lmx：
我认为团队的软件工程质量有了很大的提升，主要体现在团队交流方面。因为 alpha 阶段前端与后端之间的基本没什么交流，而在 beta 阶段，前后端进行了比较充分的交流，而对于衡量指标可以用交流的时间长度，alpha 阶段，前后端的交流时间大概是两小时，而 beta 阶段，前后端的交流时间应该能有 6 小时，所以大致是原先的三倍。
djj：
质量提高了，我们在计划阶段做了更详尽的计划，对于遇到的问题进行了更多沟通。
lhx：
我认为我们在Beta阶段的工程质量提高了不少。由于我更加了解前端的工作，所以在前端的设计和布局上画了不少功夫。相较于Alpha阶段，我们补充了每一个子页面的设计图。每一个设计图都考虑将后端所实现的功能体现出来，并且在用户体验上有更多的思考。虽然最后实现的效果可能与当初设计有不同，但大体一致。这对于前端的开发来说是非常重要的，让前端有更加明确的任务和清晰的思路。
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
lmx：
就 beta 阶段的用户反馈来说，我觉得还是比较符合预期的，虽然由于问题集的不充分使得实际使用质量还有待提升，但整个软件也通过提供问题社区的方法在一定程度上弥补了漏洞，所以一些用户的评价都是比较正面的，也说明我们较 alpha 阶段离自己的目标进了。
lhx：
从结果上看，用户对于我们的重要功能，即机器人问答和问答社区有着不错的评价。即使机器人的匹配，前端的分辨率匹配还有一定的问题，但是我认为这和我们的预期相符，并且离我们预想目标很近了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
lmx：
我认为整个开发过程遇到的很多问题主要是在 alpha 阶段，首先是对需求的技术的不了解，这导致了很高的学习成本，其次就是说了很多次的前后端交流问题，不充分的交流会导致前后端对产品的看法有很大的差异。如果重来一次，我觉得我会对使用的技术再做慎重的思考，或是提前去熟悉，而对于交流问题肯定就是尽早进行充分的交流。
lhx：
我觉得单从设计上来说，我的工作还可以做得更细致一些。可以使用一些设计工具完成网页原型设计，这样更有利于表达设计思路，也能够更加细化前端的工作。
计划
是否有充足的时间来做计划?
lmx：
对于 beta 阶段我认为用于计划的时间还算充分，我们在 beta 阶段开始前也进行过线下小组讨论详细地规划了 beta 阶段的开发工作。
lhx：
beta阶段我们留出了足够的时间来设计。我们在开发前组织了几次线下讨论，并且许多计划工作在预计的时间前就完成了。
djj：
有时间，在这一个阶段中我们做了比alpha版更充分的计划，计划中列出的各项任务更加详尽细致。
团队在计划阶段是如何解决同事们对于计划的不同意见的？
lmx：
由于我们采用的是单一PM的制度，所以对于意见上的不统一都是由PM进行定夺。
djj：
主要是通过会议协商解决，在这个阶段我们增加了线下会议的次数，更多的线下会议让我们对计划中的一些细节进行更好的沟通。
lhx：
基本上我们对于计划的制定都是我在定，在和组内成员充分讨论后，我会尽量对做出更加有利于工程效果和小组成员的决定。
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
lmx：
在 beta 阶段，我基本上完成了分配到我身上的所有任务。
hsw：
对于原计划的工作，还是有一些部分没有完成，比如个人中心的“评论数 点赞数”等元素。这主要是由于在打包部署到服务器上时遇到了没有预想到的问题，导致拖慢了一些进度
lhx：
一开始在Beta阶段所计划的功能全部实现，只是在后来我们打算在前端再加一些功能的时候，没能把握好时间，导致有一些功能没有按时完成（但是不太影响使用）。
有没有发现你做了一些事后看来没必要或没多大价值的事?
lmx：
后端有一项工作是为数据做打标签，一开始我们采用了手动打标签的形式，这消耗了大量精力，后来依照手动打标签的经验使用关键字匹配的方法才完成了大体上的打标签工作。但整个手动打标签的过程在事后看来确实没有太大价值。
hsw：
事后看来，对于移动端的需求并不是太大，可以先将桌面端进行更多的完善，再考虑移动端的适配
lhx：
同意hsw同学的意见，我认为我们应该花更多的时间来优化PC端端体验。
是否每一项任务都有清楚定义和衡量的交付件?
lmx：
在 alpha 阶段这一点是做的很好的，但到了 beta 阶段，由于我分配到的任务（训练 NLP 模型）在实际执行上与实现的规划在一些细节上有一点出入，导致有时候有些任务没有对应上指定的交付件。但整个过程总体上还是有所对应。
djj：
我们规定了每一项任务的内容，这一阶段我们的规定比之前更加精细，由于上一阶段我们前端的效果并不是太好，我们在这一次计划时对每个页面的布局进行了更细致的设计，然后我们照着设计进行实现，展示时也取得了比上一次更好的效果。
hsw：
在Beta阶段中，我对每一项任务都与PM详细探讨，先完成原型设计，再页面实现，做到每一项任务都有交付件
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
lmx：
就 beta 阶段来说，整个过程还算顺利，唯一与计划有出入的部分就是打标签的过程，由于采用手动打标签的方法效率太低，导致当时差点无法在发布前完成工作。这个问题的产生主要是因为一开始只是把打标签作为一个扩展工作，但后来由于聊天流程的设计导致打标签的工作变得比较重要，所以在实际执行情况下就产生了可能无法实际交付的问题。
hsw：
项目的大部分都按计划进行。只有在打包发布以后，发现某些图片、字体文件过大，加载缓慢，导致用户体验下降，这是之前没有预想到的问题
lhx：
在展示阶段，有一位同学所提的：网页每次都要重新刷新较热门的问题，如果此时有人恶意对服务器进行快速操作，很可能导致服务器运行较慢、网页崩溃等问题。这一点是我们当时并没有预料到的。
在计划中有没有留下缓冲区，缓冲区有作用么?
lmx：
我认为算是留下了缓冲区，一开始规划的 NLP 模型相关的工作就预留了很多弹性空间，以及打标签这个工作也算是缓冲区。设置这些弹性空间（缓冲区）主要是考虑到每个人物的时间不能精确计算，所以预留了一些任务以供在时间充足的情况下完善项目。这既提高了项目的鲁棒性也体现了我们对项目考虑的充分性。
lhx：
我认为前后端都留下了一定的缓冲区。后端在issues中就有补充任务。而前端在完成基本的功能后，又添加了不少新的功能（比如用户头像等等）。我认为缓冲区其实是一个项目节点，在缓冲区前，团队开发任务比较紧张，将所有的功能实现之后，我们在缓冲区阶段能够更加游刃有余的进行新功能的开发。
将来的计划会做什么修改？（例如：缓冲区的定义，加班）
lmx：
将来的计划，现在好像没有太考虑将来的计划了。祝自己软工有个好的结局。
lhx：
如果学弟想要继续选择我们的项目开发的话，我可能会劝退（X）
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
lmx：
对于计划部分，我认为 beta 阶段做的已经不错了，如果要说改进的话，我认为有关 NLP 模型部分的计划可以再详细一些，也就是初期做充分调研，因为在完成这部分的过程中确实发现了一些与初期规划的不协调，这就导致最后虽然都完成了功能，但在交付任务的时候不太好找到每个功能实际对应的子任务。
hsw：
如果重来一遍，我们应该更加注意任务的成果，即每一项任务要有实际的成果出来，才能算是完成
lhx：
如上面所说，我希望能够将计划做得更细，这样更有利于开发。
资源
我们有足够的资源来完成各项任务么?
lmx：
就我自己的任务来说，主要是 NLP 模型的任务，以及获取数据集的任务。对于前者，主要的资源消耗是算力资源，这一部分在舍友的帮助下没什么问题。而对于后者，通过爬取思否的网站也成功解决了。
各项任务所需的时间和其他资源是如何估计的，精度如何?
lmx：
时间规划与资源规划是线下讨论得出的，就最终的完成情况来看，这部分精度还算可以。
lhx：
前端和后端分别自己讨论出各任务的分配和预估时间，由PM来判断时候需要修改。
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
lmx：
对于测试，事实上资源有些不足，首先由于代码有很多的依赖，导致单元测试不好解决。而对于不需要编程的资源，由于我的工作涉及到这部分比较少所以也不太了解。
hsw：
对于不需要编程的资源，我们在Alpha阶段就吃了大亏，大大低估了难度，导致实现效果很差。在Beta阶段中，我们着重改善了这个问题，实现了页面的重新设计，虽然最后还是有很多小问题，但进步很大。
lhx：
对于前端而言，其实有许多已有的框架，如果多像这些框架借鉴，可能在设计和展示上有更好的效果。
你有没有感到你做的事情可以让别人来做（更有效率）?
lmx：
确实有这种可能，但就开发的过程来看目前这种分工也挺合理的。
有什么经验教训? 如果历史重来一遍,我们会做什么改进?
lmx：
在前面没有提到的一点是关于 NLP 模型的运行资源的问题，因为这个模型在 GPU 环境下运行的更快一些，而我们的服务器没有 GPU 资源，这就导致我们需要使用 CPU 跑这个模型，并且会消耗不小的内容资源，这就导致我们不得不想办法减小模型的体量，额外地增加了我们的工作量。而如果一开始就能考虑到对 GPU 环境的需求，或许就能节约一点精力。
lhx：
我可能需要更多的参与到前端的开发中。由于Beta阶段其实前端的压力蛮大的，所有的东西都要重新来一遍，如果我更多的进行开发的话，可能效果会更好。
变更管理
每个相关的员工都及时知道了变更的消息?
lmx：
这部分在我看来是有做到的，因为当规划有变动的时候都会及时在交流群进行通知，基本上也都有及时获取变更的信息。而对于后端自己的任务，因为只有两个人，在有变动的时候基本也做到了及时沟通变动。
hsw：
大部分时候有相关变更，我们会在工作群里告知。但是前端的两个队友之间交流不是很充足，经常出现pull下来以后发现代码改动导致bug的情况
lhx：
前后端之间的消息我们几乎都是在例会和平时的群消息中告知的。
我们采用了什么办法决定“推迟”和“必须实现”的功能?
lmx：
如果有一项功能有变动的，如“推迟”或“必须实现”，我们都会在组内进行讨论，根据讨论的结果做出抉择。
hsw：
先进行任务量评估，再进行必要性评估，由PM来决定这个功能的紧急程度
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
lmx：
在 beta 阶段，我认为“做好了”首先要保证所有实现规定的功能需要完成，其次是要做好测试，包括功能测试、压力测试、场景测试等，然后再在一定范围内进行组织用户测试，经历过所有这些环节才算“做好了”。
lhx：
我认为前端这方面的定义比较模糊。前端的出口条件在于在场景测试下不会出现bug、压力测试中能够良好的响应请求、用户体验尚好这几项。相对后段来说，用户体验这一项就比较难以清晰地定义。
对于可能的变更是否能制定应急计划?
lmx：
这一点我认为我们存在一定的欠缺，因为我们并没有提前考虑好各种可能情况的变更，一般变更的情形都是什么时候遇到需要进行变更，什么时候组内进行商量并制定计划。
hsw：
大部分时候，前端能够及时处理意料之外的工作请求。因为前端是边使用边发现bug的一个过程，经常需要修复小的问题
lhx：
紧急变更（尤其是前端）都是由我来做决定，从结果上来看，效果还不错。
员工是否能够有效地处理意料之外的工作请求？
lmx：
由于我在项目中主要负责后端，对整体团队的了解还不够充分，但就后端来说，开发期间遇到的一些意外基本都能比较有效的解决，如服务器环境可能无法运行较大的模型就额外进行了模型蒸馏工作。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
lmx：
对于变更管理这一块，其实在开发的过程中体会的并不多，但我觉得关键集中在两方面：一是开发的工作量要有一定的余量来面对突发的变更。二是在组内充分的讨论以使得每个人都理解变更对所涉及到的改动。
设计/实现
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
lmx：
设计工作是在冲刺阶段前开始的，也就是 alpha 阶段结束后，beta 阶段开发开始前组内找了一个时间线下进行讨论，然后在此期间共同商量讨论设计工作。
hsw：
对于页面设计工作，Beta阶段中进行了更多的线下讨论，细化每一个页面的设计，相比Alpha阶段“大概这样”的情况有了很大的改进。但是对于“移动端适配”这个任务，还是过于模糊，导致最后实现效果不佳
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
lmx：
整体的设计确实是一个越来越具体的过程，就我们团队来说，我认为我们的模式更像：面对一个不太具体的设计，每个组员提出自己的想法，然后由团队决定那种想法更合适，以此来逐渐完成设计的具体化。
lhx：
前端的设计其实方案有很多种，但是我和hsw同学对意见都比较统一，没有遇到太多的模棱两可对局面。有也是对于比较小的功能的情况。
dxy：
整个后段结构设计很好，基本上符合高内聚低耦合，但是在实现的时候，却经常破坏设计，比如设计上虽然控制层需要一些鉴权功能，但是总的来说权限控制，包括登录注册，主要是在用户服务中完成，但实现的时候却混合在了一起；再比如人工问答服务和数据层的设计，本来数据层只负责数据库访问，但是最后人工问答服务成了一个转发器，几乎所有逻辑都在数据层中。实现时对设计的破坏在beta阶段的时候更为严重，因为此时工程的代码量已经很大了，改着改着就成屎山了，就算有文档和注释也开始乱了。并且机器人服务作为一个上层服务，可能需要调用其他服务，写的很混乱，有一些通用的算法，最开始没有注意到其公共性，而实现在了业务类内部，导致复用的时候出现了困难。以后应该适当地将工程进行拆分，一个主项目，搭配多个子项目，这样一方面不至于工程过于臃肿难以维护，也可以强制进行一定的隔离和保护。
最开始设计架构的时候没有考虑到后台定时任务，所以后来添加热榜更新、数据库与NLP微服务数据同步的定时任务的时候，十分痛苦。跟上面，定时任务完全可以和其他部分不在一个工程中，甚至不必在一个进程中，它们之间可能会共用一些部分，将共用的部分抽象成一个单独的类库工程，然后一个Web工程提供Web服务一个控制台工程进行后台定时任务，这样的安排会比一个大工程完成所有工作清晰得多。
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
lmx：
团队开发过程中使用了单元测试，而没有使用其他开发工具。对于单元测试，我认为其在一定程度上减少了由于粗心所产生了程序漏洞。
dxy：
开发模块的时候没有考虑测试，导致测试的时候出现了一些障碍。一方面，有些相对比较大的类是直接实现的，没有接口，导致单元测试无法构建动态代理的Mock对象；另一方面，IoC容器中，临时生命周期的对象，如果需要一些共享的变量，我都采用的static变量的方式，但是这在单元测试的时候出现了问题，因为所有单元测试用例共用同一个static对象，所以一个测试用例结束之后，并没有对static对象进行重置就进行下一个单元测试，此时就可能出现问题。应当将共享变量抽象成一个类，将这个类的生命周期设置为单例的，然后添加到IoC容器中，使用的时候将这个单例的共享对象通过依赖注入添加到临时对象中。
单元测试覆盖率较低，主要有两方面原因，一方面，人手不足，alpha阶段测试数据层的时候可以通过SQLite.InMemory构建一个临时数据库进行测试，解决了很多构造Mock对象的问题，但是beta阶段大部分测试都需要构造Mock对象，而且需要构造大量的Mock对象，十分麻烦，而且我们使用的Mock库Moq只能对interface构建Mock对象，而我们不少类是直接实现的，没有定义interface。另一方面，单元测试的结构不佳，被测对象的生成是在每个样例内部进行的，这就导致构造方法发生改变的时候，就需要对每个样例进行修改，十分麻烦。
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
lmx：
我认为 bug 比较多的地方在于登陆令牌有效期这块，因为在初期测试经常遇到机器人无法回复消息的问题以及其他一些与登录有关的问题。但这一块主要与前端的工作有关，所以没有太具体的了解。
hsw：
发布的过程中，首先遇到了css被覆盖的问题，调整了代码import顺序后解决；后又遇到较大的文件(图片、字体等)加载缓慢的问题，这与服务器也有一定的关系，删除了一些图片，改为css渐变背景来优化用户体验，并将字体文件压缩，减小传输压力
代码复审（Coe Review）是如何进行的，是否严格执行了代码规范？
lmx：
就后端的工作来说，我们的代码复审过程是当其中一个人向后端主分支提交代码时，交由另一个人进行审核与 merge。这个过程的审核遵守了代码规范。
djj：
前端部分几乎没有进行过代码复审，绝大部分情况下是代码能够正常运行即可。我认为这方面需要加强，尽量加强对代码质量的管理。
hsw：
前端没有进行代码复审，这是我们做得不好的一点，也没有完全遵循代码规范，考虑使用插件对代码风格进行检查
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
hsw：
我认为前端在分工上还是有些不够明确，或者说对于开发的任务量估计有所偏差。如果重来一遍，我希望两个前端都集中于PC端的开发，优化更多细节。
lmx：
首先是在设计的过程中应要求组员的充分参与，使得每个人都知道项目的整体情况。其次是前后端人员在开发过程中应保证内部的互相审核一爆增开发的一致性。
dxy：
API设计的前后，没有进行线下的讨论，虽然在线上让大家一起看看，但是没有进行有效的反馈，导致API经常需要修改。
Scripts文件夹下是一些辅助部署的脚本，但是最开始的时候这个文件夹结构很混乱，也没有什么规范，当Scripts下内容变多之后就开始变得混乱了。后来进行了一些整理，比如将config、post、login等提出来做成一个utils之后好了很多，但是仍旧很乱。最开始没有预料到Scripts会做的很大，后来才发现这里写了很多，足足有将近2k行代码（不包括注释和空行）。现在看来，这种辅助性质的工具，尤其是当我们选择用python进行开发的时候，就应当将其视为一个工程，也需要指定一些规范，也需要创建文件夹编写模块，而不是像现在这样也蛮地进行。比如DataManager模块，留在Scripts文件夹下的只有一个DataManager.py，其中只完成主循环和任务分配，而主体逻辑实在DataManager文件夹下的字模块进行编写的。
测试/发布
团队是否有一个测试计划？为什么没有？
lhx&lmx：
测试计划包括：单元测试、压力测试以及场景测试。单元测试主要有两位后端完成，压力测试和场景测试由两位前端和PM完成。
是否进行了正式的验收测试？
lmx：
我们在项目发布的同时还完成了测试计划内的各个测试，按我的理解这可能能算是验收测试。
lhx：
在项目发布前我们也在不断的进行测试，并且完善单元测试。
团队是否有测试工具来帮助测试？
lmx：
很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。
后端主要进行了单元测试，这部分是使用 C# 的一个单元测试框架进行的，但需要手动设置测试样例。而由于没有经手压力测试与场景测试，所以对这部分是使用的工具不太了解。而对于改进计划，我认为能使用自动测试的地方当然充分利用起自动测试的优势是很好的，但有些地方如果通过手动测试可以达到更大的覆盖面也可以使用手动测试，关键就在于根据情况结合使用吧。
团队是如何测量并跟踪软件的效能（Performance）的？压力测试（Stress Test）呢？ 从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
lmx：
对于第一个问题，首先在我们做好了充分的日志记录以跟踪软件的实际运行情况。而对于后面的问题，由于软件自上线以来还未出现较大的问题，所以暂时没有预期的改进。
lhx：
压力测试方面，我们使用的是Jmeter进行压力测试，这个测试软件可以用来测试各端口面对高并发用户请求时的性能。
在发布的过程中发现了哪些意外问题？
lmx：
前端在打包发布的过程中曾出现过一些意外，主要是与一些资源有关，但我没有进行更深入的了解。
hsw：
发布的过程中，首先遇到了css被覆盖的问题，调整了代码import顺序后解决；后又遇到较大的文件(图片、字体等)加载缓慢的问题，这与服务器也有一定的关系，删除了一些图片，改为css渐变背景来优化用户体验，并将字体文件压缩，减小传输压力
我们学到了什么? 如果重来一遍, 我们会做什么改进?
lmx：
最重要的当然是做好充分的测试规划，事实上我们的测试计划是在临发布的时候才有了整体的想法（又或者是我个人是在这个阶段才知悉的），如果在开发初期就能进行比较详细的测试规划，不仅能让我们由更多的余力进行测试，同时还能使得测试进行得更充分。
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
lmx：
团队的分工是在 alpha 阶段开始前根据每个人自己的意愿确定的。就当时来说，其实大多数人都没有太多的前端或者后端经历，都需要从头学起，所以当时也很难说人尽其才，主要是根据个人兴趣。
djj：
我们团队中主要包括一个项目经理，两个前端开发，和两个后端开发，在这一阶段我们的项目经理也参与了一小部分前端的开发工作。角色分工主要是计划阶段大家共同讨论决定的。我认为我们目前的分工可以说人尽其才，大家都处于比较适合自己的位置上。
lhx：
团队每个人的角色延续了Alpha阶段的角色分配，我认为大家在Beta阶段更加熟悉相应的开发框架和工具，能够更加高效的实现计划和完成分配的任务了。
团队成员之间有互相帮助么？
lmx：
就后端来说，我认为还是存在很多帮助的（至少是单方面帮助），因为另一个后端同学较我来说对所需的技术有更深的了解，所以很多时候都都为我提供了很多开发上的帮助。
lhx：
我认为在前端的设计上，hsw提供了非常多的建议，让我能够更好的完成页面的设计。
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
lmx：
在之前也提到过，因为我们有单一的 PM，所以在遇到问题的时候，很多时候都可以由 PM 来帮助解决。
hsw：
出现像项目管理、合作方面的问题时，我会联系PM，让他与相关的队友进行沟通，避免直接的接触
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
lmx：
我感谢 ____邓新宇____对我的帮助， 因为某个具体的事情: _帮助我在不熟悉 C# 以及 ASP .NET的时候解决各种开发问题。还有其在后端开发中起到的主导作用，带领我（算是）比较顺利地完成了各项后端任务。
总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
lmx：
我觉得我的团队目前处于第二级管理级。
djj：
我认为我们处在可重复级(Repeatable)阶段。我们的管理有了一定的制度，工作中的任务都通过github中的issue进行管理，任务完成后由项目经理关闭issue。前端后端等各部分都在git仓库中有自己的分支，由开发人员提交到对应分支并给项目经理发出MergeRequest来合并。
lhx：
我认为处在第二个档次，重复级阶段，有规范的管理。
- 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
lmx：
我觉得我们的团队目前处于规范阶段。
lhx：
我认为属于规范阶段。
- 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
lmx：
一是团队内的讨论增多了，二是成员之间对于要完成的项目有了更多的共识。
lhx：
最重要的是，团队的沟通增加了，这一点对于所有事务来说都是至关重要的！
- 你觉得目前最需要改进的一个方面是什么?
lmx：
我认为是工具的使用，主要是在做项目规划的时候，使用的工具比较少，比如 UML 什么的都没有使用到，这引出的一个关联方面就是初期规划的粒度，也就是我们初期规划的粒度可能还不够细。
djj：
我认为我们最需要对计划中的任务进行更精细和规范的要求，以及对任务进行更合适的时间预估。
lhx：
我认为我们还需要将任务更加细化，这样对于开发人员来说也更好有明确的目标。
- 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
lmx：
- 原则二：敏捷流程欢迎需求的变化，并利用这种变化来提高用户的竞争优势。
起初在规划机器人流程的时候没有日常对话，但后来考虑到一些人使用这个软件的时候会问一些比较日常的问题，所以就加入自然问答这个需求了。 - 无论团队内外，面对面的交流始终是最有效的沟通方式
我们团队在 beta 开发前，以及开发初期进行一些设计的时候，都采用了线下进行的模式。
djj：
无论团队内外，面对面的交流始终是最有效的沟通方式。beta阶段我们加强了线下交流，开了更多次线下会议，对工作中遇到的细节和以后的规划进行了较多的讨论。我认为这一点提高了我们工程的质量。
- 正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
lmx：
首先项目的主要分支包括三个：主分支、前端分支与后端分支。我认为可以这样做：
- 每个新的功能最开始只能提交到前端分支或后端分支，然后才能合并到主分支上。对于合并到主分支这一行为，需要交由 PM 进行审核。
- 每个提交到前端分支或后端分支的代码，需要交由前端或后端内的其他人员进行审核。
hsw：
- 对于前端，代码规范做得并不是很好。应该考虑使用一些代码风格检查的插件，对代码风格进行严格的要求
- 对于前端，css部分的架构并不是太合理，应该多多参考实际项目中的具体架构与实现进行一定的重构
