Backend事后诸葛亮
事后诸葛亮
设想和目标
-
我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们的软件想解决初学编程语言的入门困难。定义的不算太清楚，没有仔细地调查用户入门的困难之处。
针对的典型用户是编程语言的初学者，暂时只能学习python语言（并且认为其之前没有语言基础）。 -
我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
达到了基本的目标，计划中的部分都完成了，且按原计划时间交付。 -
和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？
无上一阶段。 -
用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
我们在该阶段不考虑用户量。即虽然在底层保留了多用户数据库和多用户模型，但是alpha阶段我们只用了单个用户进行测试。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
如果重来一遍的话、我们会把和前端模型的交流放到更重要的位置上，完成了任务之后我们发现项目的推动主要依靠于另外两个组的push。他们需要测试某项功能的时候我们才发现没有完成然后继续去做。重来一遍的话我们就会以这个为动力来做好后端的工作
计划
-
是否有充足的时间来做计划?
项目的整个过程都按照计划进行，但这个计划在项目开始后第一天发生了很大更改。我们原本有充足的时间做好了计划，但是工作第一天scrum组长就宣布要离开了，以及两位已经安排好的队员也退出项目所以这是我们没有估计到的一个风险，就是队员“临时”退出的问题。这个问题的没考虑到主要是一开始没有和一些没选课或者不需要学分的同学单独确定，解决方式就是剩下的队员立马集结起来重新确定计划。 -
团队在计划阶段是如何解决同事们对于计划的不同意见的？
团队中在前两次开会中敲定了之后所有的计划，并且进行的还算顺利。在之前的会议中确实会出现不同意见，但是由于我们模块分的比较明确，不同的部分的人员都是按照自己的方式进行实现的，只需要告诉同伴接口即可，如何执行该模块完全由完成的人员来实现。总的实现的功能接口部分由组内维护的文档来决定，有不同意见马上开会讨论修改文档。其次也有不同意见是靠一些队员斡旋一下或者请教mentor和助教来解决的。 -
你原计划的工作是否最后都做完了? 如果有没做完的，为什么?
组内成员计划的工作都完成了。 -
有没有发现你做了一些事后看来没必要或没多大价值的事?
沙箱部分刚开始的实现改了很多版，浪费了一些时间。组内沟通花了一些时间，最后发现重要的是和另外两组的沟通。 -
是否每一项任务都有清楚定义和衡量的交付件?
有的。我们组内主要功能的三个模块，数据管理、前端与模型端接口实现和沙箱设计相关人员都有明确的测试标准与接口标准。在doc上明确写出来的任务是有的，但是有些非常小的bug非常快速的解决了就没有记录下来。 -
是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
项目的整个过程都按照计划进行，但这个计划在项目开始后第一天发生了很大更改。我们原本有充足的时间做好了计划，但是工作第一天scrum组长就宣布要离开了，以及两位已经安排好的队员也退出项目所以这是我们没有估计到的一个风险，就是队员“临时”退出的问题。这个问题的没考虑到主要是一开始没有和一些没选课或者不需要学分的同学单独确定，解决方式就是剩下的队员立马集结起来重新确定计划。 -
在计划中有没有留下缓冲区，缓冲区有作用么?
我们在计划中没有留下缓冲区，实际上在对接过程中有很多小bug。如果有两到三天的缓冲区可以把这些bug更优雅地完全fix掉，而不是选择退而求其次的打补丁形式。
- 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
将来的计划会做什么修改？Beta阶段我们会设置两天左右的缓冲区，并且要求后端的模型层和视图层工作再解耦的更好一些，写一份模型层的文档来给视图层调用数据库接口。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
alpha阶段里主要学习的是软件工程里的沟通交流、使用git写作、交流合作时定义好api接口、联调时提issue然后相应负责的人解决。
资源
-
我们有足够的资源来完成各项任务么?
有服务器搭后台的硬件资源和两周的时间。 -
各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务所需的时间是在一开始估计的，也有后来添加的，精度毕竟只是之前的估计，不算太准确。 -
测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间是在我们每个人每写一个小模块就拿来测试，时间是足够的。可能最后各个组一起联调的时候会感觉测试不够。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
变更管理
-
每个相关的员工都及时知道了变更的消息?
我们主要采用在teams群中交流的形式，一旦由东西merge进分支都会提醒一下群里人员。接口的变更除了该方式之外，还会开个小会讨论下，修改一下doc。 -
我们采用了什么办法决定“推迟”和“必须实现”的功能?
我们开发阶段就决定好了alpha阶段做MVP，所以三个组讨论的时候就商量好了哪些功能是必须做的，最后发布alpha版本的时候也都做到了。 -
项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
没有特别清晰的定义 -
对于可能的变更是否能制定应急计划?
我们在第一天发现只剩下三个同学能参加任务，于是紧急开会变更了计划，并重新分配了任务。 -
员工是否能够有效地处理意料之外的工作请求？
后端和前端在联调过程中都有提出过之前没有想到的需求，我们都一一解决了。
设计/实现
-
设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
数据库设计的太早了，不过如果不早点设计好数据库又会出现无法继续进展的问题。 -
设计工作有没有碰到模棱两可的情况，团队是如何解决的？
非常多、基本是交给个人实现的时候自行解决 -
团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
我们写接口前是要求大家都自己做好单元测试的，虽然最后对接的时候看起来没有用到太多。不过整体来看使用了单元测试的同学bug出的比较少。 -
什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
提交代码运行的部分产生的bug最多，因为这部分实现起来的逻辑最复杂，用户提交后要根据运行的结果分别处理stdout和stderr，而且要把美化过的stdout和stderr返回给前端。并且在这个api的实现里还需要和模型组交互多个hint接口。发现的重要bug比如返回给前端的error中有随机的文件名、hint system一直对接不上、多次请求会崩溃等。开发的时候就有一些心理准备，不过由于条件竞争或者逻辑判断没做好出现的一些小问题确实是在对接的时候才逐一发现的。 -
代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
没有做太多的code review，主要是出了bug之后负责联调的同学来review代码找找错在哪里。
测试/发布
-
团队是否有一个测试计划？为什么没有？
有测试计划、在联调之前大家都有做过基本测试。 -
是否进行了正式的验收测试？
没有正式验收 -
团队是否有测试工具来帮助测试？
使用api测试工具postman -
团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
没有具体实施 -
在发布的过程中发现了哪些意外问题？
联调的时候发现了一些意外的bug，大家无法正常使用系统编造数据的时候就得疯狂查错。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
重来一遍的话我们会把代码写的更加清晰一点，解耦做得更好，code review做的更好。没有code review的代码确实容易出问题，而且整体联调的时候很难发现bug所在。
团队的角色，管理，合作
-
团队的每个角色是如何确定的，是不是人尽其才？
每个角色基本做到了人尽其才。大家做之前都没有django的开发经验， -
团队成员之间有互相帮助么？
-
当出现项目管理、合作方面的问题时，团队成员如何解决问题？
应该互相讨论，最终由leader决定。
总结:
你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
你觉得目前最需要改进的一个方面是什么?
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？
- 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？
代码管理的质量需要要求每一个开发者都遵守一些提前商量好的规范，并且在合作过程中及时更新约定，比如工程目录的安排、测试代码的规范等等。
代码复审除了代码原作者之外最好还是有其他开发者参与，这样可以避免一些理解上的误区以及个人不良习惯导致的错误，同时也可以互相监督代码的规范程度。
-
整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？
我们在Alpha阶段使用的Django框架其实并没有使用它的一些高级标准，架构也不够优雅，但是非常方便好用，如果使用它提供的模板可以使得架构更加清晰。重构的目的是在保持逻辑严谨的基础上让人能够更快速、更舒适的理解代码，衡量质量的提高主要可以通过文件个数、API个数、单个API函数长度等一些标准来衡量。 -
其它软件工具的应用，应该如何提高？
先阅读官方文档软件工具的使用还是在“做中学”才提高的快，并且不清楚的地方要及时查询文档或者询问熟悉软件的开发者。 -
项目管理有哪些具体的提高？
及时有效的scrum，代码的及时迭代也方便了交流。 -
项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？
还需要提高对用户答题状态、时间间隔的监测。我们对用户的每个Action都有存储记录，包括用户对问题的点击，根据他们的点击和答题次数记录就可以获得活跃用户。 -
项目文档的质量如何提高？
借助一些工具协同制作项目文档，比如hackmd等等非常好用。 -
对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书
-
对于软件工程的理论，规律有什么心得体会或不同意见？
