答辩博客

---

一、设想和目标

• 做这个项目的背景、意义是什么？要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

我们的产品解决的是食堂用户在食堂用餐的时候难以选择窗口以及选择窗口后没有喜欢的菜品的问题
对于典型用户和典型场景基本上有清晰的认识

• 项目达到目标了么（原计划的功能做到了几个？在原计划之上是否有所拓展)

并没有达到，只基本完成了用户端

---

二、计划

• 和alpha阶段相比，每天是否时间规划的更好?

时间规划上区别不是很大，甚至可能更差了

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

总体上定义了交付件，但是粒度划分不够细致

• 项目是否出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

意外上倒是没有什么特别的意外，因为原本工作量过大可能导致的项目无法完成已经是意料之内了

• 在计划中有没有留下缓冲时间，缓冲时间有作用么?

预留了三天的预留时间，一天用在在冲刺期间让部分组员跟上进度，两天用在项目最后进行加班，但是作用依然十分有限

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

计划上来说项目开始的时间比较晚，这个是因为一开始安排组员学习新技术的时间较晚导致的
如果重来一次，还是要让组员尽可能早的开始计划，缓冲时间还是要越多越好的
另外任务粒度应该进行更细致的划分

---

三、资源

• 有足够的资源（可以是时间、开发资源等）来完成各项任务么?

前后端几乎完全重启，大部分队员对于新技术并不熟悉
α阶段没有完成的部分给本阶段带来了过多压力
时间上基本是不够的

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

时间上来说安排的过于极限了，安排上几乎是没法完成的部分，相应的精度也比较低

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

测试上用了之前测试没有使用的技术所以实际上是比之前测试快了不少的，美工设计文案基本没有完成所以也就没有什么低估难度的说法了

• 变更的组员工作如何？如果未变更是否项目完成效率会更高？变更的组员学到了什么？对于可能的变更是否能制定应急计划?

新组员给我们的后端带来了非常大的改变，引入了新技术并且新组员代码完成的速度非常快，反而是我们向新组员学习也是挺奇妙的。

• 有没有感到某个成员做的事情可以让别人来做（更有效率）?有什么经验教训? 如果历史重来一遍, 你们会做什么改进?

---

四、设计/实现

• 项目是否经历重构？为什么需要重构？

项目基本完全重构，主要的原因是α冲刺中我们使用的技术过于老旧，有更合适的新技术可以使用

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

UML文档补充了一些我们之前遗漏的部分
后端的测试上一开始计划使用的是swagger，但是没有成功，最后还是使用postman

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

复审的工作进行的较为粗糙

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

设计上来说一开始还是野心太大希望能完成整个项目而忽视了部分组员的实际能力，导致一些任务分配的粒度过大，一开始如果就舍弃一部分功能的话也许能把力所能及的部分做得更好。

---

五、测试/发布

• 和alpha阶段相比，测试工作有提高吗？在哪些地方提高了？
  运用了更合适的测试工具
• 团队是否有一个测试计划？

原本计划是最后两天开始由部分组员开始测试到所有人进行测试，当然因为进度较慢没有执行

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

单元测试：JUNIT
接口测试：POSTMAN

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

没有这方面测试

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

没有发布计划

---

六、团队的角色，管理，合作

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

α阶段之后我们发现前端的工作量还是比较大的，所以我们分配变为了四人前端两人后端

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

沟通上比α阶段更好，遇到问题有互相帮助讨论解决方法

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

---

七、总结

• 组员们自我总结
  自我总结见冲刺博客
• 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?

定义级。我们对于产品质量的趋势偏差还很大

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

磨合阶段

---

八、提高软件工程的质量

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

由接口文档明确定义小组成员应该使用的接口
代码规范的审查上借助第三方工具
代码可能出现的漏洞上，小组成员之间互相审查代码