UltraSoft - Alpha - Postmortem 事后分析

Alpha阶段 Postmortem会议

设想和目标

  1. 我们的软件要解决什么问题？是否定义得很清楚？是否对典型用户和典型场景有清晰的描述？

    主要是解决DDL提醒功能的问题，定义的比较清楚，对典型用户和典型场景有比较清晰的描述。

  2. 我们达到目标了么（原计划的功能做到了几个？ 按照原计划交付时间交付了么？ 原计划达到的用户数量达到了么?)

    核心功能都完成了，没有完成的消息中心不属于核心功能且开发阶段发现并不太符合核心需求，遂取消。比计划交付的时间晚了5天，用户数量在2天内已经达到。

  3. 和上一个阶段相比，团队软件工程的质量提高了么？ 在什么地方有提高，具体提高了多少，如何衡量的？

    本次开发是Alpha开发，因此无可用的对比。

  4. 用户量, 用户对重要功能的接受程度和我们事先的预想一致么? 我们离目标更近了么?

    用户量基本达到实现预想的数量。用户对重要功能（同步课程中心DDL和资源、自定义Task）的接受程度与预想的比较接近，自定义Task的用户数量较少，可能是由于现在放假的原因。

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

    发布时间较晚，没有如期发布，虽然在短时间内达到了最初设定的用户量目标，但是由于发布时间短没有收集到很多反馈意见。如果历史重来我们会选择在初期就进行前后端的连接，这样在后期开发的过程中减少因前后端连接而带来的阻塞时间。

计划

  1. 是否有充足的时间来做计划?

    有，课程组提供了一周的时间做计划，我们制定了明确的目标和产品原型，这对我们在Alpha阶段的开发起到了至关重要的作用，我们直接按照产品原型按计划进行开发即可。

  2. 团队在计划阶段是如何解决同事们对于计划的不同意见的？

    一是在开Scrum Meeting讨论的时候提出，小组内成员共同协商，综合前端、后端、PM的意见最终决定；二是直接在微信群提出，直接就开一个微信的语音会议进行商讨决定。

  3. 你原计划的工作是否最后都做完了? 如果有没做完的，为什么?

    计划的工作大部分做完了，小部分由于技术原因如动态加密留到Beta阶段再实现，但这不影响用户核心功能的使用。

    消息中心部分经过讨论认为用处不大，因此决定现阶段不实现，看后期的需求。

  4. 有没有发现你做了一些事后看来没必要或没多大价值的事?

    前期学习技术的时间分配的过多，这些技术有些用不上，有些要用的时候忘记了还需要回去看，造成了进度的耽搁，应该今早开始动键盘。

  5. 是否每一项任务都有清楚定义和衡量的交付件?

    开始时计划过于笼统，因为分割的feature太大，如一个界面的开发，因此很难确定具体的交付件。后面到实现阶段，对feature进行了进一步的细化，细化到一个界面里的按钮和点击按钮之后响应的事件，这时的交付件就明确多了，如某个页面、某个按钮能正常使用等。

  6. 是否项目的整个过程都按照计划进行，项目出了什么意外？有什么风险是当时没有估计到的，为什么没有估计到?

    计划时没有估计前后端连接的任务量，造成了上线时间严重拖后。这是由于大家都没有前后端连接的经验，没有预料到连接起来的任务量会那么大。

  7. 在计划中有没有留下缓冲区，缓冲区有作用么?

    计划中没有留下缓冲区，而且由于我们对课程组的时间线理解有偏差，导致最后时间非常紧张。

  8. 将来的计划会做什么修改？（例如：缓冲区的定义，加班）

    1. 考虑增加缓冲区的时间，留给测试多一些时间。
    2. 将计划变得更具体，交付件更明确。

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

    开始的计划需要细化，每个人的任务、交付件都需要明确，否则难以衡量组内成员的进度。

资源

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

    学习资源（如前后端的教程）这部分网上还是相当丰富的，但服务器资源就相对匮乏了，由于资金有限，我们自己申请的阿里云服务器性能较差，在使用VSCode多人协作时经常卡死。

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

    时间和资源在一开始通过任务的size进行估计，但由于计划中大大低估了前后端连接和部署到服务器上所需的时间，因此计划的精度有限。

  3. 测试的时间，人力和软件/硬件资源是否足够? 对于那些不需要编程的资源 (美工设计/文案)是否低估难度?

    如果按照正常发布的时间线来看，测试的时间是完全不够的。但出于程序可用性的考虑，我们还是进行了比较充足的测试，因此发布时间也拖后了几天。对于美工和文案等资源，我们组有专门负责这两部分的成员，因此这部分没有造成大的困难。

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

    这部分暂时没有感觉，我们组员做的事情都是比较难交给外面去做的。

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

    应该给测试留出更加充分的时间，这样既能保证测试的充足，也能基本保证项目在发布日期之前上线。

变更管理

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

    基本能及时知道。如果是比较简单、笼统的变更消息会直接在微信群中通知所有人；如果涉及到具体文档的修改，会直接在GitHub上修改，但这部分的修改有时候并不及时。

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

    主要采用开会讨论的方式，大家一起决定哪些功能可以推迟，哪些必须实现。

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

    出口条件在规格说明书中有着明确的规定，在Github的issue中也对每个模块列有详细的验收标准。

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

    暂时没有应急计划。

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

    可以，我们的组员都非常乐意帮助别人debug，或是增加一些必要的需求等。

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

    对于和前后端关联密切的api和json格式的修改，我们应该更加及时地签入GitHub文档中，并通知组员有改动，防止后面出现接口版本不统一的问题。

设计/实现

  1. 设计工作在什么时候，由谁来完成的？是合适的时间，合适的人么？

    设计是在组员都学完各自的前后端教程后，由PM组织大家开会共同协商的。设计时间和人员恰当。

  2. 设计工作有没有碰到模棱两可的情况，团队是如何解决的？

    遇到过模棱两可的情况，仍然是由PM组织大家开会协商解决。

  3. 团队是否运用单元测试（unit test），测试驱动的开发（TDD）、UML, 或者其他工具来帮助设计和实现？这些工具有效么？ 比较项目开始的 UML 文档和现在的状态有什么区别？这些区别如何产生的？是否要更新 UML 文档？

    我们没有用到UML。测试主要是在前后端连接后进行功能上的测试。

  4. 什么功能产生的Bug最多，为什么？在发布之后发现了什么重要的bug? 为什么我们在设计/开发的时候没有想到这些情况?

    课程中心的爬虫产生的Bug最多，主要是由于课程中心网站的结构、目录结构过于混乱，且每个老师的发布格式不一，导致非常难对所有可能出现的情况进行判断。发布之后又发现激活邮件的链接错误、Bug反馈按钮没有实现等，这是由于Bug反馈按钮的所在页面一开始没有商量好的原因。

  5. 代码复审（Code Review）是如何进行的，是否严格执行了代码规范？

    Code Review主要是通过类似“结对编程”的方式实现的，即正在编程的组员将他的屏幕共享出来，大家在他编写的过程中进行Code Review，这样做还是找到了很多Bug的，大家的编程习惯都很好，严格执行了代码规范。

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

    前后端链接和部署到服务器上的过程比想象的要困难很多，在Beta阶段一定要给这部分留出足够的时间。

测试/发布

  1. 团队是否有一个测试计划？为什么没有？

    测试计划分为两个部分：

    1. 在前后端连接前进行单独的分开测试，前端使用mock进行模拟数据，后端使用requests模拟请求。
    2. 在前后端连接完之后进行整体功能的测试。

  2. 是否进行了正式的验收测试？

    进行了，在上线之前组员们一起进行了验收测试，每个组员都实际地走过完整的从注册到每一个界面和按钮的使用流程，做到自己发现bug。

  3. 团队是否有测试工具来帮助测试？

    前端通过mock模拟后端数据，进行api的调用和测试；后端使用httpie制造请求，进行后端的测试。

  4. 团队是如何测量并跟踪软件的效能的？从软件实际运行的结果来看，这些测试工作有用么？应该有哪些改进？

    主要是通过服务器的响应速度来评判软件的效能，这是用户最能直观感受到的指标，现在看来评估得还是比较准确的。

  5. 在发布的过程中发现了哪些意外问题？

    发布的过程中又发现了几个关于爬虫的小Bug，发布之后也遇到了激活邮箱链接错误等Bug。

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

    在每次变更代码之后再进行一次完成的测试流程是非常必要的。由于我们的注册邮件使用了emoji等图标，导致在使用vim修改代码的时候出现了字符显示的问题，进而导致我们没有发现注册连接被误改，导致有的同学无法收到验证码。如果我们在修改完代码之后自己再走一遍注册流程可以避免这个bug，所以永远不要相信自己的代码 😃

团队的角色，管理，合作

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

    每个人的角色基本遵循自己的意愿进行分配的，之前有前端开发经验的人去了前端，有美工经验的人进行设计，做到了人尽其才。

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

    当然有，前后端有经验的组员会分别指导没有经验的组员。

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

    如果是简单的问题可以直接和PM沟通，如果问题比较复杂、涉及的方面较多，则需要开Scrum Meeting解决。

  4. 每个成员明确公开地表示对成员帮助的感谢 （并且写在各自的博客里）：

    • Monster: 我感谢曲奇对我的帮助，他在我负责的内容（如设置注册激活链接）遇到问题时，和我一起查找资料并解决问题，最终实现了这个功能。
    • Dz: 感谢曲奇和久春，在后端开发中为我解答了许多问题并提供了很多帮助，在功能和设计上进行了多次的交流以取得更好的实现效果。
    • LiuZH: fmhnb 帮我de玄学bug，教我实现前后端连接，wxc 教我使用xshell等，曲奇 给我提出UI设计上更好的建议，push我前进
    • 王FUJI: CookieLau、fmh、lzh、yjc、dz，多谢各位的耐心和帮助
    • fmh(kkkkkk): CookieLau全能nb在线陪聊nb！wxc美工nb！
    • CookieLau:
      • 感谢fmh，陪我度过前后端连接的几个夜晚和一起DE了数不清、道不明的BUG
      • 感谢wxc，提升了整个项目的艺术水平
      • 感谢LiuZH，负责前端最核心的开发工作
      • 感谢Dz，在设计数据库的字段方面做出了非常重大的贡献
      • 感谢Monster，总是能帮助我实现一些细小而又重要的功能，也是我在写博客的时候的好帮手
      • 感谢所有的组员，对你们这个小白组长的不离不弃~

总结:

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

    目前处于CMMI二级，即管理级。组员能够遵守既定的规划和流程，并且权责到人。

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

    处于规范阶段，大家遵循规范和领导，互相帮助，共同进行项目的开发。

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

    大家的交付时间经常是压线交付的，如果能稍微提前交付，就能有更多的测试和缓冲时间了。

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

    我认为我们在组员面对面沟通这一点做的最好，当然现在由于疫情的原因，我们的“面对面”只能是通过腾讯会议的方式实现。我们在前后端交互的过程中，有时会有前后端有部分不统一的情况，此时如果问题严重，我们会开一个小会，只要求负责这部分的组员参加，通过共享屏幕的方式来讨论并消除分歧，这样做提高了效率。此外，我们组还做到了类似“多人结对编程”的模式，即一个人开着屏幕共享写代码，其他人在旁边为其做代码审查，这样做将结对编程的优点带到了小组合作中，提高了编程的效率和正确性。、

  5. 正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

    1. 代码管理的质量具体应该如何提高？ 代码复审和代码规范的质量应该如何提高？

      使用GitHub或是Gitee进行代码版本的管理，每个人及时将自己的进度更新到自己的branch上。在每个人的代码交付前，进行代码复审和代码规范的审查，通过了再上线。

    2. 整个程序的架构如何具体提高？ 如何通过重构等方法提高质量，如何衡量质量的提高？

      我们组是新提出的项目，并且采用已有的开源框架进行搭建，因此架构是比较难提高的。

    3. 其它软件工具的应用，应该如何提高？

      用好测试工具，例如进行充分的单元测试等。

    4. 项目管理有哪些具体的提高？

      项目进展应该及时签入代码仓库，各种文档（规格说明书、api接口、json格式）等有变动也要及时push到仓库。

    5. 项目跟踪用户数据方面，计划要提高什么地方？例如你们是如何知道每日/周活跃用户等数据的？

      目前在统计注册用户数，由于我们的项目主打的是提醒功能，用日活跃用户这样的指标衡量并不妥当。可以通过后台统计创建Task的数量、发送提醒邮件的数量来估计活跃用户的数量。

    6. 项目文档的质量如何提高？

      文档内容要及时更新，如技术文档中对于api和json格式的规定等内容。

    7. 对于人的领导和管理， 有什么具体可以改进的地方？ 请看《构建之法》关于PM、绩效考核的章节， 或者 《人件》等参考书

      CookieLau: 作为我们软软软团队的PM，我发自内心地感觉通过Alpha阶段我成长了许多，从一个PM小白到如今的入门PM的模样。就像《构建之法》的9.5中所言，成为一个合格的PM，需要具备哪些能力？观察、管理、做出重要决策、指引团队方向、扎实的专业能力、自省的能力...... 毫不忌讳地说，在开始的阶段我确实没有做到位，对团队的成员进行放养的策略，让大家自己管理自己，每天向我汇报，也没有核实汇报成果，这就导致了出现团队没有动力、进展缓慢的情况。在第一周之后我也意识到了这一点，开始每晚的例会，对前后端的工作进度进行审核与控制，加强了团队的沟通，将项目的进度提了起来。在后期的时候，确实考察到了我做出重要决策和扎实的专业能力的方面，我需要进行整个项目的部署和主导前后端的连接，逼迫我成为一个全栈工程师，每天与前端的同学进行频繁甚至全天的交流，顶着逾期的压力将进度向前推进，在遇到最难最麻烦的bug的时候也需要PM出来决定如何去做，是继续改还是删还是换。感谢我的团队给我这样一个机会做PM，我如今依然有需要改进的地方，还需要提升自己的专业水平才能站在更高的角度去思考更长远的问题，还需要加强团队成员之间的沟通，不过目前非常庆幸的是我们已经找到了属于自己的开发的模式，按照整个模式进行开发我相信我们在Beta会做得更好。

    8. 对于软件工程的理论，规律有什么心得体会或不同意见？ 请看阅读作业。 (这个作业的期中阅读)

      一直都认为软件工程是一门“大家在一起打代码”的课，但实际做下来之后，发现除了代码之外，还有很多东西。最重要的就是文档了，如果文档不规范不准确不及时更新，那么就可能造成前后端对相应接口的调用和实现不一致，导致后面连接是出现很多问题。

      此外，PM如何领导成员、如何激励成员也是一个问题，一个小组只有在负责任的PM的领导下，才能正确高效地完成任务。

全组讨论的照片：

img

Alpha α 完结撒花，感谢软软软所有成员的辛勤付出
Beta β 还在不远处等着我们，DDL Killer故事还将继续

To Be Continued...

posted @ 2020-05-08 22:40  BUAA软软软件工程小队  阅读(236)  评论(2)  编辑  收藏  举报