• M2事后总结


    照片

     

     

    设想和目标

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

    "北航"Clubs旨在于解决北航校内社团管理与学生参与社团活动的困难的问题,通过构建一个校内社团发布活动or资讯的平台,使学生可以通过网站获取社团活动信息,使社团可以通过后台管理活动,群发通知。

    典型用户和典型场景在之前的Alpha阶段产品功能说明书以及Beta阶段开发目标中有说明;但典型场景的分析在beta阶段做的不太详细。

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

    有,在M1之前就已经完成了很大一部分的项目产品设计、项目计划与项目设计。而因为种种因素,M1未能实现当时的全部计划,所以有很多留在M2继续完成。而在M2开始之前,PM也已经根据实际进度、时间以及最新的需求做好了规划。

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

    M1计划阶段不同,随着项目的深入,成员们对项目需求的了解也不断加深,逐渐有了自己的对项目规划的看法。所以在M2的设计中,PM与成员间的沟通讨论更加多,很多计划都是共同制定出来的。

    相对于M1的改进

    M1的设想和目标有些太过笼统,而且忽视了时间因素;

    M2中的设想目标更加切合实际,也更加灵活

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

    对新阶段的典型场景重新进行细致分析

       

       

    计划

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

    用户以及社团的修改头像、修改密码这两项功能未实现。

    未完成主要是因为开发时间过于紧张,外加这两项功能并不是核心需求,所以就选择了舍弃。

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

    有。

    后端:一开始计划用leancloud实现消息实时推送,所以初期花费了大量时间学习,还发布了一些文档。但中期经过商讨消息实时推送难度太大,同时不太适合PC端且完全可以由更简单的刷新界面操作代替,所以初期的学习leanclound显得十分多余、占用时间。

    前端:初期学习的react vue.js到开发阶段也并未用到,但占用了时间成本

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

    定义:所有任务都以TFS任务的形式规范。所有人都是根据实际进度情况实时创建任务、更改任务状态,以便让TFS任务直观真实体现当前成员工作量与进度

    衡量:要求每天在进行汇报时要有签入记录作为衡量当日工作量的依据,签入记录可以是代码签入或者文档签入

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

      前期较为顺利,后期则偏离计划较多。主要原因就是后期其他课程(数学建模、编译、数据库理论考试+实验课设)对软工开发时间的巨大挤压。其实一开始是考虑到这些风险的,但对风险的影响显然是估计不足的。在其他课程的冲击下,有一段时间,软工开发几乎处于停滞状态。

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

    因为预料到后期其他课程会占用大量时间,M2计划阶段预留了缓冲区。虽然仍然没能避免一些熬夜冲刺,但对整体项目的最终顺利完成还是有一些作用的。

    相对于M1的改进

    1. 对任务的定义和衡量有了更健全的机制
    2. 预留了缓冲区

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

    1. 将计划做的更加细致全面一些,减少无效任务的产生,避免做没有价值的事,让开发更加有效率
    2. 计划时考虑更多的外界干扰因素,综合规划

       

     

    设计/实现计划

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

      设计在M1结束后就开始进行,主题由PM江昊完成,但这次整个团队都参与讨论了计划的产生,并且在后期也通过每日例会一起不断调整。

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

         

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

          设计:团队借用E-R图来对后端Model层设计进行建模处理,有效的推动了后端数据库的建立与后端dev对项目的认识。

          实现:M2继续借用API文档来规范前后端接口,实现前后端交互。有效的降低了前后端工作的耦合性,提升了项目效率。

    继续沿用M1的单元测试

    同时,M2开始用GIT管理代码,开发效率提高,发生错误的几率也降低

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

          前端 社团后台界面。

          原因:界面元素较多,并且功能较复杂,前端技术细节本就难处理,所以实现时遇到了很多BUG和困难。

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

          很遗憾,同M1一样,因为时间原因,后端虽进行了代码复审,但并没有一套严格的流程,只是后端dev之间口头交流,粗略审查。

          代码规范方面初期执行的较好,后期因为进度原因不理想。 

    相对于M1的改进

    1. 计划的修改通过每日例会进行,更加灵活,更多人参与
    2. GIT管理代码
    3. 更加重视前端

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

    1. 规划好代码复审机制,开发时严格执行
    2. 测试可以应用更多的工具来提高效率,目前只是单元测试和fiddler

       

     

    资源

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

      M2最稀缺的就是时间资源,严重不足。 而其他资源则较为充足,而且比较M1来说,学习应用GIT提供的管理资源对我们的项目有很大的帮助。

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

      同M1一样做的不够理想,估计时间主要是通过PM来估计的,由于PM对一些技术细节以及外界因素了解得并不多,因此精度比较低。

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

      前端没有做专门测试,而后端花去了约三分之一的时间进行测试,人力、软件、硬件资源都足够。

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

    我们的分工比较明确,大家完成得都较好,不适宜更换任务。

    相对于M1的改进

    GIT的介入提升了效率

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

     1. 重视时间的估计,考虑多重因素的影响,综合规划整个项目。时间会影响到成败。

     2. 每周的开会更细致一点,对可能发生的意外情况提前进行预估。

       

     

    变更管理

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

    有了GIT,代码的更新可以直观的看到,能够及时知道变更的消息。

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

          M1一样,主要通过每日例会以及平时开发过程中成员与PM之间的面对面交流来决定。会根据我们项目的具体情况,选择处于当前核心需求的功能来进行实现;而对于那些无关紧要或者实现难度过于大的功能会考虑予以舍弃。

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

          我们本阶段的目标就是实现web端的社团综合管理平台,所以"做好了"的直接效果就是网页上各个功能以及排版都能够实现其应有的功能,这也是比较好测试的。页面整合后,能够通过各项的测试,这样就算是"做好了"

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

          应急计划就是面对时间紧缺的情况,回选择削减一些非核心需求的功能来紧急应对。

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

          有了M1的经验,M2每次出现意料之外的工作请求时,pm都会和dev商讨提出可行的解决方案。而且从结果来看,意料之外的工作的处理的情况还是不错的。

    相对于M1的改进

    GIT的介入避免了只能通过QQ传递代码的麻烦,而且可以处理代码版本冲突、版本变更等带来的代码管理风险

       

     

    测试/发布

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

    M1相同

      团队有明确的测试计划。后端的测试主要是编写单元测试,功能测试和压力测试。

      前端的测试主要是场景测试和在不同浏览器及不同环境下的测试。

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

      后端测试完成了单元测试和功能测试模块,也实施了压力测试。

      前端测试计划均已完成,并进行了验收。

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

      后端进行测试主要使用rails自带的单元测试模块,来编写单元测试和功能测试。

      利用Fiddler4这一工具,来测试相应的API逻辑,对传入的请求和返回的响应进行检查。

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

      效能测试之前我们并没有考虑,主要因为时间有限,所以只做了一些基础性的测试。向效能测试和负载测试会在Beta阶段进行,对于效能方面,  我们团队计划通过增加服务器的数量,将逻辑计算和数据交互分开进行,进而提高服务器的响应效能。对于负载方面,我们团队打算将数据库改用MySql实现,并且将后端rails框架改进为可以并行访问。

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

    相对于M1的改进

    1. 后端执行了压力测试

    2. 增强用户场景测试

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

      Fiddler难免有一些繁琐与麻烦,应该寻找一些更高效的测试工具

     

    补充问题:

    1. 对比敏捷的原则, 你觉得你们小组相对于M1做得最好的是什么
      1. 处理需求变化更加及时

        M1阶段在应对各种突发状况时,显得过于被动,对项目整体需求和进展的把控也不足。而在M2中,伴随着更多的沟通交流,这一点做得更加到位。能够及时根据进度调整需求变化以及更新TFS任务

      2. 能够时时总结并提高团队效率

        M2初期关于scrum meeting做的是不够好的,写得太过简略,而且标准控制的也不严格。中期通过一次例会,一位同学提到了这点,并提出了自己的意见,经过讨论被大家接受。之后迅速更改了scrum meeting发布模式,后几篇的博客质量明显上升。这就是一个能够时时总结并提高团队效率的例子。

    而在M1中做的比较好的几点也保持了下来。

    I.保持简明——尽可能简化工作量的技艺——极为重要

    通过API文档,将项目任务细化为前端与后端。

    后端采用rails框架,自带MVC结构,后端三人分别去做Model层,Controller以及Router

    前端采用界面也JS代码分离开发的方式,将任务分为UI设计界面实现,界面动态化展示。

    通过以上的开发模式,虽然大家是各自编码,但是各个部分之间的耦合度非常低,整合起来比较简单明了。每个人只需要专注于自己的技术领域,学习成本降低,开发效率提升。

    II. 无论团队内外,面对面的交流始终是最有效的沟通方式

    我们每周都有小组会议。每周例会主要议题有两个,第一个是该周目标与任务安排,第二个是介绍采用的新的技术方案or开发工具、开发方式。第一个议题,使每个队员明确自己的任务,任务明确,是一个开发人员进行开发的最大动力。第二个议题,使队员知道接下来将如何和队友合作,如何什么样的技术实现将要开发的功能。
    比如,我们在讨论用户状态控制时,涉及到后端的Token存储、API调用、前端sessionStorage存储以及header传递身份信息的验证方式,将整个技术流程介绍完毕,前后端队员就理解如何更好的和对方配合了。

    III. 以有进取心的人为项目核心,充分信任他们

    我们团队有明确的前端负责人和后端负责人。平时遇到一些问题,PM直接和负责人沟通,负责人再和自己组内人员分工讨论。PM充分信任负责人。把任务交给他们十分方向。这样PM才有更多的时间和精力宏观规划,整体把握。如果PM总是担心任务完成情况和质量,或者总是追着每个人催促进度,那么就没有充足的精力规划项目,项目质量就会下降。

       

    2. 总体相对于 M1 改进的地方

    I.TFS任务的规范化。TFS任务采用实时创建、更新的策略,严格按照真实进度来进行,能够更好的进行敏捷开发。

    II.UI得到了部分美化。

    III.使用了GIT作为代码管理工具,大大提高了代码管理效率。解决了诸如代码共享、代码版本更新、代码版本冲突等潜在问题。M2中几乎没遇到代码版本带来的麻烦。

    IV. 后端执行了压力测试。

    V. 增强了用户场景测试。

       

    1. 仍需改进的地方

    I. 前端测试机制仍不完善,互相之间的沟通交流也需加强。

    II.仍需更重视代码规范。前后端代码的规范并不很严格,这会对将来的进一步开发产生较大的影响。

     

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

    我觉得团队目前的状态属于可管理级级别,有过程纪律和功能性,,团队协作比较协调,但仍缺乏严格的代码复审流程。

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

    我觉得我们团队目前处于磨合阶段

     

  • 相关阅读:
    sql语句执行顺序
    ThinkPHP的入门学习目录结构及基础知识
    IE6的PNG透明解决方案
    用CSS画三角形
    position:sticky介绍 页面滚动导航条始终在最顶部的实现方法
    那些年我们一起清除过的浮动
    "自适应网页设计"到底是怎么做到的?其实并不难。
    jQuery formValidator表单验证插件(详解)
    学习10分钟,改变你的程序员生涯【转载】
    最差的时光 枯木
  • 原文地址:https://www.cnblogs.com/wowotoubuaa/p/5118509.html
Copyright © 2020-2023  润新知