Alpha事后分析
设想和目标
1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
我们的软件的功能主要是让一些基于表单识别的项目(如微软智能表单识别项目)减少在数据生成方面上浪费的时间。定义的比较清楚,对于典型用户和典型场景的描述较为清晰。
具体来说,当一个项目需要用大量的人力来完成数据生成工作的时候,就可以用到我们的项目,不仅方便快捷,还能减少人力财力的浪费。具体见功能规格说明书
2. 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)
alpha阶段我们的目标是实现一个最小可用版本,即支持简单的表单生成。经过两周的学习和代码编写、一周的测试和稳定,我们基本完成了原计划的功能。
按照原定计划进行交付,用户数量基本上差不太多。
反思:由于我们的项目的主要受众并不是学生群体,而我们在短时间内也只能在学生群体内进行宣传,所以宣传效果并不是很好。
3. 和上一个阶段相比,团队软件工程的质量提高了么? 在什么地方有提高,具体提高了多少,如何衡量的?
无上一阶段。
4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
预计的用户数量是100左右,生成的表单数量约在400个左右。
由于我们的项目受众并不是学生群体,而我们目前在短期时间内只能向同学们推广,因此软件的预期下载量很可能并不能达到相应的标准。
但值得欣慰的是,截止5月5日21:15,我们的项目创建数量达到了94个,generate的次数达到了339,除去我们的测试数据,也比较可观,这说明我们基本上完成了预期。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
本阶段做的还算不错,改进的话大概是再早一点明确目标吧,这样会留下不少时间的缓冲期。
计划
1. 是否有充足的时间来做计划?
有充足的时间来做计划,并在开发过程中微调。
2. 团队在计划阶段是如何解决同事们对于计划的不同意见的?
计划的产生本身是由全体团队成员一起讨论得出的,每次的例会上大家都会商讨接下来的方向,由于实现功能较简单,目前并没有不同意见。
3. 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
基本上完成了,在某些方面可能并不是做的尽善尽美,但基本上达到了alpha阶段的原定计划目标。
4. 有没有发现你做了一些事后看来没必要或没多大价值的事?
姓名的生成部分在起初统计了近年来的新生儿数据,比较繁琐还没太大的用处,后期舍弃了。
5. 是否每一项任务都有清楚定义和衡量的交付件?
交付件:
- PM:博客、issue
- 后端:可以提供给前端的接口
- 前端:可以提供给用户的界面
6. 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
基本上按照计划进行。
小意外:
由于我们的项目受众并不是普通学生,因此在宣传发布时出现了一些意外,即用户量比较少。但我们随即加大了推广的力度,推(强)荐(迫)身边的朋友使用了我们的软件,收到的反响还是不错的。
7. 在计划中有没有留下缓冲区,缓冲区有作用么?
Alpha阶段的计划中没有明确的缓冲区。但开发按部就班的进行,没有出现延期的情况。
8. 将来的计划会做什么修改?(例如:缓冲区的定义,加班)
beta阶段会完善alpha阶段的交互速度,并进行新功能的扩展。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
model页面没用到,这应该算是在计划方面比较大的问题,值得重新考虑一下alpha阶段的最初预期。其次,由于我们比较信任微软的代码质量,忽略了我们接手的是一个还在开发和完善中的项目,因此没有计划修复和细致测试原项目中已经存在的bug,干扰了后期测试时对bug的定位和修复。
资源
1. 我们有足够的资源来完成各项任务么?
暂时足够,但由于今年的课程比较特殊,线上联系并没有线下联系效率高。
2. 各项任务所需的时间和其他资源是如何估计的,精度如何?
各项所需时间估计基本准确。数据生成上花费的时间比较多,由于服务器起初是在国外,导致访问速度非常慢,也对我们的用户造成了影响。
3. 测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试的时间,人力和软硬件资源足够,美工方面并不需要大费周折,但还是出现了一点点小的插曲。
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
如果重来一遍我们会仔细思考在数据生成方面所使用的方法,另外也会尽早地布置好服务器。
变更管理
1. 每个相关的员工都及时知道了变更的消息?
是。当有重大变化会及时通过微信进行通知,即使没有及时查看微信,至少每天的例会上也会当面讲清楚。但其实变更并不多。
2. 我们采用了什么办法决定“推迟”和“必须实现”的功能?
基本可使用功能最小集为“必须实现”功能,其余都归类在“推迟”功能里。
3. 项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
有,完成最小可用版本即为出口条件,详见发布声明
4. 对于可能的变更是否能制定应急计划?
当一个比较复杂的功能无法立即实现,且不属于最小可用版本的必要功能时,在例会上就会将其作为可推迟的功能,将该功能优先级降低。
5. 员工是否能够有效地处理意料之外的工作请求?
能。最初并没有计划增加上传空白PDF的功能,随着测试的进行发现了这一问题,最终也顺利的解决了。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
model页面的推迟方面,我们可能在一开始就将其放入beta阶段;生成的字体方面,由于最初出现了莫名其妙的bug,导致暂时推迟了手写字体的生成,改成了打印字体,但是后期bug又消失了,又改了回来,浪费了一些时间,如果重来,我们可能会先不考虑手写字体,将打印字体做好后在实现手写字体。
设计/实现
1. 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
设计工作在项目冲刺开始前,由大家自由选择的,是合适的时间。开发主要分成了前端和后端两个方向,相关技术基本上大家都没接触过,因此难以评价是否是合适的人。
2. 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
有。因为在任务发布时只是将任务的名称发出,具体实现方法和内容并没有明确,此时会在团队例会上解决或由PM协调。
3. 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么? 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
4. 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
数据生成方面产生了很多bug,例如生成的文字是反的等等,后期进行了分类讨论,做出了修改。
因为我们在开发的时候真的就没有想到这些情况
5. 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
利用github复审,当前端某一个页面的代码写完时,会push到github上,然后由负责merge的同学进行复审。代码规范也是严格遵守pylint的规定进行编写。
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
在tag页面标注方面,我们现在实现的时点一次按键传一次请求,效果并不是很好,重来的话会做成一次传递多个请求的方式。
测试/发布
1. 团队是否有一个测试计划?为什么没有?
有,见测试分析
2. 是否进行了正式的验收测试?
是,(功能规格说明书、整体测试、测试计划)
3. 团队是否有测试工具来帮助测试?
postman测试驱动开发
开发环境:使用VS Code和Azure Functions开发http响应函数,构建后端http服务器。
测试工具:Postman。
开发过程前端的请求由Postman模拟,对后端进行测试,整体上采用测试驱动开发的方式,根据Postman的测试请求来开发完善http服务器功能。
举个例子
生成请求:是GET请求,没必要是POST,参数需要携带项目路径信息。
后端基于此请求开发生成模块,接受请求后解析路径,将路径中对应的项目文件取出来,运行数据生成模块,将生成的文件存放回对应的路径。
4. 团队是如何测量并跟踪软件的效能的?
自己先做使用测试、压力测试等。然后通过用户的反馈不断地进行完善。
5. 在发布的过程中发现了哪些意外问题?
由于服务器问题引发的访问慢,让用户体验较差并进行了反馈。
我们学到了什么? 如果重来一遍, 我们会做什么改进?
完善测试计划、并设计好缓冲区
团队的角色,管理,合作
1. 团队的每个角色是如何确定的,是不是人尽其才?
是在开会的时候自由选择的,现在来看还是可以称得上是人尽其才的。
2. 团队成员之间有互相帮助么?
有
成员 | 感谢信 |
---|---|
ly | 在本次团队作业中,合作很愉快。为了制作展示视频,我写了初稿,tzj和dxy帮助进行了修改和润色。llj帮助进行了视频录制和配音小伙伴邀请等。在测试对接后的前后端时,tzj多次帮助我测试整体项目,反馈错误和体验效果,帮助我修改了很多Bug。整合后端代码的时候,dxy同学辅助我更改代码,变更需求,不断迭代后端代码。技术上,整体思路是zyc同学提供,是我们小组的希望之花!最后感谢一下PM wyk的辛苦付出! |
llj | 感谢tzj同学对我的帮助,在开发前期帮助我厘清前端源代码结构,详略得当,在具体的功能实现中也提出了很有参考价值的建议;感谢zyc同学对我的帮助,为我提供了很多技术上的指导,总是很耐心地帮助我解决问题,也让我学习到了很多;感谢ly同学,活跃度up up!在后端部署和前后端对接的时候积极严谨,效率也超高!感谢dxy同学,项目的核心功能代码实现,后期功能不断迭代改进和修改bug高效认真,从不敷衍;感谢wyk同学,每天尽职的组织例会发布博客,灵活管理工作内容,保证项目按进度推进,确保工作中问题的及时解决以及团队的有效沟通,在答辩中也很赞!给大家撒花!!! |
dxy | 感谢wyk,尽职尽责当pm,感谢ly,为项目调度操心,感谢zyc,为项目解决重大难题,感谢tzj,在前端尽职尽责,感谢llj,生病依然坚持 |
wyk | 感谢zyc同学在前期帮我搞定了github上的issue问题,ly、tzj同学在发布期间对软件的不断测试与完善,llj、dxy同学的代码编写及视频制作……感谢大家的积极性 |
tzj | 感谢zyc对我的帮助,因为前端用到的一些代码规范化工具、单元测试工具等等都是他介绍给我的,让我省去了很多查找相关内容的时间,还有一些技术难题也都是他指导解决的;感谢ly对我的帮助, 因为端对端测试的时候,他帮助我测出了很多bug,让我能尽快的修改,而且团队交流中也经常和我一起讨论问题和前后端交接情况;感谢llj对我的帮助,因为在实现前端图标的时候,她帮助我梳理清了原项目中有关图标使用的代码结构,并且一起讨论了一些功能设计相关的问题;感谢wyk对我的帮助,因为他为我们团队组织会议,记录我们的工作进度,及时让团队中的问题得到讨论和交流。我感谢dxy对我的帮助,因为他为我解释了后端是相应的功能比如生成pdf的实现,让我更好的理解整个项目的工作流程。 |
zyc | 感谢ly的帮助,在前后端对接中做了许多工作。 |
3. 当出现项目管理、合作方面的问题时,团队成员如何解决问题?
每日例会上大家都会进行交流,基本上当天出现的问题很快就能够得到解决。
总结:
你觉得团队目前的状态属于CMM/CMMI中的哪个档次?
我觉得团队目前处于管理级。我们对各自的分工十分明确,又统一清楚的认识;任务issues管理、每日例会以及燃尽图的管理,相对来说也比较细致。
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
介于磨合和规范之间,即将进入规范阶段。
你觉得目前最需要改进的一个方面是什么?
在签入代码方面做好约定;尽早明确alpha阶段目标,以留出缓冲期。
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
尽早并持续地交付有价值的软件以满足顾客需求,我们在alpha阶段预期的实现较为困难时,我们做出了取舍,完成了最小可用版本的开发。
正如我们前面提到的, 软件的质量 = 程序的质量 + 软件工程的质量,那团队在下一阶段应该如何提高软件工程的质量呢?
代码要保质保量,定期进行代码复审。
加大测试力度,减少bug出现的可能性。
讨论截图
Alpha事后分析的更多相关文章
- 【二食堂】Alpha - 事后分析
事后分析 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? Alpha阶段要解决的问题是:根据用户标注的信息完成知识图谱的生成渲染.要解决的问题定义得比较 ...
- [no_code][Alpha]事后分析
$( "#cnblogs_post_body" ).catalog() 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们要解决的 ...
- Alpha阶段事后分析报告
每个团队编写一个事后分析报告,对于团队在Alpha阶段的工作做一个总结. 请在2016年11月24日上课之前根据下述博客中的模板总结前一阶段的工作,发表在团队博客上,并在课上的事后分析会上进行汇报,并 ...
- [Alpha阶段]事后分析博客
目录 Alpha阶段事后分析博客 设想和目标 计划 资源 变更管理 设计/实现 测试/发布 团队的角色,管理,合作 总结 讨论照片 Alpha阶段事后分析博客 作业要求:Alpha阶段事后分析 设想和 ...
- 事后分析$\alpha$
项目 内容 课程:北航-2020-春-软件工程 博客园班级博客 要求 事后分析 我们在这个课程的目标是 提升团队管理及合作能力,开发一项满意的工程项目 这个作业在哪个具体方面帮助我们实现目标 组织组员 ...
- M1事后分析报告(Postmortem Report)
M1事后分析报告(Postmortem Report) 设想和目标 1. 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们项目组所开发的软件为一个基于Andro ...
- 团队作业10——事后分析(Beta版本)
团队作业10--事后分析(Beta版本) 目录 一.设想与目标 二.计划 三.资源 四.变更管理 五.设计与实现 六.测试与发布 七.总结 八.图片和贡献分分配 一.设想和目标 1.我们的软件要解决什 ...
- 【集美大学1411_助教博客】团队作业10——项目复审与事后分析(Beta版本)
写在前面的话 软件工程课结束了,大家开心吗?是不是再也不用熬夜写代码了?如果这门课你真的熬夜写代码了,相信你一定有收获,如果这门课结束了你觉得是自己一个全新的开始,那么这门课的意义就实现了.团队作业全 ...
- 【2017集美大学1412软工实践_助教博客】团队作业10——项目复审与事后分析(Beta版本)
写在前面的话 转眼轰轰烈烈本学期的软工实践就结束了,这个过程中想必在熬夜敲代码,激烈讨论中留下诸多回忆的同时,也收获了不少.恭喜所有团队完成了本阶段冲刺,此外,由于大家的贡献分给的都很平均,将个人贡献 ...
随机推荐
- java四种字符串拼接方式
1.直接用"+"号 2.使用String的方法concat 3.使用StringBuilder的append 4.使用StringBuffer的append
- 回忆那些年我玩过的ide,看看哪些你也玩过,看图回忆
闲来无聊,回忆一下这些年玩过的ide.看看哪些你也玩过. QBasic 第一个ide,兴奋程度也是最大的,从此进入了码农行列 VisualBasic 可以拖界面了,成就感爆棚 Turbo C c语言, ...
- canvas绘制图像轮廓效果
在2d图形可视化开发中,经常要绘制对象的选中效果. 一般来说,表达对象选中可以使用边框,轮廓或者发光的效果. 发光的效果,可以使用canvas的阴影功能,比较容易实现,此处不在赘述. 绘制边框 绘制 ...
- 201871030116-李小龙 实验二 个人项目—《D{0-1} KP》项目报告
项目 内容 课程班级博客链接 https://edu.cnblogs.com/campus/xbsf/2018CST 这个作业要求链接 https://www.cnblogs.com/nwnu-dai ...
- 痞子衡嵌入式:同一厂商不同系列Flash型号下Dummy Cycle设置方法可能有差异 (以IS25LP064为例)
大家好,我是痞子衡,是正经搞技术的痞子.今天痞子衡给大家介绍的是同一厂商不同系列Flash型号下Dummy Cycle设置方法的差异. 上一篇文章 <在i.MXRT启动头FDCB里调整Flash ...
- Spring Boot入门学习
1. Spring Boot概述 1.1.什么是Spring Boot SpringBoot是一个可使用Java构建微服务的微框架.是Spring框架及其社区对"约定优先于配置"理 ...
- 逆向初级-PE(五)
5.1.PE文件结构 1.什么是可执行文件? 可执行文件(executable fle)指的是可以由操作系统进行加载执行的文件. 可执行文件的格式: Windows平台: PE(Portable Ex ...
- 「HTML+CSS」--自定义加载动画【016】
前言 Hello!小伙伴! 首先非常感谢您阅读海轰的文章,倘若文中有错误的地方,欢迎您指出- 哈哈 自我介绍一下 昵称:海轰 标签:程序猿一只|C++选手|学生 简介:因C语言结识编程,随后转入计算机 ...
- VirtualBox虚拟机读取U盘
1 概述 使用VirtualBox虚拟机(系统Win10)读取宿主机(系统Manjaro)中的U盘. 2 安装扩展 戳这里下载对应版本的一个叫Oracle_VM_VirtualBox_Extensio ...
- IDEA main 函数的快捷键
1.main()快捷键:psvm 当输入ps的时候编辑器就会有如下提示,可见比eclipse要很方便 2.System.out.println()快捷键:sout