事后诸葛亮分析报告

具体贡献如下表

设想和目标

Q:我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们的软件要解决的问题是广东工业大学物理实验计算过于繁琐，我们需要能提供一款无需安装简易上手，仅需键盘输入数字即可获取答案的软件。典型用户指的是刚做完物理实验，手握大量数据，急需一款领域专用计算器验证结果的用户，典型场景则是广工物理实验所用仪器精度太高，以致于计算变得非常困难。

Q:我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

原定的目标是完成广工物理实验常见的公式(如模拟法测绘静电场等)共计六个公式的计算。每个公式由专人负责追踪进度，并在规定时间内完成交付。

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

一年之计在于春。对于本次项目，我们最大的教训是对于最终呈现出来的效果并没有做一个统一的规划，导致前后端协调不便。如果可以重来，我们一定会先协商制作出一份路线纲要，对于前端的UI界面展示，代码规范，后端接口风格，计算程序实现本身进行统一规划，再根据目前已掌握技术栈，对各个模块进行进一步细化并派遣专人负责跟进。

计划

Q:是否有充足的时间来做计划?

有。

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

良好的沟通是开展工作的基础。对于原定计划的落实，每个同事都可能会有不同的理解。例如对于计算本身的技术实现而言，有同事认为直接用Int类型即可，但是也有同时认为用字符串接收数据才更能保证计算的安全性和稳健性。对此情形，我们经过不停的沟通，各自摆出令人信服的证据，最终让对方理解并能接纳自己的意见，同时也汲取对方的智慧来进一步完善自己的方案。在这个过程中，不仅沟通双方对于计划的落实有了更深入的理解，还加快了后续的开发进度。

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

有的。在项目落实过程中，对于计算程序本身也有许多不同的方案。一般认为C语言的运行速度极快，科学计算都应该使用C语言来作为底层代码。按照以上思路，自然而然想到了Java程序通过C语言代码的架构。但是由于项目部署于linux服务器，环境与windows截然不同。再加上Java程序本身通过JNA调用C语言代码需要额外开销，性能上甚至不如预热编译后的java代码本身。最终放弃了C语言计算结果的方式，转而使用Java来实现。

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

知己知彼才能百战不殆。我们会直接复习Java基础，并全程使用java代码一遍打通前后端，不去研究python，C语言等在linux环境下的运行

资源

Q: 我们有足够的资源来完成各项任务么?

人才是最重要的资源。对于各项任务，我们有专业的团队成员来确保任务的落实。对于前端界面的搭建，我们有精通vue框架和element-plus样式框架的前端人才。对于后端服务器程序开发，我们有擅长spring框架的后端。对于物理公式计算，我们有精通各种公式的物理领域大神。对于计算公式实现，我们团队成员均能胜任公式的落实。对于服务器，我们斥巨资拿下一台1c2g服务器...

Q:各项任务所需的时间和其他资源是如何估计的，精度如何?

冰冻三尺，非一日之寒。我们基于已有的开发经验，对于各项任务进行合理的评估。对于前端页面展示，我们基于已完成果的作品，可以复用原有的代码并将其迁移至物理公式计算所需的平台。后端和计算同理。对于精度的把控，我们将主体部分划分成三个模块，每个模块均列出对应实现的功能，每个功能的实现均有专人负责追踪

Q:测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

站的更高，才能看得更远。测试时间，人力和软硬件资源是足够的。对于不需要编程的资源并无低估其难度，对于美术这一块，更重要的是前端开发的发挥。在这个领域，已有前人贡献了无数智慧的开源共享库element-plus UI框架。我们基于以上框架，以最短的开发时间，获取了最大程度的UI展示效果和渲染性能。

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

一定优先确认技术选型，不在技术选型上纠结太多时间。服务器晚点买，等需要展示时再购买，节约开发成本

变更管理

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

信息不准，生意亏本。每个团队成员都加入了独属于我们团队的微信群。再群里，若有紧迫性要求非常高的消息则直接一对一传达至该成员手上。对于紧急性要求并不算高的消息，我们有专门的代码仓库，在上面可以根据代码的不同问题提出相对于的issues，并派遣专人负责维护该issue并持续追踪该issue的解决。

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

物以类聚，人以群分。对于部分功能的开发，我们也确定了一套完整的分级制度。最高优先级的一定是保证网络环境畅通，在极端网络环境下，即便UI加载不出来，也要保证用户能获取到最基本的数据，哪怕以字符串的形式展示。至于可以推迟的功能，则是属于UI样式错位，计算程序精度不足等问题可以稍微延迟。

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

水无常形，兵无常势。基于以上确定的分级制度，对于可能的更改，我们会优先评估可能造成的破坏性和波及范围，再决定是否全面铺开。在最紧急的情况下，可以直接无视分级制度直接追加更新，但是需要有专人负责跟进进度

设计/实现

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

是在项目创建之初，由队长负责推进。

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

一失足成千古恨。后端接口设计上bug最多，原本是希望通过设计不同的接口去调用不同的计算程序以算出不同的答案，后期发现可以使用一个统一的url，通过不同的参数来决定调用的公式。在一开始，由于公式数量众多，很自然的联想到一个接口对应一个公式，但是后期发现维护成本过大，不利于后期的可拓展维护，故而改为统一url前缀的入参方式

测试/发布

Q:是否进行了正式的验收测试？

是的，对每一个模块和功能的实现都做了专门的测试。

Q:团队是否有测试工具来帮助测试？

好刀要用在刀刃上。对于基础的web项目开发，本团队已为项目开发配备齐全的开发环境和测试工具，诸如IDE，接口调试工具均有现成轮子可用。

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

linux环境与windows不同，且由于开启后台运行，每次查看日志需查找相关进程号并附加，对于测试运维压力较大，后期改用docker一键部署

总结

Q:代码质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

可以为专业的开发环境配置插件，以保证开发人员可以遵循良好的代码规范。

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

应多使用常见的代码编辑器，如vscode或IDEA等，以及熟悉掌握一批相关的运维测试工具

 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
  你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
  你觉得团队在这个里程碑相比前一个里程碑有什么改进? 
  你觉得目前最需要改进的一个方面是什么?

Q:你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

达到了CMMI二级——管理级的程度。我们团队遵守了既定的计划和流程，有资源准备，权责到人。但是还没有一套完整的管理措施，没有制度化。

Q:你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?

我认为到了规范阶段。我们团队成员们就很多事情取得了一致。角色和职责定义得非常清楚。团队还进行过有趣的团队建(shua)设(ye)活动。