°LL
第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 计划 20 20
Estimate 估计这个任务需要多少时间 20 20
Development 开发 1055 1720
Analysis 需求分析 (包括学习新技术) 100 250
Design Spec 生成设计文档 60 100
Design Review 设计复审 20 20
Coding Standard 代码规范 (为目前的开发制定合适的规范) 125 150
Design 具体设计 240 360
Coding 具体编码 240 360
Code Review 代码复审 120 180
Test 测试（自我测试，修改代码，提交修改） 150 300
Reporting 报告 60 90
Test Repor 测试报告 20 30
Size Measurement 计算工作量 15 20
Postmortem & Process Improvement Plan 事后总结, 并提出过程改进计划 25 40
合计 1135 1830

学习进度条

第N周 新增代码（行） 累计代码（行） 本周学习耗时(小时) 累积学习耗时(小时) 重要成长
1 0 0 5 5 熟悉Axure RP用法
2 0 0 5 10 了解原型设计方法
3 0 0 5 14 原型设计实战
4 0 0 12 25 团队项目原型设计
5 0 0 15 40 学习kotlin
posted on 2019-11-24 21:21  °LL  阅读(64)  评论(0)  编辑  收藏  举报

Copyright © 2024 °LL
Powered by .NET 9.0 on Kubernetes Powered By博客园