第12组 Alpha事后诸葛亮
Header
Postmortem
设想和目标
- 我们的软件要解决什么问题?是否定义得很清楚?是否对典型用户和典型场景有清晰的描述?
要解决的是喜欢记录分享旅游生活的人群的行迹记录和分享问题,提供一个方便的平台,供这些用户记录和分享、交流。
相关定义,典型用户和典型场景已在需求分析报告有清晰的描述。 - 我们达到目标了么(原计划的功能做到了几个? 按照原计划交付时间交付了么? 原计划达到的用户数量达到了么?)?
- 原计划功能实现情况
- 核心功能基本实现
- 非核心功能一点没做
- 界面较为简陋
- 是否按原计划交付时间交付
- 是的,在答辩当天我们展示了我们的成果
- 原计划预期的用户数量是否达到
- 没有计划有用户使用
- 原计划功能实现情况
- 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
- 用户量与预期一致
- 接受程度与设想一致,确实离目标更近了
- 有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 遇到的困难真的是不计其数,甚至可以单独写成一篇报告
- 如果历史重来一遍
- 尽早明确分工
- 技术选型要谨慎,事先踩坑很重要
- 合理安排时间,尽量不要摸鱼
计划
- 是否有充足的时间来做计划?
- 我们很早就开始了计划,时间上是很充足的,但是我们没有足够重视这个环节,并没有投入过多的时间在这个方面,这也是算是个教训。
- 团队在计划阶段是如何解决同事们对于计划的不同意见的?
- 由于团队成员开发经验不足,基本没提出什么不同意见
- 你原计划的工作是否最后都做完了? 如果有没做完的,为什么?
- Alpha计划的核心工作基本完成,但扩展工作没有完成,时间不够
- 有没有发现你做了一些事后看来没必要或没多大价值的事?
- 复杂的Git工作流和对代码质量的保证,这个目前看起来没多大价值,但后面说不定
- 踩坑,别人不会知道我们踩了什么坑,有什么意义,但是长期来看这个意义也说不定
- 是否每一项任务都有清楚定义和衡量的交付件?
- 每一项任务都有很清楚的定义,但未必都有清楚的衡量标准
- 是否项目的整个过程都按照计划进行,项目出了什么意外?有什么风险是当时没有估计到的,为什么没有估计到?
- 并没有严格按照计划。因为踩了一些坑,导致进度缓慢。
- 对于风险估计,经验不足
- 在计划中有没有留下缓冲区,缓冲区有作用么?
- 没有,故没有作用
- 将来的计划会做什么修改?(例如:缓冲区的定义,加班)
- 将来会将任务集中在一段时间完成,而不是平摊到整个任务周期。
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 学到了长痛不如短痛,慢慢肝不如爆肝,集中在一起完成任务效率比较高。
资源
-
我们有足够的资源来完成各项任务么?
- 除了钱和经验都有
-
各项任务所需的时间和其他资源是如何估计的,精度如何?
- 根据经验和前辈历史随缘估计,十分粗糙
-
测试的时间,人力和软件/硬件资源是否足够?
- 足够,开发兼职测试,并且测试量不是很大
-
对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
- 是,成果不够美观
-
你有没有感到你做的事情可以让别人来做(更有效率)?
- 感觉没有,但实际情况说不定,谁知道呢
-
有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
- 开发人员工作量过大,大家都应该学点开发
变更管理
-
每个相关的员工都及时知道了变更的消息?
- 在我们的分组内的成员都知道了变更的消息。主要通过交流和自动化通知
-
我们采用了什么办法决定“推迟”和“必须实现”的功能?
- 组长根据实际情况调整,但核心功能必须实现
-
项目的出口条件(Exit Criteria – 什么叫“做好了”)有清晰的定义么?
- 计划的功能实现,测试通过
-
对于可能的变更是否能制定应急计划?
- 没有,没考虑这一点
-
员工是否能够有效地处理意料之外的工作请求?
- 目前看来这方面并不是很好
-
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 计划赶不上变化,无论如何都会出现意外情况。在计划的时候要设置缓冲区以应对未知的变更。
设计/实现
- 设计工作在什么时候,由谁来完成的?是合适的时间,合适的人么?
- 设计工作在Alpha开始之际完成,主要由组长完成,时间和人未必都合适
- 设计工作有没有碰到模棱两可的情况,团队是如何解决的?
- 有,比如说可实现性存疑,一般通过踩坑解决。
- 团队是否运用单元测试(unit test),测试驱动的开发(TDD)、UML, 或者其他工具来帮助设计和实现?这些工具有效么?
- 没有。根据我以往的经验,在非专业团队里推行这些工具和机制,可以起到提高相关人员经验和拖慢进度的效果。
- 比较项目开始的 UML 文档和现在的状态有什么区别?这些区别如何产生的?是否要更新 UML 文档?
- 有一些差别,主要是实现细节导致的差异,文档需要更新
- 什么功能产生的Bug最多,为什么?在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
- 地图展示的Bug最多,因为Android生命周期的复杂性。还没发布
- 代码复审(Code Review)是如何进行的,是否严格执行了代码规范?
- 由组长复审,使用了强制措施(Git分支保护)执行代码规范
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 设计应具有前瞻性
- 充分考虑每个人的能力
测试/发布
- 团队是否有一个测试计划?为什么没有?
- 功能完成合并前自测
- 是否进行了正式的验收测试?
- 否
- 团队是否有测试工具来帮助测试?
- Postman和Swagger UI
- 团队是如何测量并跟踪软件的效能的?从软件实际运行的结果来看,这些测试工作有用么?应该有哪些改进?
- 未进行相关工作
- 在发布的过程中发现了哪些意外问题?
- 未发布
- 我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 预先定义测试细则和条件
- 测试应紧随开发进行
- 使用持续集成
团队的角色,管理,合作
-
团队的每个角色是如何确定的,是不是人尽其才?
- 由组长根据每个人的能力分配;否,因为考虑不是很这周全
-
团队成员之间有互相帮助么?
- 有
-
当出现项目管理、合作方面的问题时,团队成员如何解决问题?
- 讨论撕逼解决
-
我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
- 及时沟通
我感谢 _______徐祖豪______对我的帮助, 因为某个具体的事情: 就是很多不懂的地方,我去找他,他都很耐心的给我解答。
总结
- 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
- 处于初始级。我们的开发过程基本符合下面的定义。尤其是 “成功依靠的是个人的才能和经验” 而不是成熟的软件工程管理制度。
软件工程管理制度缺乏,过程缺乏定义、混乱无序。成功依靠的是个人的才能和经验,经常由于缺乏管理和计划导致时间、费用超支。管理方式属于反应式,主要用来应付危机。过程不可预测,难以重复。
PS:我觉得反应式管理挺好的,挺刺激的
-
你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
- 处于磨合的阶段,我们没有一个规范的制度或者说相关开发文档,在接下来的开发中,我们会注意改进。
-
你觉得团队在这个里程碑相比前一个里程碑有什么改进?
- 开发经验和合作经验有较大提升
-
你觉得目前最需要改进的一个方面是什么?
- 规范的制度
-
对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
- 递增,而不是连续的:先完成核心功能,再往外扩展
- 拥抱变化:我们对变化不排斥,并随时准备着
- 避免不必要的开销:不必要的文档都没写
照片
由于答辩后部分成员存在伤残情况和其他不可抗力,未能出席本次会议
这再次说明了软件工程实践是一门不吉利的课程
答辩总结
贡献比例
成员 | 分工 | 贡献度 |
---|---|---|
王永福 | 主要代码开发,派任务、催进度、代码规范 | 42% |
孙承恺 | 美术监督、现场评审、评分表整理 | 7% |
邱畅杰 | 分享图生成相关实现 | 8% |
丁枢桐 | 分享图生成相关实现 | 8% |
徐祖豪 | 评审表设计 | 4% |
余琳玲 | 答辩PPT | 7% |
林星培 | 答辩PPT | 7% |
林青霞 | 答辩PPT | 7% |
张凌昕 | Alpha大部分博客 | 10% |
得分
组号 | 分值 |
---|---|
1 | 57 |
2 | 54.6 |
3 | |
4 | 54 |
5 | |
6 | 58.2 |
7 | 54.6 |
8 | 53 |
9 | 56.4 |
10 | |
11 | |
12 | 50.4 |
平均 | 54.9 |
截至本博客撰写时(2019-11-24T17:00),空白小组尚未评分
Q&A
1
- Q:创建新点时是否只能手动选点定点?会否导致选的点不够准确或难以定点的问题?
- A:创建时自动定位,可以手动调整
2
- Q:选点频率可以频繁一些,定位都会准确吗
- A:定位精度依赖于设备和环境
3
- Q:在路线上是否能体现地点先后问题?
- A:Alpha版本比较简陋,没有体现这个,后续我们会使用有向纹理体现
4
- Q:旅游时进入了信号不佳的地点会不会对软件运行结果造成影响?
- A:这个是会的,但是我们目前暂不考虑这个问题
5
- Q: 是否有自动填补足迹的功能?如果有,打算怎么实现?
- A:目前没有。打算做,可以通过历史数据和地图高程数据进行猜测
你们这么嫖柯老板的问题真的好吗
6
截至本博客撰写时(2019-11-24T17:00),尚未提问
7
- Q:能不能手画路径,让我即使没去旅游也能装个b
- A:不能
8
- Q:旅游的时候手机电量有限,而定位耗电比较多,这个问题你们是如何解决的呢?
- A:我们目前采用被动位置更新,比较温和,耗电量不会比主动位置更新大
9
- Q:周边人怎么看到你们的分享,答辩的时候你们好像没有提到。
- A:在地图上可以直接看到其他人发布的点分享,轨迹分享暂时还没实现
10
- Q:怎么解决手动选点不准确问题?是否考虑增加输入地址定点功能?
- A:我们不需要手动选点,但是可以手动调整。至于第二个问题,我们不考虑,因为地理编码存在精度和二义性问题,但我们考虑逆地理编码
11
- Q:建议前端加大力度
- A:谢谢建议
个人
PSP表
PSP | Personal Software Process Stages | 预估耗时(分钟) | 实际耗时(分钟) |
---|---|---|---|
·Planning | 计划 | 5 | 5 |
·Estimate | 估计这个任务需要多少时间 | 5 | 5 |
·Development | 开发 | 20 | 25 |
·Analysis | 需求分析 (包括学习新技术) | 10 | 15 |
·Design Spec | 生成设计文档 | 0 | 0 |
·Design Review | 设计复审 | 5 | 10 |
·Coding Standard | 代码规范(为开发制定合适的规范) | 0 | 0 |
·Design | 具体设计 | 10 | 10 |
· Coding | 具体编码 | 0 | 0 |
·Code Review | 代码复审 | 0 | 0 |
· Test | 测试(自我测试,修改代码,提交修改) | 0 | 0 |
·Reporting | 报告 | 0 | 0 |
· Test Repor | 测试报告 | 0 | 0 |
·Size Measurement | 计算工作量 | 0 | 0 |
·Postmortem & Process Improvement Plan | 事后总结, 并提出过程改进计划 | 0 | 0 |
. | 合计 | 50 | 65 |
个人学习进度条
第N周 | 新增代码(行)| 累计代码(行)| 本周学习耗时(小时)|累计学习耗时(小时)| 重要成长
- | :-: | :-: |:-: |:-: | -:
1 | 0| 0 | 30|30 | 学习了安卓前端,Kotlin|
2 | 10| 10 | 20|50 | 学习了安卓前端,Kotlin|
3 | 33| 43 | 70|1200 | 学习了安卓前端,Kotlin,会了一些基本操作|