Alpha 冲刺11——总结

拖鞋旅游队团队事后诸葛亮会议

前言

• 队名：拖鞋旅游队
• 组长博客：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安排。没有什么是合作解决不了的问题，如果有，那就一瓶奶茶搞定。
• 每个成员明确公开地表示对成员帮助的感谢
  我感谢开发组长（叶一帆）对我的帮助， 因为某个具体的事情: 在开发过程当中，基本都是我们两个在对接前后端，思考改善程序的逻辑结构。同时也有一个点，他是比较专业的后端开发，改变了我之前对接口功能看法，在对信息安全，数据库安全有了比较大的改进认知。

总结

• 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

【问题&回答】

第一小组的问题：

• Q1:为什么没有使用版本管理工具管理代码？
• A1:我们有使用git工具来管理代码，只是在使用过程当中，多数开发成员对git并不熟悉，没能很好地上手，只好由PM来代替实现。
• Q2:你们要怎么解决UI不够美观的问题？
• A2:我觉得Alpha版本我只专注于做某些部分，所以并没有对所有的界面进行UI改善，我相信全部界面经过UI设计改善后美观程度还可以，在对功能的实现有完全把握的情况下我们才会再去考虑更好地改善UI。
• Q3:你们分工是否不明确？
• A3:我们的团队分工在团队成立之后就比较明确，当然我们也会视任务情况进行再次分配，但是不会改变成员的分工主方向。

第三组的问题

• Q1:地图上的照片定位标记当数量达到一定量时，或许会不方便于用户的查看，出现重叠遮挡的情况，是否有考虑过如何优化呈现形式的想法呢？
• A1:这一问题我们一直有在考虑，现在团队成员也在学习聚合信息，相信在Beta版本我们可以解决这一问题。
• Q2:原本的功能设计中有 h5 等形式的发布，可以细说一下具体的实现方式吗？最终你们的产品整体会是一个怎样的效果？
• A2:H5等形式的发布，是被包含在分享方面。具体的实现方式是使用用户数据生成动态h5页面，用户可分享至朋友圈，理想效果可参考易企秀等。整体效果敬请期待。
• Q3:你们目标中的短故事、文字等的记录，在地图上的标注大概以怎样的形式来展现？
• A3:这部分内容并不会在地图上显示标注，这部分主要是用在用户记录和分享上面。

第四组的问题

• Q1:为什么实现功能偏少呢？
• A1:在课堂上，我们有提到这一部分，看起来我们实现的功能是比较少，但是其中有许多的逻辑结构以及核心功能花费了我们非常多的时间，目前看来我们的计划进度也是符合预期的。
• Q2:开发组进展过慢？
• A2:我觉得我们的开发进度基本上是符合预期的。基本实现了核心功能，也完成了Alpha的任务。

第五组的问题

• Q1:为什么对于之前一次的答辩过程中提到的问题没有考虑全面，只有选择性的解决了部分的问题？
• A1:在此部分我们的主要任务并不在于此，同时我们的考虑也都是经过团队讨论慎重决定，也基本是有理有据的。
• Q2:为什么在展示的过程中，基本上在吹大佬完成了什么工作，其他成员有点太过于放低自我？
• A2:我们的主讲人可能滑稽感染能力较强，导致你们产生这方面的误解，其实我们的成员对分配的任务（还是比较均衡的）完成度还是比较好的。
• Q3:在小程序上，美工方面也是有所不足，上传照片方面也是有所受限，怎么解决？
• A3:美工方面我们在完成功能的方面才会考虑进一步改善，上传照片方面我们目前没有很好的办法，但是团队讨论也有个比较好的权衡办法。

第六组的问题

• Q1:为什么旅游故事没有展示？
• A1:因为Alpha版本我们分配成员设计旅游故事生成算法，相关方面的功能实现是安排在Beta阶段。
• Q2:个人感觉旅游软件APP更好，有没有考虑？
• A2:这方面竞争较大，同时与我们的定位和挖掘的需求有较大的差异，目前不会考虑。
• Q3:进度有点慢？
• A3:我们的能力比较有限，我觉得我们的开发进度基本上是符合预期的。基本实现了核心功能，也完成了Alpha的任务。

第七组的问题

• Q1:怎么提高UI设计？
• A1:我觉得Alpha版本我只专注于做某些部分，所以并没有对所有的界面进行UI改善，我相信全部界面经过UI设计改善后美观程度还可以，在对功能的实现有完全把握的情况下我们才会再去考虑更好地改善UI。
• Q2:通过这次展示感觉组内分工不明确？
• A2:我们的团队分工在团队成立之后就比较明确，当然我们也会视任务情况进行再次分配，但是不会改变成员的分工主方向。
• Q3:开发进度较慢，完成度较低是为什么？
• A3:我们的能力比较有限，我觉得我们的开发进度基本上是符合预期的。基本实现了核心功能，也完成了Alpha的任务。
• Q4:是否还存在git使用问题？
• A4:团队成员目前对git使用还不够熟悉，还存在点问题，我们成员也在积极学习，相信在Beta版本我们可以较好地使用git。

第八组的问题

• Q1:技术上的问题怎么解决？还有待改善
• A1:狂啃资料，爆肝。

第九组的问题

• Q1:怎么解决UI界面不够美观，有些按钮显得不和谐问题？
• A1:我觉得Alpha版本我只专注于做某些部分，所以并没有对所有的界面进行UI改善，我相信全部界面经过UI设计改善后美观程度还可以，在对功能的实现有完全把握的情况下我们才会再去考虑更好地改善UI。
• Q2:为什么有些界面过于简陋看不出功能是否可用？
• A2:我觉得Alpha版本我只专注于做某些部分，所以部分界面只完成了前端部分，还没有与后端对接。
• Q3:进度有点慢？
• A3:我们的能力比较有限，我觉得我们的开发进度基本上是符合预期的。基本实现了核心功能，也完成了Alpha的任务。

【其他组提出的意见和建议】

• 后期要加强功能的完善
• 建议使用 git 进行版本管理
• UI界面需要美化
• 优化 UI 以及部分操作逻辑，但软件更易用。
• 对现有功能进行完善并添加新的功能。
• 可以尝试通过接口其他方式实现其他风格的转化，用户参与度上对签到可以采用奖励制
• 希望能够?先考虑优化一下大众群体及一些重度用户户的用户户体验， 比如如柯老师这样的万图用户。
• 在地图的标注上面可以采取更加友好美观的界面互动形式。
• 加快项目推进。
• 下次可以着重讲解功能实现进度

个人部分

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	5	5
· Estimate	· 估计这个任务需要多少时间	120	150
· Development	开发	10	10
· Analysis	· 需求分析 (包括学习新技术)	10	10
· Design Spec	· 生成设计文档	20	30
· Design Review	· 设计复审 (和同事审核设计文档)	20	20
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	0	0
· Design	· 具体设计	50	80
· 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	· 事后总结, 并提出过程改进计划	5	5
	合计		150

• 个人学习进度条

第N周	新增代码	累计代码	本周学习时间	累计学习时间(小时)	重要成长
1	200	200	5	5	对Axure的学习
5	200	400	12	17	html,css的学习
7	400	800	8	25	对c中各种函数的学习
8	500	1300	8	33	微信web开发者工具的使用,css,js的学习
12	200	1500	6	39	wxml,wxss的学习和使用
13	300	1800	6	45	微信中js的运用和微信接口的调用

• 个人体会

  感谢

  • 我感谢叶一帆同学对我的帮助，由于我以前并没有开发过任何程序，对此并不是很了解，一帆同学发给我许多学习资料，以及在前后端接口对接上给予了我许多帮助。

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

  • 我学会了许多东西例如微信小程序中所需要用的wxml,wxss,js以及echart对地图的绘制。如果重来一遍我希望能够提高自己学习的效率。

  你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次？

  • 我觉得我们还只处于第二阶段。

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

  • 我觉得我们团队目前处于磨合阶段。

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

  • 对自己所开发的产品有更多的了解，对微信小程序的开发有更深的理解。

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

  • 对UI界面的设计和统一风格。

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

  • 我认为我们组做得最好的几个原则有：敏捷流程应能保持可持续的发展。 领导, 团队和用户应该能按照目前步调持续合作下去。我们每天都在为产品进行更新与修复bug；只有不断关注技术和设计才能越来越敏捷。我们每天都在学习新的技术以及更好的UI界面设计；无论团队内外，面对面的交流始终是最有效的沟通方式。我们经常互相沟通来更加方便的对接前后端。