诸葛亮文档
设想和目标
1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
传统编程教育模式下，初学者(主要是刚刚接触编程的学生)往往依靠老师与助教的课堂教学，由于时间有限或者得不到针对性的训练，编程初体验比较差，我们希望借助AI以及体贴的设计，用一款软件来帮助初学者更好的学习编程语言。
我们的问题定义较为明确，软件“AI Coach”针对刚接触python编程语言，编程经验很少的初学者，优化他们的学习曲线，提高他们入门学习编程的体验。
典型用户：刚开始以python为接触的第一门编程语言的大一新生。
典型场景： 小明大学之前从未接触过编程，大一开始学习python，非常吃力，不知道从何入手，希望在课余时间能找到一个平台做针对性的练习，提高编程水平。
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
我们达到了alpha阶段的目标，实现了最小可用系统对模型的基本要求。原计划的推荐题目功能(冷启动及热启动)，友好的错误提示功能(三种不同的方式)都做到且按时交付了。alpha阶段的用户数量来自各组进行测试的同学们。
3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
目前的alpha阶段只实现了最小可用系统，但内部接口及与后端的接口定义划分已经较为明晰了，应该可以说达到了目标的工程质量，不足及考虑不周的地方在beta阶段可以进一步去提高。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
alpha阶段用户量只有我们几个小组的同学，也没有实现多用户的功能，大家都是在同一个用户下进行测试的，从测试结果来看，用户在网页上做题，跑代码，看结果，进行友好报错，提交评价等的流程已经能够完整跑下来了。 基本功能达到了可用的程度，可以接受。友好报错方面结果对于部分错误给出了比较好的结果，但也有部分错误结果比较不可靠，有待进一步提高。我们在alpha阶段迈出了从无到有的一大步，离目标更近一些了。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
经验教训方面，我们在alpha阶段结束后认真审视了我们之前的工作流程，发现有很多可以提高的地方。scrum流程上因为模型组任务跨度较大，小组内做不同事的同学先分别快速交流讨论，最后集中起来大家一起总结一天的工作在相同的时间内可以达到更高的效率，也能更好的交流减少因为沟通不畅而产生的额外时间花销。内部及与其他组的接口应该更早的商讨并确定，一旦确定就要尽量避免改动，小组之间的工作对接要比组内的时间花销大，需要予以更多的关注。
计划
1. 是否有充足的时间来做计划?
没有， 由于之前我们没有对模型组的任务做充分的调研，倒是alpha 阶段一开始我们不知道要干什么，计划也是在执行过程中不停地修改。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
scrum中讨论，然后少数服从多数
3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
做完了
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
没有
5. 是否每一项任务都有清楚定义和衡量的交付件?
是
6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
没有，计划在不停修改，因为我们一开始并没有很明确的把问题定义好。
7. 在计划中有没有留下缓冲区，缓冲区有作用么？
有，缓冲区就是full rule based， 这个两天就可以弄好，所有我们有退路
8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）？
不会，我们alpha 阶段这种类似科研的探索开发开展得很愉悦。
9. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
我们发现，其实研发和科研是一样的，重要的是发现问题，定义问题，解决问题，我们在这个过程中不仅体会到了开发的充实，也体会到了创造新东西的愉悦。
在beta阶段，我们会用深挖项目中，模型组所负责的问题，然后努力寻找“局部最优解”。
资源
1. 我们有足够的资源来完成各项任务么?
人力资源方面：我们组人手较为充足，可以分配为几个小组分别完成两个不同的任务：推荐系统与提示系统。
硬件资源方面：我们组由于用到神经网络，需要一定的GPU保证计算速度；由于我们组大部分成员都有GCR节点，因此足够进行调试开发。最终部署时，我们同样使用了GCR节点的GPU。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
估计方式：各项任务所需时间和其他资源在scrum meeting上由scrum manager、PM和相应工作负责人员进行估计，随着工作实际展开随之调整。
精度：初期，由于需求与技术选型都不完全确定，估计工时误差较大，部分估计误差达到半天；后期，我们在组内讨论及与后端沟通过程中逐渐确定了工作具体内容与技术细节，工作时间估计误差能够控制在30min以内。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
变更管理
1. 每个相关的员工都及时知道了变更的消息?
每个相关组员都能及时得知变更消息。以下分两个方面说明：
（1）需求上的变更：当我们需要增加新的特性，或者对我们产品功能的要求有较大变更的时候，PM会与相关组员面对面讨论，在所有相关组员意见达成一致之后才会正式通过。同时，我们会在VSO上分配或修改任务，相关组员会收到邮件提醒。
（2）技术细节上的变更：当有一些技术细节需要调整的时候（常出现在组间对接时），我们会修改文档，并通知相关成员及时根据文档进行修改。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们主要是根据a. 每项功能的重要性; b. 实现所需要的时间这两个因素来决定的。
具体来说，对于核心功能，我们都要求“必须实现”。比如说友好报错信息这一功能，在和后端对接的时候发现要进行大量修改才能对接，但因为这是非常核心的功能，“必须实现”，所以组员投入了大量的精力进行修改。
对于一些非必要功能，在时间安排不允许的条件下，我们会决定“推迟”。
3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
对于alpha阶段，我们定义的项目出口条件为：
（1）必须完成定义好的三项任务：友好报错与提示，构建用户画像并智能推荐题目，根据用户数据改进模型。在我们最后的产品中，成功完成了这些任务。
（2）完成的产品必须具有鲁棒性。对于各种可能出现的情况，都要保证程序不会崩溃。在完成基本程序编写之后，我们又针对这一点进行改进，基本保证了产品的鲁棒性。
4. 对于可能的变更是否能制定应急计划?
我们在这一点上做的还不是很好。我们的工作一直遵循着“最小可用”原则开展，对于各种变更我们会先做出一个可用的方案。但在“制定计划”上我们仍然有所欠缺，更多的是走一步看一步。
5. 员工是否能够有效地处理意料之外的工作请求？
是的，组员们都能有效地处理意料之外的工作请求。这一方面得益于组员们的责任心，另一方面，也得益于小组的合理组织。当有意料之外的工作需要的时候，PM会协调处理，不会“甩锅”，而是和相关组员讨论是否能够处理，当任务量大的时候，会安排其他小组成员进行协助。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在变更管理这一方面，我们学到了
设计/实现
1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作分为两个阶段，在项目的前期规划阶段，我们进行了统一的讨论，确定了项目整体模块架构的初步设计，并将团队划分为了几个小组以对应不同的功能模块。项目需求初步确定后，由每个小组的内部成员讨论确定每个模块具体的细节设计。通过这样的方式，我们自顶向下地分解了整个设计任务，并且让每个成员都参与设计了自己熟悉擅长的部分，保证了人员安排和时间安排的合理性。
2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
存在过这样的情况，我们整理的应对思路是从简单到复杂逐步扩展。首先确定那些毋庸置疑的部分，并快速地加以实现。然后在初步实践的基础上再进行更进一步的细节设计。这样我们可以一定程度上缓解项目初期的迷茫感，也大大减少了过度设计的可能。
3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
我们为模型对外提供的API都编写了对应的测试样例及测试代码，并在代码合并前由各个负责人检查代码改动是否通过了测试。我们这次开发暂时没有使用测试驱动，由于算法模型的输入输出在前期很难明确，我们的测试样例在模型初步稳定后才能进行合理的构建。由于我们团队主要负责整个项目的模型与算法设计，因此我们也设计了一套检验模型质量的指标，为以数据驱动的模型迭代创造了基本条件。
4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
我们在项目对接时发现了最多的bug，而这些bug大部分都是因为我们双方在数据传输规范性上的约定不一致导致的，这让我们认识到了建立详尽接口说明文档的必要性，过于简要的接口文档会增加不必要的线下沟通成本，甚至会迫使开发者进行多次的代码重构和重部署，实际上反而增加了人力开销。在设计时没有能够重视这一点的原因是，我们一开始的组间讨论并不充分，也没有事先就达成一些较为明确的约定。在后期对接时我们较为及时地对这些疏忽做出了纠正，完善了接口文档。
5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审由PM和scrum master两位同学兼任，当一个分支的功能实现完毕，或者一次版本迭代完成了，由分支负责人提起Pullrequest，交由两位同学进行code review，并提出合理的改进意见。这保证了主分支上的代码都经过了二次确认，尽可能提升主分支代码的稳定性。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
较为清楚的感受是，项目的设计工作很难一蹴而就，而是随着项目的发展不断丰富和完善的。如果重新来过，我们会更加注重工作开展的层次性和纵深性，从骨架到血肉进行逐步讨论和实现，节省一些前期盲目规划的时间。
测试/发布
团队是否有一个测试计划？为什么没有？
是否进行了正式的验收测试？
团队是否有测试工具来帮助测试？
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
在发布的过程中发现了哪些意外问题？
我们学到了什么? 如果重来一遍, 我们会做什么改进?
团队的角色，管理，合作
团队的每个角色是如何确定的，是不是人尽其才？
在第一次scrum中我们将整个Model组的任务分为两部分，Recommender Systems和Hint Systems。推荐系统由Jie Pan, Linfeng Qi,Kun Yan三个人来负责。提示系统由 Xueqing Wu, Yutong Lin, Lei Chai主要负责。Jiyan He作为组长，两个部分的工作都有参与，最终完成了代码整合的部分，同时和前端后端对接。Zhipeng Huang由于有CVPR投稿的ddl，所以负责每天的scrum的整理和日志的撰写。成员的具体分工如下：
Jie Pan
Recommender::Path, Cold start, Survey design, Learning path design
Jiyan He
API design, Code control, Documents, Dockerize, Server ops, Debugging with FE/BE
Kun Yan
Recommender::ALS, Mock data, Cold start, Debugging with BE
Lei Chai
Hint::www, Documents
Linfeng Qi
Problems, Tags, Input/output, Solutions, , Initial comments
Xueqing Wu
Hint::neural, Documents, Common mistakes, Initial comments
Yutong Lin
Hint::structure, Documents, Common mistakes, Initial comments
Zhipeng Huang
Scrum reports 1,2,3,4,5,6,7,8,9,10,11
我们认为全组所有成员都人尽其才，大家最大效率的完成了自己的部分。每一个具体小组内成员相互协调合作，同时也都和前端后端完成了良好的协调对接。每当有某一个成员的工作出现困难，都能在小组中及时的找到援助。
团队成员之间有互相帮助么？
每天在scrum中，大家在小组讨论中都能及时的提出自己遇到的困难和困惑，其他成员会提出自己的想法，大家在沟通中可以很快的找到更好的解决方法。在日常工作中，我们都能够及时通过teams来沟通和帮助。 当出现项目管理、合作方面的问题时，团队成员如何解决问题？
在项目的管理方面，组长jiyan一直都能很好的组织和规划项目的进度，小组成员也都能及时的提出对于当前进展的建议。出现合作的问题时，我们常常会预约一个讨论室，面对面的解决问题。如果问题较小时，基本通过teams也都能得到好的解决。
每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：
我感谢 _______ <姓名> ______对我的帮助， 因为某个具体的事情: _____________________。
总结:
1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
我们团队目前基本处于已定义级。在开发过程中我们由分成了两个大组，最后有组长统一进行协调。并且组员所负责的接口功能等都有着良好且同意的定义，并会同步跟进文档。我们对整个项目的进程、指责等都有基本的共同理解。
2. 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我们团队处在规范的阶段。经过一段时间的共同工作和相互讨论，我们对自我在团队中的定位和所担负的指责都有了基本清晰的任职，并且成员之间的相互合作也有秩序地进行着。
3. 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
相比前一个我们对自己所要做的项目有了更加清晰的认识，对最终产品的形态有了一个共同的认知。
4. 你觉得目前最需要改进的一个方面是什么?
我们团队之间的合作和t讨论目前还是以线下见面为主，有的时候并不是每个人都有时间，而且有的时候很浪费时间。应该多利用线上交流提高效率。
5. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。 一、避免不必要的开销：我们团队内部是分为两个小团队的，一个做错误处理一个作推荐。这两个工作之间目前是没有耦合的，所以我们都是先小组内讨论交流，然后在一起集中交流。避免过多浪费时间。
二、协作：我们每个成员都有着明确分工，对于每个分工所要实现的功能和接口我们都提前协商好，并且有必要的文档支持，这样每个分工作完成之后，可以很快将成员的成果组合起来。
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
- 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
代码管理：充分发挥Git等版本管理工具的功能，如branch等将在开发项目与已确定的项目隔离；成员之间进行代码审查；为自己的代码编写测试代码，请求别人帮助自己进行代码的功能测试等；对于代码的接口要达成共识。
代码复审：首先要检查代码的功能性，其次寻在代码的缺陷，最后对代码的风格进行评估
代码规范：代码首先要简单易懂，必要处有注释，有必要的文档。组内对命名规则等达成同意的规范。
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
其它软件工具的应用，应该如何提高？
项目管理有哪些具体的提高？
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
项目文档的质量如何提高？
对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)
各个成员得分情况
跳槽情况
会议照片
Lei Chai 病假
Jiyan He 去西安开技术会议了。