第12组 Alpha事后诸葛亮

Header

组长博客

Postmortem

设想和目标

  1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
    要解决的是喜欢记录分享旅游生活的人群的行迹记录和分享问题，提供一个方便的平台，供这些用户记录和分享、交流。
    相关定义，典型用户和典型场景已在需求分析报告有清晰的描述。
  2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么？)？
    • 原计划功能实现情况
      • 核心功能基本实现
      • 非核心功能一点没做
      • 界面较为简陋
    • 是否按原计划交付时间交付
      • 是的，在答辩当天我们展示了我们的成果
    • 原计划预期的用户数量是否达到
      • 没有计划有用户使用
  3. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么？ 我们离目标更近了么？
    • 用户量与预期一致
    • 接受程度与设想一致，确实离目标更近了
  4. 有什么经验教训？ 如果历史重来一遍, 我们会做什么改进？
    • 遇到的困难真的是不计其数，甚至可以单独写成一篇报告
    • 如果历史重来一遍
      • 尽早明确分工
      • 技术选型要谨慎，事先踩坑很重要
      • 合理安排时间，尽量不要摸鱼

计划

  1. 是否有充足的时间来做计划？
    • 我们很早就开始了计划，时间上是很充足的，但是我们没有足够重视这个环节，并没有投入过多的时间在这个方面，这也是算是个教训。
  2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？
    • 由于团队成员开发经验不足，基本没提出什么不同意见
  3. 你原计划的工作是否最后都做完了？ 如果有没做完的，为什么？
    • Alpha计划的核心工作基本完成，但扩展工作没有完成，时间不够
  4. 有没有发现你做了一些事后看来没必要或没多大价值的事？
    • 复杂的Git工作流和对代码质量的保证，这个目前看起来没多大价值，但后面说不定
    • 踩坑，别人不会知道我们踩了什么坑，有什么意义，但是长期来看这个意义也说不定
  5. 是否每一项任务都有清楚定义和衡量的交付件？
    • 每一项任务都有很清楚的定义，但未必都有清楚的衡量标准
  6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到？
    • 并没有严格按照计划。因为踩了一些坑，导致进度缓慢。
    • 对于风险估计，经验不足
  7. 在计划中有没有留下缓冲区，缓冲区有作用么？
    • 没有，故没有作用
  8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）
    • 将来会将任务集中在一段时间完成，而不是平摊到整个任务周期。
  9. 我们学到了什么？ 如果历史重来一遍, 我们会做什么改进？
    • 学到了长痛不如短痛，慢慢肝不如爆肝，集中在一起完成任务效率比较高。

资源

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

    • 除了钱和经验都有

  2. 各项任务所需的时间和其他资源是如何估计的，精度如何？

    • 根据经验和前辈历史随缘估计，十分粗糙

  3. 测试的时间，人力和软件/硬件资源是否足够？

    • 足够，开发兼职测试，并且测试量不是很大

  4. 对于那些不需要编程的资源 (美工设计/文案)是否低估难度？

    • 是，成果不够美观

  5. 你有没有感到你做的事情可以让别人来做（更有效率）？

    • 感觉没有，但实际情况说不定，谁知道呢

  6. 有什么经验教训？ 如果历史重来一遍, 我们会做什么改进？

    • 开发人员工作量过大，大家都应该学点开发

变更管理

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

    • 在我们的分组内的成员都知道了变更的消息。主要通过交流和自动化通知

  2. 我们采用了什么办法决定“推迟”和“必须实现”的功能？

    • 组长根据实际情况调整，但核心功能必须实现

  3. 项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么？

    • 计划的功能实现，测试通过

  4. 对于可能的变更是否能制定应急计划？

    • 没有，没考虑这一点

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

    • 目前看来这方面并不是很好

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

    • 计划赶不上变化，无论如何都会出现意外情况。在计划的时候要设置缓冲区以应对未知的变更。

设计/实现

  1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
    • 设计工作在Alpha开始之际完成，主要由组长完成，时间和人未必都合适
  2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？
    • 有，比如说可实现性存疑，一般通过踩坑解决。
  3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
    • 没有。根据我以往的经验，在非专业团队里推行这些工具和机制，可以起到提高相关人员经验和拖慢进度的效果。
  4. 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
    • 有一些差别，主要是实现细节导致的差异，文档需要更新
  5. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug？ 为什么我们在设计/开发的时候没有想到这些情况？
    • 地图展示的Bug最多，因为Android生命周期的复杂性。还没发布
  6. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
    • 由组长复审，使用了强制措施（Git分支保护）执行代码规范
  7. 我们学到了什么？ 如果历史重来一遍, 我们会做什么改进？
    • 设计应具有前瞻性
    • 充分考虑每个人的能力

测试/发布

  1. 团队是否有一个测试计划？为什么没有？
    • 功能完成合并前自测
  2. 是否进行了正式的验收测试？
    • 否
  3. 团队是否有测试工具来帮助测试？
    • Postman和Swagger UI
  4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
    • 未进行相关工作
  5. 在发布的过程中发现了哪些意外问题？
    • 未发布
  6. 我们学到了什么？ 如果历史重来一遍, 我们会做什么改进？
    • 预先定义测试细则和条件
    • 测试应紧随开发进行
    • 使用持续集成

团队的角色，管理，合作

  1. 团队的每个角色是如何确定的，是不是人尽其才？

    • 由组长根据每个人的能力分配；否，因为考虑不是很这周全

  2. 团队成员之间有互相帮助么？

    • 有

  3. 当出现项目管理、合作方面的问题时，团队成员如何解决问题？

    • 讨论撕逼解决

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

    • 及时沟通

  5. 我感谢 永福大佬 对我的帮助， 因为？

    • 作为组长他一直很照顾我们，自己揽下重活后还不忘督促我们学习，带领我们走上脱贫致富的道路！！！

总结

  1. 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？
    • 处于初始级。我们的开发过程基本符合下面的定义。尤其是 “成功依靠的是个人的才能和经验” 而不是成熟的软件工程管理制度。

软件工程管理制度缺乏，过程缺乏定义、混乱无序。成功依靠的是个人的才能和经验，经常由于缺乏管理和计划导致时间、费用超支。管理方式属于反应式，主要用来应付危机。过程不可预测，难以重复。

PS：我觉得反应式管理挺好的，挺刺激的

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

    • 处于磨合的阶段，我们没有一个规范的制度或者说相关开发文档，在接下来的开发中，我们会注意改进。

  2. 你觉得团队在这个里程碑相比前一个里程碑有什么改进？

    • 开发经验和合作经验有较大提升

  3. 你觉得目前最需要改进的一个方面是什么？

    • 规范的制度

  4. 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则？ 请列出具体的事例。

    • 递增，而不是连续的：先完成核心功能，再往外扩展
    • 拥抱变化：我们对变化不排斥，并随时准备着
    • 避免不必要的开销：不必要的文档都没写

照片

由于答辩后部分成员存在伤残情况和其他不可抗力，未能出席本次会议
这再次说明了软件工程实践是一门不吉利的课程

答辩总结

贡献比例

成员 分工 贡献度
王永福 主要代码开发，派任务、催进度、代码规范 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表格

PSP2.1 Personal Software Process Stages 预估耗时（分钟） 实际耗时（分钟）
Planning 计划 2 2
Estimate 估计这个任务需要多少时间 2 2
Development 开发 1055 17
Analysis 需求分析 (包括学习新技术) 10 25
Design Spec 生成设计文档 6 10
Design Review 设计复审 2 2
Coding Standard 代码规范 (为目前的开发制定合适的规范) 12 15
Design 具体设计 24 36
Coding 具体编码 24 36
Code Review 代码复审 12 18
Test 测试（自我测试，修改代码，提交修改） 15 30
Reporting 报告 6 9
Test Repor 测试报告 2 3
Size Measurement 计算工作量 5 2
Postmortem & Process Improvement Plan 事后总结, 并提出过程改进计划 2 4
合计 155 172

学习进度条

第N周 新增代码（行） 累计代码（行） 本周学习耗时(小时) 累积学习耗时(小时) 重要成长
1 0 0 5 5 熟悉Axure RP用法
2 0 0 5 10 了解原型设计方法
3 0 0 5 15 原型设计实战
4 0 0 12 27 团队项目原型设计
5 0 0 15 42 学习kotlin
6 0 0 10 52 学习kotlin
7 0 0 8 60 学习kotlin
8 0 0 7 67 了解kotlin
9 0 0 7 74 学习kotlin
posted @ 2019-11-24 17:47  雨霖铃0000  阅读(77)  评论(0)  编辑  收藏  举报