第03组 Alpha事后诸葛亮
组长博客
项目Postmortem模板
设想和目标
1.我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
我们软件要解决的的问题是福州大学校园二手书的处理问题。应该定义得算比较清楚。有比较清楚的描述。
2.我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?
我们暂时还没有达到目标。原计划的功能以及实现了3个,还没有按照原计划的时间交付,用户数量也还没有达到。
3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
目前因为功能没完善还没有什么用户量。
4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
如果重来一遍,我肯定好好规范组员的代码。
计划
1.是否有充足的时间来做计划?
时间方面是很不充足的,大家都有很多的考试需要复习。
2.团队在计划阶段是如何解决同事们对于计划的不同意见的?
一般是通过询问有经验的同学或者老师然后投票觉得该执行哪个意见
3.你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
还没有做完,因素有比较多,主要的原因是花的时间少了,组员们不够重视。
4.有没有发现你做了一些事后看来没必要或没多大价值的事?
有,因为是第一次做项目,所以在各个方面的调试中都会发现这种问题。
5.是否每一项任务都有清楚定义和衡量的交付件?
应该都有比较清晰的定义。
6.是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
后端的进程太慢了。没估计到的是组员的热情,有些很高,有些就低得离谱。人心你叫我猜讲道理我猜不透袄。
7.在计划中有没有留下缓冲区,缓冲区有作用么?
没有,也是临时知道周六答辩,都在疯狂赶进度,没留什么缓冲区。
8.将来的计划会做什么修改?(例如:缓冲区的定义,加班)
会加入一些缓冲区,毕竟变数还是比较大的
9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
对于一个项目,必须每个人都积极去做好自己的本职工作,这个项目的进度才能够按时完成。同时我也觉得是我自己的管理能力出问题,如果重新来一遍的话,我会花更多的时间去管理整个项目的进度。
资源
1.我们有足够的资源完成这个项目吗?
就目前来说是有的,可能就支付功能那一块会出现没有资源的问题。
2.各项任务所需的时间和其他资源是如何估计的,精度如何?
一般是按照任务的难度来估计的,估计得比较粗糙,一般是按照星期估计。
3.测试的时间,人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试人员和硬件应该是足够,对于那些美工文案等。。感觉就那样吧说不上低估了,基本都在预期之内。
4.你有没有感到你做的事情可以让别人来做(更有效率)?
有时会有。
5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
再来一遍我会重新安排一下人员的岗位,争取做到更优。
变更管理
1.每个相关的员工都及时知道了变更的消息?
基本都能够及时知道。
2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
基础功能必须实现,一些附加的功能可以推迟实现。
3.项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
目前还比较朦胧,我会抓紧时间弄清晰
4.对于可能的变更是否能制定应急计划?
目前还没有制定,前段时间大家都忙,没有人手的情况下着实没法制定。
5.员工是否能够有效地处理意料之外的工作请求?
有些员工可以。
6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
首先要弄清楚项目的出口条件,尽量提前做好应急方案,以防变更之后出现的风险。
设计/实现
1.设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
设计的工作在10月份选题报告作业的时候开始。由我来完成。确实是合适的时间,但人选不算最优。
2.设计工作有没有碰到模棱两可的情况,团队是如何解决的?
有,毕竟第一次做项目,从原型设计开始就有比较模棱两可的情况。都是经过组员讨论之后决定的。
3.团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
暂无,测试阶段会用到
4.比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
没区别,没更新
5.什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
就目前而言是前端用户界面产生的bug比较多,页面间的交互bug多得自闭。确实想到了,但也还在解决。
6.代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
没有严格执行代码规范,所以还在改进之中。
7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计得时候一定要设计得清晰一些,否则实现起来难度就会比较大。
测试/发布
1.团队是否有一个测试计划?为什么没有?是否进行了正式的验收测试?
有测试,计划在项目功能初步完成的时候进行测试。还没进行。
2.团队是否有测试工具来帮助测试?
暂无
3.团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
在手机上真机调试测试功能的。测试工具暂时没用,应该有的改进就是用测试工具。
4.在发布的过程中发现了哪些意外问题?
还没发布,没有先知的功能,以后再回答这个问题。
4. 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
先制定好测试计划吧
团队的角色,管理,合作
1.团队的每个角色是如何确定的,是不是人尽其才?
按照队员意向确定,基本保证人尽其才吧
2.团队成员之间有互相帮助么?
那肯定是有
3.当出现项目管理、合作方面的问题时,团队成员如何解决问题?
我感谢 _____林家伟_____对我的帮助, 因为某个具体的事情: 帮我分管了后端很多的事情。
4.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
学到了一些团队协作的精神。重来一遍的话,那就多学一点这种精神好了。
总结:
1.你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
可重复级吧。
2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
规范阶段吧
3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
如果说前一个里程碑是确定需求的话,那确实没有什么改进。如果说是别的事情作为里程碑的话,也确实没什么改进。以后尽量争取改进。
4.你觉得目前最需要改进的一个方面是什么?
队员对项目的重视程度。
5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
协作原则吧。就前端部分的同学而言一直都有在和写接口和后端的同学进行交互。
全组讨论照片
答辩总结:
1.评估团队中每个人对本次作业的贡献比例,描述为本次作业的工作流程、组员分工、组员工作量比例
姓名 | 分工 | 比例 |
---|---|---|
张逸杰 | 组长+自适应性工具人 | 12% |
林家伟 | 后端+接口+数据库 | 13% |
苏凯婷 | 前端 | 10% |
鲍冰如 | 前端+UI设计 | 10% |
杨锦镔 | 前端 | 10% |
吴智勇 | 后端 | 7% |
刘汪洋 | 后端 | 7% |
黄彬煌 | 后端 | 7% |
陈荣杰 | 后端 | 8% |
黄智锋 | 后端+UI设计 | 10% |
王嵚 | 文档撰写+测试 | 6% |
答辩平均分
91+90+87(最低分去掉)+91+94(最高分去掉)+88+94+91+94+90=91.125
91.125*0.6≈55分
问题
1.界面再优化一下,功能就完善一下
我们会继续努力,争取写出更好的界面,将功能完善到位。
2.取消配送
我们会考虑这个建议取消配送。
3.增加用户反馈功能
已经有了这个功能,只是还没写完,我们争取早些写完。
4.psp表格
PSP2.1 | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
Planning | 计划 | 10 | 20 |
Estimate | 估计这个任务需要多少时间 | 5 | 5 |
Development | 开发 | 10 | 10 |
Analysis | 需求分析 (包括学习新技术) | 60 | 50 |
Design Spec | 生成设计文档 | 0 | 0 |
Design Review | 设计复审 | 0 | 0 |
Coding Standard | 代码规范 (为目前的开发制定合适的规范) | 10 | 10 |
Design | 具体设计 | 10 | 15 |
Coding | 具体编码 | 60 | 140 |
Code Review | 代码复审 | 10 | 10 |
Test | 测试(自我测试,修改代码,提交修改) | 30 | 20 |
Reporting | 报告 | 0 | 0 |
Test Repor | 测试报告 | 0 | 0 |
Size Measurement | 计算工作量 | 0 | 0 |
Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 10 | 10 |
合计 | 215 | 300 |
学习进度表
第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
---|---|---|---|---|---|
12 | 200 | 2000 | 20 | 120 | 学习了推荐算法 |
第03组 Alpha事后诸葛亮的更多相关文章
- 第11组 Alpha事后诸葛亮
第11组 Alpha事后诸葛亮 组长博客链接 https://www.cnblogs.com/xxylac/p/11924846.html 设想和目标 我们的软件要解决什么问题?是否定义得很清楚? ...
- 第01组 Alpha事后诸葛亮
目录 一.总结思考 1.设想和目标 ①我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? ②我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原 ...
- 第10组 Alpha事后诸葛亮
一.组长博客链接 组长博客 二.总结思考 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 我们的APP主要解决大学生闲置物品处理问题,定义的很清楚,用户 ...
- 第02组 Alpha事后诸葛亮
目录 1. 组长博客(2分) 2. 总结思考(27分) 2.1. 设想和目标(2分) 2.2. 计划(5分) 2.3. 资源(3分) 2.4. 变更管理(4分) 2.5. 设计/实现(4分) 2.6. ...
- 第09组 Alpha事后诸葛亮
组长博客链接 组长博客 参考邹欣老师的问题模板进行总结思考 设想和目标(2分) 1.我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 解决的问题 我们软件初期旨在解决 ...
- 第08组 Alpha事后诸葛亮
组长博客 点这里! 总结思考 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 弥补Powerpoint中模板转换存在的缺陷,完善PPT模板一键转换的功能 ...
- 第12组 Alpha事后诸葛亮
Header 组长博客 Postmortem 设想和目标 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述? 要解决的是喜欢记录分享旅游生活的人群的行迹记录和分享问题, ...
- 第07组 Alpha事后诸葛亮
1.请在博客开头给出组长博客链接(3.1 2分) 团队:摇光 队长:杨明哲 组长博客:这里 2.参考邹欣老师的问题模板进行总结思考(3.2 27分) 设想和目标(2分) 1.我们的软件要解决什么问题? ...
- 第06组 Alpha事后诸葛亮
一.组长博客: https://www.cnblogs.com/mhq-mhq/p/11923194.html 二.Postmortem模板 设想和目标 1.我们的软件要解决什么问题?是否定义得很清楚 ...
随机推荐
- C# Modbus 数据读取 使用NModBus4库
ModBus通讯协议 方法名 作用 所需参数 返回值 对应功能码 ReadCoils 读取DO的状态 从站地址(8位) byte slaveAddress 起始地址(16位) ushort start ...
- 用友U9 UFSoft.UBF.Business.Session
Session的概念 在现在UBF中,Session的本意是work unit,即持久层的一个边界,非常轻,主要用作批量提交,并标识这次批量提交的边界,不涉及到事务等概念. 当前ISession可以通 ...
- SpringCloud-Consul开发环境配置
一.consul安装 1.下载:https://www.consul.io/downloads.html: 2.选择版本:本人开发环境是windows,所以选择win64: 3.安装:保存至D:/Sp ...
- python基础流程控制
流程控制主要分为三大类: 1.if 判断语句 2.while 循坏语句 3.for 循坏语句 下面以举例说明: if 判断语句: user1 = 'seven' user2 = 'alex' pass ...
- Laravel使用Redis共享Session
一.当系统的访问量上升的时候,使用Redis保存Session可以提高系统的性能,同时也方便多机负载的时候共享Session 打开config/database.php.在redis中增加sessio ...
- FreeRTOS 任务通知模拟事件标志组
实验 //设置事件位的任务 void eventsetbit_task(void *pvParameters) { u8 key; while(1) { if(EventGroupTask_Handl ...
- Java检查字符串是否包含中文字符
转自:https://blog.csdn.net/zhanghan18333611647/article/details/80038629 强烈推荐一个大神的人工智能的教程:http://www.ca ...
- FFMPEG处理音频时间戳的主要逻辑
来源:http://www.xuebuyuan.com/1466771.html FFMPEG处理音频时间戳的主要逻辑 2013年12月09日 ⁄ 综合 ⁄ 共 2226字 ⁄ 字号 小 中 大 ⁄ ...
- Pandas 之 DataFrame 常用操作
import numpy as np import pandas as pd This section will walk you(引导你) through the fundamental(基本的) ...
- Nmon监控性能分析
一.CPU信息 1.折线图中蓝线为cpu占有率变化情况:粉线为磁盘IO的变化情况: 2.下面表各种左边的位磁盘的总体数据,包括如下几个: Avg tps during an interval 每个间隔 ...