• Alpha 事后诸葛亮(团队)


    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.即使到了开发的后期,也欢迎改变需求,敏捷过程利用变化来为客户创造竞争优势。

  • 相关阅读:
    利用Hexo搭建个人博客-环境搭建篇
    Appium的安装-MAC平台
    alias指令:设置命令别名
    Android学习——第一个NDK程序
    Android学习——windows下搭建Cygwin环境
    Android学习——windows下搭建NDK_r9环境
    Win7&Ubuntu12.04 双系统引导问题
    Android学习第三天-签名常用命令
    Android学习第三天-打包常用命令
    Android学习第二天-android常用命令
  • 原文地址:https://www.cnblogs.com/starset/p/7861196.html
Copyright © 2020-2023  润新知