首页 > 其他分享 >希望能做队——团队事后诸葛亮会议

希望能做队——团队事后诸葛亮会议

时间:2023-05-23 23:44:51浏览次数:31  
标签:事后诸葛亮 是否 做队 时间 计划 测试 团队 我们

时间:2023-5-23 20:00

地点:九栋

参会人员:希望能做队全体成员

图片:

设想和目标

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

  人脸识别签到的总体流程;足够清楚;有一些描述,但老师认为我们的场景太过于简单。

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

  是的,有时间做计划,但是项目的具体实现非常耗时。

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

  我们共同商量,最终达成一致。

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

我们会更加完善我们的人脸识别签到系统,更好地适用于场景模式。

计划:

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

  原计划的工作只完成了一部分,没做完的部分,是因为没时间。

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

  有的,比如我们的数据库太过复杂,不够简便。

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

  是的。

是否项目的整个过程都按照计划进行?

  差不多,但有的时候团队的人都想歇一歇。

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

  没有

将来的计划会做什么修改?(例如:缓冲区的定义,加班)
  预留必要的缓冲时间。

资源:

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

  资源(书籍,开源解决方案,服务器,素材)非常充足

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

  大体以14天为周期,估计每天的工作量,精度差别不大。

用户测试的时间,人力和软件/硬件资源是否足够?

  我们的测试都在最后,非常的不容易。

你有没有感到你做的事情可以让别人来做(更有效率)?

  没有。

变更管理:

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

  是的。

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

  根据功能在整个项目中的重要程度。

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

  无。

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

  没有。

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

  可以,我们都能接受意外,但是未必能完成完美这些新问题。

设计/实现:

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

  前三天,由我们团队共同完成。是合适时间和人。

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

      对于一些界面的设计;我们共同商量,决定最终方案。

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

  并没有,我们的项目比较简单,所以只需要照着场景流程去测试就可以了。

什么功能产生的Bug最多,为什么?

  界面适配,因为很多东西我们都不太会。

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

  并没有。 

测试/发布:

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

  团队有明确的测试计划。

是否进行了正式的验收测试?

  有。

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

  无。

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

  我们并不了解效能测试,但是会在二阶段考虑。

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

  域名的部署有些问题。

1.1 简单----使未完成的工作最大化的艺术----是根本的

我们在开发过程中,始终遵循MVC的开发模式,大家各自编码,整合起来也比较容易。

1.2 敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度

我们在整个Sprint阶段,坚持每天拿出2h+的时间coding,良好的进度使得我们的工作能够按部就班地进行下去。虽然平时的作业也很多,但我们基本能够把边边角角的时间放到Coding上,这样总的时间投入不会与其他课程冲突。

1.3 不断地关注优秀的技能和好的设计会增强敏捷能力

我们在项目开发过程中,使用了MVC等设计模式,这使得我们能够把精力集中在满足用户需求之上。

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

在最后的整合阶段,出现了许多问题,也能近似解决。

2. 什么是在下个阶段要改进的地方? 

我们将发布服务器版本,使得各地方得用户都可以访问我们的系统。

标签:事后诸葛亮,是否,做队,时间,计划,测试,团队,我们
From: https://www.cnblogs.com/XWNZD/p/17425027.html

相关文章

  • 事后诸葛亮会议
    设想和目标1.我们的软件意在解决市面上的语音转文字收费问题,希望为用户提供一个能够随时随地生成自己想要的语音的文本文件,方便用户进行记录和总结我自我感觉我们起初的开发方向不够明确,只是想着做语音转写,之后在老师的点拨下才明确了具体的用户场景和使用方向,特别是在二阶段我......
  • 科技云报道荣膺全球云计算大会“云鼎奖”2020-2021年度优秀团队
    2021年6月16日-18日,第九届全球云计算大会·中国站(CloudConnectChina)在宁波隆重举行。本次大会上,科技云报道荣膺全球云计算大会“云鼎奖”2020-2021年度优秀团队奖项。科技云报道团队代表上台领奖(左一)科技云报道荣膺“云鼎奖”2020-2021年度优秀团队作为每年全球云计算大会·中国......
  • 技术团队要小心,那些技术过早优化的迹象
    hi,我是熵减,见字如面。在软件行业内,有一句关于技术实用性的名言:“过早优化是万恶之源。”在局部代码层面上的追求先进,是无可厚非的事情。但是,在一些小公司中,技术过早优化的现象又是很常见的。当小公司为了追求技术的先进性和高效性,往往会采用一些不适合自己的技术方案,导致开发成......
  • 团队项目 阶段2 3
    我们团队修不了一些项目的不足。if(dao.getStatus(id).equals("0")){ out.print("<scriptlanguage='javaScript'>alert('学号不能重复');</script>"); response.setHeader("refresh","0;url=index.jsp"); }发博客:增加了学......
  • Deferred Components-实现Flutter运行时动态下发Dart代码 | 京东云技术团队
    导读DeferredComponents,官方实现的Flutter代码动态下发的方案。本文主要介绍官方方案的实现细节,探索在国内环境下使用DeferredComponents,并且实现了最小验证demo。读罢本文,你就可以实现Dart文件级别代码的动态下发。一、引言DeferredComponents是Flutter2.2推出的功能,依赖于......
  • 团队开发第二阶段10
    现在是我们团队开发阶段的最后一天,我们已经完成了昨天代码bug的最终修改,首先我们面向了班级内部同学,进行了初步的效果展示,通过收集大家的意见我们略微改动了UI界面,保证了UI界面的美观与合理。接下来就要面对用户的考核,将软件分享给其他院系同学。基本任务已经完成,现在已经将软件打......
  • 彻底理解EF Core(5)的运行机制,万字长文带你成长为团队中的EF Core专家
    彻底理解EFCore的运行机制,万字长文带你成长为团队中的EFCore专家1、将EF的ToTraceString移植为EFCore的ToQueryString2、从EFCore记录详细信息2.1、简单的日志记录2.2、响应EFCore事件2.3、使用事件计数器访问指标3、拦截EFCore的数据——拦截器4、查询拦截5、EFCore5中......
  • 通过团队协作,搭建WEB软件产品
    需求分析用例图现实设计图代码构件图代码信息流物理部署图后端代码编写表结构设计范式:列的原子性范氏:列要保持和主键强关联范氏:列之间没有关联dto路径约定业务entity类编写Model代表现实世界的抽象Schema使用了某种方式呈现ModelEntity代......
  • :ArmSoM研发团队联合Banana pi开源社区基于Rockchip RK3588 soc发布了ArmSoM W3 单板计
    ArmSoM推出的W3rk3588单板计算机采用核心板+底板设计方式,核心板采用LGA封装方式,核心板尺寸仅45mm50mm4.1mm,且RK3588SOC所有Pin脚对外引出。ArmSoMW3单板计算机接口示意图如下:[email protected][email protected],8nmGPUA......
  • 如何进行测试分析与设计-HTSM启发式测试策略模型 | 京东云技术团队
    测试,没有分析与设计就失去了灵魂;测试人员在编写用例之前,该如何进行测试分析与设计呢?上次在《测试的底层逻辑》中讲到了【输入输出测试模型】,还讲到了【2W+1H测试分析法】,但2W1H分析法是初步的分析方法,具体在测试中如何落地,还需要更细的设计。今天就给大家介绍一下由测试领域专家......