当前位置 博文首页 > aisi3613的博客:团队事后分析

    aisi3613的博客:团队事后分析

    作者:[db:作者] 时间:2021-09-19 16:20

    设想和目标

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

    Gamma阶段原计划的密码找回功能,排名功能,移动端的适配功能等均做到了,按照时间交付了,原计划的目标用户200已经达到,目前Django后台记录的数目为243个用户。

    和上一个阶段相比,团队软件工程的质量提高了么? 在什么地方有提高,具体提高了多少,如何衡量的?

    整个团队的软件工程质量提高了,我们有WIKI来保存所有的完整文档,所有的文件均有完整的注释,并且通过Code Review,测试保证等方式确保了代码质量。

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

    这个阶段我们确定了任务的优先级,改进了燃烬图,加了任务总量这条曲线,PM能更好地把控任务进度。因为家庭的原因,PM有段时间未在学校,如果重来一遍的话,PM应该会更加注重进度的把控,随时push团队成员。

    计划

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

    我们在每个阶段的末尾都会提前讨论下一阶段的任务,在阶段的开始又会再次确定好阶段任务,因此是有充足的时间来确定计划的。

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

    我们都是当面讨论,讨论任务的可行性和复杂性,针对大家提出的考虑来判断是否要做这个任务。

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

    都做完了,只是部分任务的完成度没有太高,因为时间还是有一定的不足。

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

    前端的分页功能,实现起来太过于复杂,总是出问题,其实现在觉得让后端分页更简单。

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

    有。每个任务都确定了优先级以及相关人员。

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

    基本按照计划进行。安全性问题在Alpha初期没有考虑到,准备添加在Beta阶段任务中,但是在Alpha阶段末尾网站突然被攻击,因而采取了一定的紧急措施,恢复了网站的正常功能,避免了再次被攻击。

    在计划中有没有留下缓冲区,缓冲区有作用么?

    留下了一定的缓冲区。任务执行时出现突发情况时,缓冲区就能够避免任务总体进度出问题。

    资源

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

    完成所有基本功能的资源足够,但是在完成一些比较麻烦的功能例如移动端适配的时候,时间不太足够因而不太完美。

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

    主要是由开发和测试人员依据Alpha,beta的经验来估计,精度比较准确。

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

    资源足够,对移动端的适配低估了难度。

    变更管理

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

    我们组变更管理部分做的比较好,我们主要通过微信群进行交流,因此项目任务有变更时团队成员很快就能获知。

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

    我们使用了自己设计的燃尽图,其中有一项是当前任务总数,PM能抓住重点,及时判断任务能否完成,进而将下一阶段的任务提前或者砍掉某个任务。当某阶段任务稳定并且全部完成后,就达到了该阶段的出口条件。

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

    我们有一定的应急计划,比如我们在网站受到攻击时,应急修复,在1.5小时就让网站成功重新上线,尽可能减少了用户的损失。团队对于这类意料之外的任务处理起来也比较顺利,队员能主动认领,有效处理。

    设计/实现

    设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?

    后端的设计工作是在后端的线上会议的时候敲定的。设计由后端的两位同学,结合项目具体情况,共同拟定。前端的设计工作是由UI和前端开发成员你一起决定的。

    设计工作有没有碰到模棱两可的情况,团队是如何解决的?

    在设计中,我们遇到了这样的情况。比如,原项目中,并没有采取前后端分离的设计方式,而是由后端全部完成,返回html给前端。我们在发现了这个设计之后,经过讨论,觉得不符合我们的项目设计。决定更改整体的设计。

    代码复审(Code Review)是如何进行的,是否严格执行了代码规范?

    后端的代码复审,通常是一位后端的开发在完成了自己的任务后,通过issue或者即使通讯软件的形式,联系另一位后端开发同学,通知他开发已经完成。再交付测试同学之前,另一开发同学需要阅读实现了的代码,结合已经拟定好的后端接口文档,以及代码的规范要求,对于代码的功能已经标准性进行复查。如果遇到不合规范的情况,会在issue以及即时通讯工具中提醒,要求开发人员进行更改。

    测试/发布

    团队是否有一个测试计划?为什么没有?

    团队有完整的测试计划。也有测试工具,并且进行了验收

    Gamma测试工作反思

    没有考虑到测试样例执行速度的问题,虽然是放着跑一下就完事了,但会占着那么久电脑,而且每次跑都要跑那么久确实是个问题。
    测试样例的管理问题,虽然我当初的理想是使用tag进行管理。但事实上对上百个样例使用tag来进行管理真的是个折磨。一套更方便的管理系统可能更好,这有助于在测试样例执行速度无法提升的情况下选择性地进行测试。
    对需求变更的即时响应问题,虽然我使用了page object方便了同类测试样例的批发式编写,但问题是当page本身发生变更时,我的即时响应方面,虽然工作量不大,但存在较高的抽象复杂度。因为我和前端那边对页面的抽象方式不同,所以每次他们修改我都要想想怎么适配成我这边的逻辑。手工工作量是减少了,但思维工作量增加了。

    总结

    团队目前的磨合非常不错,处于“创造”阶段。整个Gamma阶段,在PM因特别原因的缺席下,也能不延期地完成所有任务。同时团队成员也注重了软件工程的质量等,对安全性测试,兼容性测试,以及使用自动化测试工具等都非常熟练,相比起Alpha阶段和Beta阶段来说,我们组已经成为一个相对“成熟”的软件工程团队~
    1632489-20190624221142835-435213859.jpg

    cs