Alpha 事后诸葛亮（团队）

Posted 2020-10-15

Alpha 事后诸葛亮（团队）

标签（空格分隔）： 软工实践

---

设想和目标

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

acm队员个人训练中的所有需求以及简化管理层人员的管理，定义的很清楚,对典型用于和场景有清晰的描述。

2.我们达到目标了么?

除了 个人能力分布分析 部分的个人能力图做不了外,其他部分基本上都按时完成了,甚至提前完成,并且分析的时候发现做了部分Beta版本的内容，因为我们的开发时间其实是比较长的,从组队确立开始后,立刻就进行了相关学习,10月中旬就开始投入开发。

3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么?

有固定的用户群体,过了暑假集中集训的高峰期，使用的不多,和预期差不多。

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

如果是按最初的思维导图,功能太多,做不完，发现只能挑最核心与可行性高的做，原因有很多,比如:队伍人员的时间有很大的不均衡性,前期能参与开发的人员只有一半;前端人员只有一个;最了解项目的人没有时间管理项目,交接问题导致项目停滞了一段时间等。

做到现在，发现需求方面有一些变化,比如没有考虑到数据量相关方面的缺少，导致个人能力图做不了,而靠着数据为基础的组队方面的功能也相应的就停滞。

所以我们的aphla的需求分析还算是相对合理的,组队方面没有考虑在内，但是也分析了一些自己列了一些不是很需要的需求在内。

如果从来一遍，需求方面需要更加慎重的考虑。

计划

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

有

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

队内讨论解决，如果还有的话,保留意见,组长担责任。

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

按照aphla版本,最主要的功能都已经实现,没有做完的有两个原因:
1.没有数据支持 2.队内讨论后发现该需求实际上是伪需求

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

布置任务有详细的任务步骤,并且做了交付的规范说明

5.是否项目的整个过程都按照计划进行，项目出了什么意外？

没有完全按照计划进行,组长在aphla进行到一半的时候交接了统筹的任务;后台的任务结束的过早;

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

后台任务是领取制的,完成一个任务后,可以自由选择其中一个未完成的任务,所以时间上相对比较自由。不过根据个人时间安排,有要求每个人相应的任务量。

7.将来的计划会做什么修改？

由于Beta版本时间比较长,所以会从思维导图中选择可做的需求加入其中。

资源

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

没有足够的资源完成思维导图中的内容,但是完成当前的预期还是足够的

3.各项任务所需的时间和其他资源是如何估计的?

由组内有项目经验的人来评估时间和任务难度决定.

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

测试任务已经算在任务当中了,接口的任务中直接包含了测试文档的编写。
文案所需的时间低估了，花了很多时间。
美工设计?前端人员直接上。

变更管理

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

知道，小团队内消息传递比较及时

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

不了解这个

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

有问题找PM

设计/实现

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

接口由后台人员一同编写，写到一个阶段后,前端人员再开始根据原型设计来完成

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

可以的话找PM，不可以的话就自己想办法解决。

3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？

没有单元测试,接口的编写都是要求先编写流程图的,测试接口我们团队有用专门的测试工具Insomnia，并且编写相应的测试文档,测试文档很有用,后台和前端人员基本上不需要直接交互,看测试文档就知道作用了，流程图的话是给编写的人员理清思路的。

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

复审基本上是PM肉眼观察,因为有测试文档等经过测试可以用了,出错率比较低。

测试/发布

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

编写接口的人员直接进行相关测试与测试文档的编写。

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

没有,直接发布出来看使用效果

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

有,前面提到过,Insomnia。

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

实际使用一下看响应时间是不是在能接受的范围内。测试工具蛮有用的,如发现某些网页的爬取特别耗时,这个时候就选择缓存一下。

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

本地测试是没有问题的,但是放到服务器上就会出现了BUG,原因是:本地的数据库貌似可以不区分表名的大小写,但是服务器上是严格区分大小写的。

团队的角色，管理，合作

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

有相关经验的直接进行相关角色操作。
没有经验的再一起学习。

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

大部分都是新手上路，互相帮助是很常见的事情。

我感谢 _______<姓名>______对我的帮助， 因为某个具体的事情: _____________________。

总结:

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

第二个档次。可重复级

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

• 1.我们最优先要做的是通过尽早的、持续的交付有价值的软件来使客户满意

• 2.即使到了开发的后期，也欢迎改变需求，敏捷过程利用变化来为客户创造竞争优势。