拖鞋旅游队团队事后诸葛亮会议
前言
- 队名：拖鞋旅游队
- 组长博客：https://www.cnblogs.com/Sulumer/p/10054510.html
- 时间：2018-12-1 20:00
- 地点：生活三区31#3楼活动室
- 参会人员： 拖鞋旅游队全体成员
- 与会图片：
项目Postmortem
设想与目标
- 1.我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？
我们软件要解决的是喜欢记录分享旅游生活的人群的旅游记录分享功能。相关定义、典型用户以及典型场景已经通过UML图和需求分析报告清晰地描述。 - 2.我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)?
在alpha冲刺阶段，按时达到了原计划的要求。目前仍处于内测阶段，只在小范围内挑选特定用户交流使用，尚未大面积投放给用户使用。在beta冲刺阶段开始时会陆续提交试用版本，让用户进一步参与软件设计。 - 3.用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?
在alpha版本下，用户的满意程度符合我们的预期，可以自信地说，我们离目标更近了。 - 4.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
原型设计非常重要，常常起到先导作用。我们在做alpha版本之前没有重视原型设计，后来在实现时出现漏洞，不得不返工重构，浪费了时间。如果历史重来一遍，在设想阶段，应尽可能的完善原型设计，减少重构次数。
计划
- 1.是否有充足的时间来做计划？
从确定团队开发项目到具体实践，做计划的时间不多。但随着项目的推进，我们也在不断的完善细化计划。 - 2.团队在计划阶段是如何解决同事们对于计划的不同意见的？
我们通过集中讨论的方式，在小组讨论会上收集不同意见，由PM和技术组长进行整合，再提出统一的解决方案。 - 3.你原计划的工作是否最后都做完了？如果没有完成，为什么？
alpha冲刺阶段原计划工作都完成了。没有完成的部分是因为在计划之外的拓展功能实现较困难，需要花费较多时间。 - 4.有没有发现你做了一些事后看来没必要或没多大价值的事?
因为在Alpha版本分工前，对整个项目的架构和功能界面都已经定义比较清楚，所以在这方面倒是比较少。但是，由于之前没对团队条件的充分理解，也可以说是疏忽吧，做不了本来计划好的事而不得不先丢弃。在之前我们一直畅想着加入榜单功能以及基于地理位置的比较有意思的功能，而在后来发现在此方面微信定义了门槛，需要《电信业务增值许可证》，而这也需要公司主体才能够办理，因此我们只能暂时废弃之前对这方面做的工作。 - 5.是否每一项任务都有清楚定义和衡量的交付件?
有些有，有些没有。对于核心功能，每个任务都有清楚的定义和衡量的交付件，但是对于小功能，因为比较简单，在alpha阶段还没有十分清晰的定义。 - 6.是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?
到目前为止，项目的整个过程都按照计划进行。项目中队友GitHub的使用情况不容乐观，在签入代码时花费了较多时间。 - 7.在计划中有没有留下缓冲区，缓冲区有作用么?
有，有留下一天的缓冲区用来修改和debug。 - 8.将来的计划会做什么修改？（例如：缓冲区的定义，加班）
在目前核心功能都已经基本完成的情况下，将来的计划会更多的倾向功能完善和拓展，会扩充缓冲区时间，留出较多时间用来收集用户建议和测试。 - 9.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
完善计划和定制计划同样重要。原计划的实施情况已经符合我们的预期，但是在过程中总会有一些意想不到的突发情况，因此及时的微调计划对于整个项目的实行起到了很重要的作用。如果能重来一次，我希望在制定计划时能够留下更多的缓冲时间。
资源
- 1.我们有足够的资源来完成各项任务么?
目前的资源足够我们完成各项任务。 - 2.各项任务所需的时间和其他资源是如何估计的，精度如何?
各项任务所需要的时间和其他资源是有PM人为估计的，对时间的估计精度误差在小时以内。资源估计精度误差较大。 - 3.测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?
测试，人力和软件/硬件资源足够，但对于美工设计和文案设计这些主观难以定性衡量的资源难度较大，要设计出符合预期甚至超出预期的产品需要反复迭代。 - 4.你有没有感到你做的事情可以让别人来做（更有效率）?
没有，团队分工明确，各司其职，对待自己负责的模块工作效率已经足够高。 - 5.有什么经验教训? 如果历史重来一遍, 我们会做什么改进?
初期分配学习时间不是很合理。在时间分配上，如果能够重来一次，在初期分配学习任务的时间会缩短，提前进入实战环节。
变更管理
- 1.每个相关的员工都及时知道了变更的消息?
是的，对于变更会及时通知相关成员。 - 2.我们采用了什么办法决定“推迟”和“必须实现”的功能?
根据功能在整个项目的重要程度。核心功能在alpha版本实现，剩下的完善部分放到beta版本。 - **3.项目的出口条件（Exit Criteria – 什么叫“做好了”）有清晰的定义么?
所有页面整合在一起，通过了各项测试，就“做好了”。 - 4.对于可能的变更是否能制定应急计划?
能。团队支持变更，对于变更能及时定制相应计划。 - 5.员工是否能够有效地处理意料之外的工作请求？
部分员工经验不足，不能独自有效的处理，但是在PM和技术组长的带领下能够有效的应对变更。 - 6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
GitHub的使用能大大提高工作效率，如果能够重来一遍，在项目开始前应该进行相应的GitHub使用培训，减少用QQ传代码的频率。
设计/实现
- 1.设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？
设计工作在alpha冲刺的前三天，由经验丰富的PM完成。设计时间合适，人选合适。 - 2.设计工作有没有碰到模棱两可的情况，团队是如何解决的？
在PM设计过程有遇到模棱两可的情况，团队开会讨论解决。 - 3.团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？
有，团队使用Visual Studio 2017自带的性能测试工具进行测试。这些工具可以很好的帮助我们测试，进行代码规范和debug。 - 4.比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？
最开始的UML文档给出了一个大体的框架，在根据这些框架逐一实现时会做出一定修改甚至重构，这些区别产生的原因是需求的变更以及计划变更。为了项目完整性，我们有及时更新UML文档。 - 5.什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?
照片地理位置解析和登录。在照片信息解析方面，需要对经纬度的格式转换，以及一系列的流程，在这里我们共用了五个接口，目前也没有特别好的解决这个问题，在分析后发现是计算过程精度的丢失，有所改进。登录方面，由于安卓手机的数据没有办法很好地清除，导致用户不满足条件，确能够使用功能（当然无法返回结果）。目前还没有发布，都是团队内部人员在测试，以上就是主要的bug。问题主要在于设计/开发前没有很好地理清逻辑，也有点忽视了这方面。 - 6.代码复审（Code Review）是如何进行的，是否严格执行了代码规范？
代码复审没有很详尽，在程序可运行可读的情况下进行代码复审，没有严格的执行代码规范。 - 7.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
设计很丰满，实现很骨感，在实现的过程中总会出现知识和非知识层次的困扰。如果历史再来一遍，希望在alpha冲刺开始前团队先集中训练。
测试/发布
- 1.团队是否有一个测试计划？为什么没有？
有。团队根据功能图表有详细的测试计划。 - 2.是否进行了正式的验收测试？
还没有，目前功能还没有全部实装，因此还没有进行正式验收测试。 - 3.团队是否有测试工具来帮助测试？
有，团队使用Visual Studio 2017自带的性能测试工具进行测试。 - 4.团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？
目前还没有考虑测量软件的效能，会在beta版本中考虑。 - 5.在发布的过程中发现了哪些意外问题？
前端的测试并不理想。GitHub操作不注意导致用户信息泄露。 - 6.我们学到了什么? 如果历史重来一遍, 我们会做什么改进?
辅助工具的使用不熟练，如果能重来增强GitHub的使用，熟悉VS2017、LoadRunner等负载测试工具的使用.
团队的角色，管理，合作
- 1.团队的每个角色是如何确定的，是不是人尽其才？
团队角色由队员自己申报，再由PM根据情况调整。每个队友得到符合其意愿的职务，工作效率合格，算是人尽其才吧。 - 2.团队成员之间有互相帮助么？
有的，团队合作总会出现问题，不管是技术上的还是非技术上的，团队分为几个小组，每个小组在执行任务时遇到问题相互讨论，互相帮助解决。 - 3.当出现项目管理、合作方面的问题时，团队成员如何解决问题？
团队合作融洽，很少出现合作问题，当出现问题时，听PM安排。没有什么是合作解决不了的问题，如果有，那就一瓶奶茶搞定。 - 每个成员明确公开地表示对成员帮助的感谢
我感谢UI组长（俞凯欣）对我的帮助， 因为某个具体的事情:原先我对UI设计及各种P图软件，UI设计软件，设计方法一窍不通，在他的帮助下我觉得学到了很多东西。
总结
- 1.你觉得团队目前的状态属于CMM/CMMI中的哪个档次？
我们团队对团队协作开发经验比较欠缺，目前还处于磨合阶段吧。所以我们前端后端基本上都处于初始级别，部分达到可重复级，目前也在积极向第一组学习，争取之后能达到可重复级以上。 - 2.你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
我觉得团队目前还处于磨合的阶段。首先，大部分成员对团队开发都是0经验，也没有很好的团队开发意识。其次，由于客户课程的原因，我们并没有很多的时间能够坐在一起面对面编程（感觉这点第六组特别棒，积极向他们学习）。目前团队也慢慢开始都有了团队开发的意识，团队成员的开发风格、代码风格也在慢慢统一（这点觉得第一组做得特别棒，在被迫手动合并代码，帮成员写对接部分时在好几份代码风格差异较大的代码中游走，真的太难受了）。 - 3.你觉得团队在这个里程碑相比前一个里程碑有什么改进?
这阶段的任务可以说是比较重吧，时间也比较紧迫，团队的积极性提升了不少。团队也慢慢越来越像一个团队，整体团队意识也有所增强。 4.你觉得目前最需要改进的一个方面是什么?
团队协作能力，这方面提升了会很大幅度地提升工作效率，很多问题也都会跟着解决。5.对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
敏捷原则：
1.1 简单----使未完成的工作最大化的艺术----是根本的。
1.2敏捷过程提可持续的开发速度。责任人、开发者和用户应该能够保持一个长期的、恒定的开发速度
1.3 不断地关注优秀的技能和好的设计会增强敏捷能力
1.4 即使到了开发的后期，也欢迎改变需求。敏捷过程利用变化来为客户创造竞争优势
答辩总结
【团队中个人的贡献比例】
| 031602428 | 苏路明 | 博客撰写，整合前端，对接后端，测试，改善原型 | 12 |
| 031602401 | 陈瀚霖 | 首页地图页面开发，照片显示页面开发 | 10 |
| 031602406 | 程晓宏 | 自动生成旅游故事算法、设计，接口开发，事后博客撰写 | 10 |
| 031602438 | 叶一帆 | 后端接口设计，接口开发，对接前端，测试 | 14 |
| 031602407 | 何家健 | 用户中心、反馈页面开发，短故事模板选择页面开发 | 9 |
| 031602410 | 黄海潮 | 记录方式相关页面开发 | 9 |
| 031602429 | 王锦扬 | 短故事模板设计，评分表设计、记录 | 7 |
| 031602442 | 郑孔宇 | 可视化地图开发 | 10 |
| 031602439 | 俞凯欣 | 短故事模板设计，评分表设计、记录，视频录制 | 8 |
| 031602421 | 林世杰 | 自动生成旅游故事算法、设计，接口开发，PPT制作、演讲 | 11 |
【评审表格设计】
【答辩总结】
评分：去除最高分（83）最低分（73）后的平均分：76.71
1 爸爸饿了 73 2 拖鞋旅游队 81 3 彳艮彳亍 78 4 火箭少男100 75 5 起床一起肝活队 83 6 404 Note Found 79 7 第三视角 77 8 小白吃 74 9 我头发呢 73
【问题&回答】
【其他组提出的意见和建议】
- 后期要加强功能的完善
- 建议使用 git 进行版本管理
- UI界面需要美化
- 优化 UI 以及部分操作逻辑，但软件更易用。
- 对现有功能进行完善并添加新的功能。
- 可以尝试通过接口其他方式实现其他风格的转化，用户参与度上对签到可以采用奖励制
- 希望能够?先考虑优化一下大众群体及一些重度用户户的用户户体验， 比如如柯老师这样的万图用户。
- 在地图的标注上面可以采取更加友好美观的界面互动形式。
- 加快项目推进。
- 下次可以着重讲解功能实现进度
个人部分
- 个人PSP
| PSP2.1 | Personal Software Process Stages | 预估耗时（分钟） | 实际耗时（分钟） |
| Planning | 计划 | 15 | 25 |
| · Estimate | · 估计这个任务需要多少时间 | 220 | 350 |
| · Development | 开发 | 10 | 10 |
| · Analysis | · 需求分析 (包括学习新技术) | 10 | 10 |
| · Design Spec | · 生成设计文档 | 30 | 30 |
| · Design Review | · 设计复审 (和同事审核设计文档) | 15 | 20 |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | 0 | 0 |
| · Design | · 具体设计 | 40 | 60 |
| · Coding | · 具体编码 | 0 | 0 |
| · Code Review | · 代码复审 | 0 | 0 |
| · Test | · 测试（自我测试，修改代码，提交修改） | 0 | 0 |
| · Reporting | 报告 | 0 | 0 |
| · Test Report | · 测试报告 | 0 | 0 |
| · Size Measurement | · 计算工作量 | 0 | 0 |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 10 | 10 |
| 合计 | 515 |
【学习进度条】
| 第N周 | 新增代码(行) | 累计代码(行) | 本周学习耗时(小时) | 累计学习耗时(小时) | 重要成长 |
| 1 | 0 | 0 | 18.5 | 18.5 | 熟悉Axure的使用方法、对软件的原型设计有了更深刻的理解 |
| 2 | 113 | 113 | 28.5 | 47 | 对算法的构思有更多的了解 |
| 3 | 106 | 219 | 15 | 62 | 加深掌握了Axure的使用，学会了使用NABCD模型进行需求分析 |
| 4 | 211 | 430 | 18 | 80 | 认识了原型设计的重要性，学会部分原型设计的技能 |
| 5 | 252 | 692 | 12 | 92 | 进行logo，原型的设计与修改 |
| 6 | 50 | 742 | 10 | 102 | logo，原型初步设计完成 |
| 7 | 190 | 932 | 30 | 132 | logo，原型完善 |
| 8 | 0 | 932 | 25 | 157 | 海报设计，logo，原型完善 |
| 9 | 200 | 1132 | 5 | 162 | logo，原型继续完善 |
| 10 | 100 | 1232 | 3 | 165 | 短故事模板设计 |