Visual Lab Online —— 事后分析

项目	内容
班级：北航2020春软件工程	博客园班级博客
作业：事后分析	事后分析

设想和目标

1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
   • 我们的软件使得编写简单的代码工程变得更加方便，用户无需安装复杂的开发环境，拥有一个浏览器和流畅的网络环境就可以编写运行代码，甚至可以在移动端（iPad）编写代码
   • 定义清楚
   • 典型用户：学生，码农新手
   • 典型场景：编写小型工程时，例如算法作业，学科大作业
2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)
   • 我们的基本目标基本已经达到了，原计划的语言支持功能（包括自动补全，查看定义，代码纠错等），编译运行功能已经完成，并且支持了cpp和python语言
   • 按照原计划时间交付了（4.29）
   • 原计划的用户数量没有达到
3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
   • 用户量比预期计划的少一些
   • 用户对重要功能的接受程度和我们事先的预想比较一致，给予反馈的用户中大多数表示我们的产品功能比较完善，是一个比较好用的工具，也有细心的用户发现了我们在设计过程中的不足，这些是仍然需要改进的地方

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

• 重来的话，会在产品的定位和受众上做进一步调研和分析，进一步明确产品的最终目标，进一步细化产品需要交付的功能
• 理想的用户量目标和现实的有限服务器资源存在冲突。重来的话，会在指定目标时考虑资源有限的情况，制定更切合实际的用户量目标

计划

1. 是否有充足的时间来做计划?

   有足够的时间进行计划。小组讨论了很长时间来决定产品要实现哪些功能，并给不同功能的实现划分到了不同的阶段。

2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

   对于不同的意见，首先是一起讨论后进行投票决定；若不同意见分歧比较大，会让大家去做好调研工作后开一次研讨会，再进行一次深入讨论投票。

3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

   • 前端部分原计划的工作基本完成了，有个别bug没有修复，原因是技术栈尚不明确，而且这些bug没有影响产品主要功能，主要是一些用户体验上的bug。
   • 后端部分的工作基本完成

4. 有没有发现你做了一些事后看来没必要或没多大价值的事?

   • 前端一开始花费了大量时间调整iview组件的css样式，但是在最后很多样式都被推翻重来了。
   • sxd同学开发时曾遇到一个同步问题，查阅相关资料4个小时都没有找到解决方案，后来与队友交流后30分钟就找到了解决方案。

5. 是否每一项任务都有清楚定义和衡量的交付件?

   几乎每个任务都有清楚的定义和衡量的交付件。涉及到自己的部分和其他人负责的部分交互的时候，就需要清楚定义每个部分实现的功能以及传递的信息，需要做到封装完善，没有bug 才会交付。

   前后端有相应的接口文档，在接口交付前端前会根据接口文档定义的各项功能以及错误码进行单元测试，例如前后端Terminal在交付前，会将前端Terminal封装成一个组件，定义好使用文档，交付前端使用。

6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

   网页UI设计在项目第一阶段遗留了一些小问题，这些问题影响了后面开发阶段的正常推进。因为大家对于前端编程并不熟悉，是在边学习边实现的基础上进行的，团队内部也没有一个精通前端框架的人，都是在自己进行摸索实现的。

   网站安全方面目前仍无法保证项目100%或99%的安全，不能支持过大的并发量。这是因为设备配置方面最初没有考虑到实际设备条件的问题。

7. 在计划中有没有留下缓冲区，缓冲区有作用么?

   • 计划初期有缓冲区，对于每一个阶段安排了最后一天进行上机对接测试
   • 在整个项目完成后，安排了3天时间进行对接测试
   • 前期缓冲区作用：提前做好对接工作，不至于后续对接时手忙脚乱
   • 后期缓冲区作用：提前部署，做好测试准备

8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

   • 可能会安排多一点缓冲区时间：
     • 一方面可以解决前期留下的bug，不至于后期一直在修bug
     • 一方面可以提前做好对接，提前处理一些繁琐事项
   • 前后端持续集成、持续部署

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 要及时根据实际进度调整计划，在我们这次工作中，计划的设置有些不合理，当大家认识到这一点后，调整不够及时，仍然按部就班的工作，导致对整体工作进行到哪个阶段缺少了十足的把握。计划赶不上变化，历史如果重来，要及时根据进度来调整计划，不断完善计划。
• 对任务的拆解应该更加细化，任务分配给每个成员时充分考虑每个成员擅长的领域，从而提高开发效率。

资源

1. 我们有足够的资源来完成各项任务么?
   • 学习资源：基本足够，有官方文档，官方教程，官方论坛辅助debug
   • 硬件资源：学校提供的服务器资源是不够的，氪金后勉强上可以满足用户的实际需求。
2. 各项任务所需的时间和其他资源是如何估计的，精度如何?
   • 各项任务所需时间分为调研时间，实现时间，测试时间：
     • 调研时间会根据任务的难度（技术难度）进行估计
     • 实现时间根据任务量进行估计（代码量，功能量）
     • 测试时间会根据任务复杂度进行估计（模块松耦合，功能量）
     • 这些估计均是与基准任务进行比对的，基准任务为个人项目的完成时间
   • 其他资源估计：
     • 服务器资源估计：预估用户量和容器大小进行估计，包括内存估计，硬盘容量估计
   • 精度：对于任务时间估计基本准确，偏差在1-2h之间；对于服务器资源估计，由于实际用户量与预估存在一定偏差，因此准确度并不高。
3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
   • 测试基本是在边开发边进行测试，对于最终项目的汇总测试时间比较局促。
   • 测试人力资源不够，硬件资源严重欠缺。
   • 文案设计欠缺考虑。
4. 你有没有感到你做的事情可以让别人来做（更有效率）?
   • 后端人员认为自己做效率更高。
   • 前端人员认为某些难度较大的工作如果能交由他人完成会更有效率，例如文件树的实现。

有什么经验教训? 如果历史重来一遍, 我们会做什么改进?

• 在产品设计时，不仅要考虑功能和时间成本，也要考虑硬件成本，有时不能够全靠硬件成本换时间成本。如果重来的话，会在硬件成本上做考量，设计应该会有所改变。

变更管理

1. 每个相关的员工都及时知道了变更的消息?

   模块的变更都是先在模块设计组内部通知，在模块变更完成，测试稳定后再通知外部组人员进行使用，变更通知基本及时，并且在变更后一些需要一起变更的模块能够及时作出调整。

2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?

   根据软件的完整度，稳定性，以及组内人员的完成效率，综合考虑功能上线时间：

   • 不影响用户体验，或者对用户体验提升较小并且实现有一定技术难度的功能可以推迟。
   • 软件的核心功能，与用户体验息息相关的功能必须实现。

3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?

   出口条件一般需要满足以下几个必要条件：

   • 基本功能完善，基本功能没有bug
     • 对于我们项目而言，基本功能即是：
       • 用户基本管理：登录，注册，修改密码，项目新建，改名，删除
       • 项目语言支持：支持了cpp和python两种常用语言
       • 语言功能：自动补全，语言高亮，语法检错
       • 最最必要的功能：编译运行
       • 项目管理功能：文件管理：新建删除改名，移动
   • 界面美观简洁，基本操作流程中没有特别大的bug
     • 对于我们的项目而言，要求就是：
       • 对于每一个页面，其内部组件排版整齐
       • 每个按钮组件按下去都有相应的功能展现，并且常规操作不会触发bug
       • 对于非常规操作，不会触发特别大的破坏系统的bug
       • 页面之间衔接跳转合理，支持刷新，后退，关闭，并且这些操作不会破坏系统以及用户体验
   • 系统安全能够基本满足，用户不能触发破坏系统的bug
     • 对于我们的项目：
       • 后端docker服务器开启TLS验证，设置白名单，防止外部入侵
       • 后端front-server服务器开启TLS验证，防止数据窃听
       • 后端开启防火墙，对于频繁的请求进行一定的拦截

4. 对于可能的变更是否能制定应急计划?

   对于我们的项目，由于基本上模块间联系比较紧凑，在进行变更时能够一起进行变更，因此暂时不需要制定应急计划。

5. 员工是否能够有效地处理意料之外的工作请求？

   可以。组内成员很注重代码规范和代码可扩展性，例如当PM提出了新的需求后，可以迅速地定位到相关模块进行功能拓展。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 重来的话，项目变更前通知每位成员后，再评估变更的成本和风险以及变更的必要性来决定是否变更。

设计/实现

1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

   • 设计阶段在所有工作之前，即项目初期完成，由PM组织完成。
   • 是合适的时间，合适的人。

2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

   有。先以大模块来规划时间安排，对于具体程序设计交给完成该模块的小组单独安排时间讨论。

3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

   • 对于接口api，使用了easydoc文档规范接口的规范和功能
   • 对于其他模块的文档，接口文档定义在各自仓库的README.md中
   • 后端服务器有采用单元测试方式进行测试
   • 在设计之初，有使用draw.io划分各个模块

4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

   • 前端部分bug最多，主要是文件树这一块，因为这一块团队的成员均缺乏开发经验。
   • 发布后发现了前端展示存在一定bug，以及新建文件存在bug。因为开发人员把重点放在了编程上，对用户的使用习惯不是特别了解，另外没有意识到用户各种操作的顺序可能产生的bug。

5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

   • 同一开发小组内几个组内成员，在其中一个组成员完成模块代码后，其他成员会对该成员代码进行审查。
   • 前端使用ESLint规范。

我们学到了什么? 如果历史重来一遍, 我们会做什么改进?

• 对于逻辑复杂的部分，队伍中的其他人应及时与之交流，避免其陷入困境。这次负责文件树的同学就有点势单力薄的感觉，应加强沟通。
• 更加注重代码测试，bug不仅存在于代码运行错误中，更多的是用户体验的bug，这一块开发人员也应该更加重视。

测试/发布

1. 团队是否有一个测试计划？为什么没有？

   对于场景测试，有一定的测试计划，详见测试博客Alpha阶段测试报告。

2. 是否进行了正式的验收测试？

   对各个使用场景，进行了验收测试。

3. 团队是否有测试工具来帮助测试？

   后端借助Junit、istanbul、mocha进行测试。

   前端使用jest进行了单元测试。

4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

   前端大部分测试工作是通过dev版在本地运行测试，这些测试工作很直观反映了前端代码的一些bug，所见即所得。

   后端是借助java单元测试工具来进行测试。

   这些工作都很有效，在开发的同时进行测试，节省了最后测试阶段的工作量。

5. 在发布的过程中发现了哪些意外问题？

   前端项目部署后域名访问有问题，只能用ip访问。

我们学到了什么? 如果重来一遍, 我们会做什么改进?

• 选择合适自动化的测试工具十分重要，这部分也应该纳入最初的技术调研之中。如果重来，在最初技术选型的时候同时考虑测试相关的问题，如技术是否利于测试、是否有较好的测试方法。

团队的角色，管理，合作

1. 团队的每个角色是如何确定的，是不是人尽其才？

   根据每个成员掌握的技能和擅长的领域进行任务选择和调配，基本上做到了人尽其才。

2. 团队成员之间有互相帮助么？

   有，大家经常相互讨论，共同克服遇到的问题。如前端成员之间有时候会相互检查、给对方的bug提出解决思路。

3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

   积极沟通，例如前端开发在对后端定义接口有疑问时，会及时沟通从而确保高效敏捷地开发。

感谢信

成员	感谢信
向WL	我感谢 李PX 对我的帮助， 因为某个具体的事情: 耐心听我小黄鸭debug法 我感谢 韩WZ 对我的帮助， 因为某个具体的事情: 跟着我更新docker镜像，擦了准备不周的屁股 我感谢 孙XD 对我的帮助， 因为某个具体的事情: 帮我搞定编辑器与前端对接
李PX	我感谢 孙XD对我的帮助， 因为某个具体的事情: 对接时候和我一起深入交流，探讨解决方案。 我感谢 韩WZ对我的帮助， 因为某个具体的事情: 后端的主要负责人，教会了我各种后端框架。 我感谢 向WL对我的帮助， 因为某个具体的事情: 帮我找到了文件系统的bug
韩WZ	我感谢 李PX对我的帮助， 因为某个具体的事情: 和我一起探讨技术难题、寻找解决方案。 我感谢 向WL对我的帮助， 因为某个具体的事情: 能够提出一些不错的想法，能够从他身上学到一个researcher的思维方式。
孙XD	我感谢 李PX 对我的帮助， 因为某个具体的事情: 在IDE界面与terminal进行合并时给与细致的指导。 我感谢 向WL 对我的帮助， 因为某个具体的事情: 在IDE界面与editor进行合并时共同讨论解决方案，并指出需要改动的地方。 我感谢 韩FJ 对我的帮助， 因为某个具体的事情: 和我一起完成前端IDE界面的很多工作，并在遇到困难时给出帮助。 我感谢 韩WZ 对我的帮助， 因为某个具体的事情: 在前端对后端提出需求时耐心讨论并给予帮助。 我感谢 万ZF 对我的帮助， 因为某个具体的事情: 在完成home界面的设计后，共同协助我们完成ide界面的设计。
韩FJ	我感谢 李PX 对我的帮助， 因为某个具体的事情: 为前端提供清晰的接口文档；在了解前端的功能需求后高效地添加新接口 我感谢 万ZF 对我的帮助， 因为某个具体的事情: 高效完成home界面，为我的编码提供了很好地参考 我感谢 孙XD 对我的帮助， 因为某个具体的事情: 一起协作完成了IDE界面，共同解决了非常多的问题。 我感谢 向WL 对我的帮助， 因为某个具体的事情: push效果显著，提高工作效率。
万ZF	我感谢 李PX 对我的帮助， 因为某个具体的事情: 调研了前端组件库，使前端开发难度降低了不少，并给我解读了前后端接口的含义及使用方法。 我感谢 孙XD 对我的帮助， 因为某个具体的事情: 一起协作完成了菜单栏部分。 我感谢 韩FJ 对我的帮助， 因为某个具体的事情: 一起协作完成了菜单栏部分。

总结

• 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
  
  目前属于CMMI二级，管理级
• 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
  
  磨合阶段之后，规范阶段之前
• 你觉得目前最需要改进的一个方面是什么?
  
  团队可以更加活跃一些。

对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。

• 可用的软件是衡量进度的主要指标
  • 我们的alpha阶段的目标就是交付一个可用的软件，实现一个具有大部分功能的线上IDE。一切计划和任务拆解都是围绕这个大目标展开的，遵循了可用第一的原则。
• 要做到简洁，尽可能减少不必要的工作，这是一门艺术
  • 每个任务严格交付给个人完成，所以几乎没有重复的不必要的工作。
• 团队要定期反省如何能够做到更有效，并相应调整团队的行为
  • 项目后期有的成员提前完成了自己的任务，所以后期及时调整了任务分配，提高了项目进展速度。

团队在下一阶段应该改进的地方

1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

   可能会使用github的PR功能，进一步规范代码签入记录。

2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

   在beta阶段，后端可能会更改现有架构，支持更高的并发量和支持更多用户的使用。

   前端会继续使用vue框架。

   通过对代码模块进一步解耦、模块进一步细分来提高代码质量，代码的拓展性可以衡量质量的提高。

3. 其它软件工具的应用，应该如何提高？

   目前的软件工具能满足开发的需求，暂时没有发现需要提高的地方。

4. 项目管理有哪些具体的提高？

   git的commit信息可以进一步规范，要尽量体现出修改的具体内容。

   issue应该更加细化，最好可以对应到某个commit记录

5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

   目前是通过管理数据库的用户信息、登录服务器查看访问量来知道每日/周活跃用户等数据。计划对用户登录信息进行去重处理，获得更准确的数据。

6. 项目文档的质量如何提高？

   团队内进一步约束文档撰写规范，保证文档的使用者能很清楚的明确含义。

7. 对于人的领导和管理， 有什么具体可以改进的地方？

   • 任务进度与计划不一致时（如某人提前做完了计划任务），分工应当有一定调整（如提前做完的同学去帮助进度落后的同学）

   • 分工相同的同学（如前端页面的三位同学）效率有待提高，避免沟通不及时 / 陷入等待 / 多人同时做一件事 导致时间浪费

8. 对于软件工程的理论，规律有什么心得体会或不同意见？

   • 软件的质量 = 程序的质量 + 软件工程的质量，软件工程的质量和程序的质量同等重要。
   • 通过alpha阶段的实践可以感受到，遵循敏捷开发的12条准则，对项目的质量和管理有很大的帮助

附：全组讨论截图