UltraSoft - Beta - Postmortem事后分析

Posted 2020-12-12 ultrasoft

UltraSoft - Beta - PostMORTEM

设想和目标

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

   解决的问题和定义都在Alpha阶段的计划和Beta阶段的计划中详细说明了，都有典型用户和典型场景的清晰描述。

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

   差俩，由于啥没完成：social Gravatar 但都不是critical

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

   质量提高了，项目管理，gitee清晰的issue和pr

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

   239个，第一阶段是148个，增加了90个，感觉足够了。

   一样，面向用户需求开发，加入了课程的通知和考试的题型

   阶段性达成目标

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

早点上项目管理

计划

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

   有的，一周的时间做计划

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

   比较功能，按照用户的优先级排序，征求实际使用产品的用户的建议

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

   没做完，在计划阶段还没有烤漆安排，但是在Beta冲刺的最后阶段有诸如计算机网络实验、计算机网络安全等不进入烤漆的大作业需要完成，且工作量很大，所以有几天的时间进展不多，导致两个非核心功能没有完成。

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

   产品角度：没有，因为我们的需求都是根据用户的反馈进行选择筛选的，所以都是有需求的，比如用户需求不是非常强烈的测验功能砍去

   开发角度：正式体验了项目管理，使用Gitee进行团队协作，非常有意义

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

   有的，每一项任务都需要经过完善的测试才会纳入到主分支，并且我们的产品的功能相互之间是相互分离的，大多是查询任务，易于验证正确性的，当正确性满足时即可以交付。

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

   意外在于有几门不进入烤漆的课程，如计算机网络实验、计算机网络安全等课程的考核与Beta冲刺相撞，而且难度很大，导致考核的几天开发进度明显减缓

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

   本来没有设置，但是由于计算机网络实验、计算机网络安全等课程的考核， 被动加入了缓冲区，在缓冲区内没有大家的进度比较慢，所以之前没有交付的功能可以赶上。

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

   拒绝加班

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

早点上项目管理，项目管理中的issue可以简单明了看出当前未完成任务和项目进度

资源

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

   有的，服务器自给自足，也不需要项目资金

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

   粗略根据项目粒度的大小，如增加新的板块——消息中心，还是增加旧有板块中新的功能——课程中心的课程通知，明显两者的任务量是不一样的，在预估的时候考虑到组员们其他课程的学习，都进行了放大的预估，大多数计划都提前完成了。

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

   相当够，由于模版选的好，并没有特别重的美工设计和文案工作量。

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

   因为我们在Alpha阶段已经有了明确的分工，大家都是选择了自己擅长的部分，如前端开发，所以理论上来讲已经达到了效率的最大化。

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

资源方面没有什么需要改进的了。

变更管理

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

   有微信群的管理和通知非常及时，有时候还有PM私聊确认的情况，所以每个相关的组员都能够及时知道变更。

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

   是否影响用户的使用。如头像功能并不会影响用户选择我们产品的决定，所以进行了推迟；但是课程中心中的课程通知，是用户所需要的，所以属于必须实现。

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

   我们的项目不是App而是Web应用，所以不需要人为发布，时刻运行，用户一直在体验最新版，所以这个出口条件是时时刻刻都需要满足的，因此我就想用这三点来概括一下：

   • 服务器运行正常：提供Web服务的基础
   • 核心功能正常：用户能够登陆就能够使用功能
   • 新增功能对原有功能无影响：这是面向我们开发团队，要求了我们增加新功能前需要进行充分的测试，不仅是对新功能的测试，还有对原有功能的回归测试

   我认为做到这三点，持续部署，持续发布，就已经可以出口了。

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

   应急计划面对的问题包括两类：

   1. 新功能的问题：新功能必须经过严格的测试并在其他的服务器上运行成功才加入到主分支中，通过加入前的测试保证不会出现需要应急的场面；

   2. 旧功能的问题：如果新功能的加入或者旧功能出现了问题，这里以由于课程网站的改版导致爬虫的验证出现的问题为例：

      1. 或立刻修复不影响用户的使用（变更爬虫的代码以适应新的网站布局）
      2. 或临时取消该功能等待修复（暂停同步课程中心两天等待测试人员修复）

      我们大多数情况下都是立刻修复，以免降低用户的印象分。

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

   能够处理，比如消息中心的模块就是在后期临时添加的，组员能够非常及时的完成需求。

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

设计/实现

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

   在正式开发阶段前一周PM为主、组员为辅完成，PM根据调查用户的反馈，用户需要什么，我们开发什么，其实组员也属于我们的用户，都是用户需求导向来决定实现什么。

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

   因为指定需求的时候十分明确，具体到实现之后用户使用的场景，所以没有遇到模棱两可的情况。

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

   有单元测试，具体在测试报告中有呈现。

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

   后端产生的Bug居多，前端也存在但是比较少，主要是由于课程中心的爬虫逻辑比较复杂容易出bug，而且在新增的增加考试日程中，对于教务系统的爬取逻辑有不同，需要改变登陆的方式，但都是在开发过程中出现的bug，都是解决了才发布的。

   发布后有一次发现了比较严重的bug，就是在增加重复日程的特性时，没有考虑快速添加日程模块的修改，导致快速创建日程中会因为缺少重复日程字段创建失败，但是我们及时意识到了，说明了每个新功能的上线都应该进行回归测试。

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

   ”同行复审“制度，前端复审前端代码，后端复审后端代码，代码清晰易读，保证负责的组员在离职后新的接手人可以很快上手，不会存在阅读代码晦涩难懂的情况。

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

测试/发布

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

   有测试计划，具体在测试报告中有呈现。

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

   有验收时的代码整体覆盖测试，具体在测试报告中有呈现。

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

   很多团队用大量低效率的手动测试，请提出改进计划：至少一个方面的测试要用自动化的测试工具，自动化的测试结果报告，比较测试结果的差异，等等。

   测试工具以及详细内容见偷梁换柱：使用mock.patch辅助python单元测试。

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

   我们有同步课程信息的记录耗时日志，可以看出软件的效能还是十分稳定的：

   

   保持在1～3分钟可以接受的范围内。

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

   暂时没有意外问题。

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

团队的角色，管理，合作

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

   有根据自己的实际经验选择的，没有经验的同学根据自己的兴趣进行了选择，PM由idea的提出者担任，因为对项目整体最为了解和熟悉，从结果上来看人尽其才。

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

   前端同学之间有相互探讨疑难问题，有bug自己解决不了有组内其他同学帮忙，还有帮助进度慢的同学进行开发；前后端之间也有相互帮助，关于接口的规定和测试时的相互帮助。

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

   我们团队成员的相处都非常融洽，没有出现这方面问题，如果出现由PM进行最后的决定。

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

   组员	感谢
   Mistariano	感谢组里的每一个小伙伴带我愉快走完软工后半程。印象比较深的是接秘钥对时fmh深夜了还在推代码解决遇到的问题，并对新接的代码做了完善的测试，合作非常愉快；接找回密码时和lzh同学沟通接口时做了很多轮修改，lzh也非常耐心地和我交流，最终前后端配合实现了功能。此外其他同学也在组会时积极解答我的各种问题。我想我们的项目之所以取得成功，很大一部分源自我们紧密的团队配合及融洽的团队氛围——这是大家共同努力的结果。再次向每个人表示感谢！
   Monster	感谢雪灿能抽出时间和我一起进行前后端接口的测试，并且和我一起debug，让我们的开发进程快了很多！
   LiuZH	感谢全组队友互帮互助，合作愉快！
   王FUJI	感谢课程组给我这次机会，很开心和团队里的大家一起探索软件工程；感谢队友fmh、lqq、lzh、yjc、hdl给予我的帮助还有一起深夜打码debug的欢乐（虽然如此，但是希望未来熬夜这种事情还有少一点比较好，hh），特别要感谢fmh、lzh带我入门，在前端开发等方面给了我非常大的帮助！
   Kkkk	lqq的兢兢业业恪尽职守夜以继日孜孜不倦
   CookieLau	第一次做PM，非常高兴遇到这一群小伙伴，我们一起熬过夜，一起改过bug，一起分析过需求，整个队伍中没有一个人拖后腿，大家都非常认真完成布置的任务，非常感谢每一个付出的人，我觉得缺少了每一个人都不能让我们的项目进展如此顺利，最后的效果如此华丽，受到大家的好评。还要感谢转走的Dz同学，他在Alpha阶段也为DDLKiller做出了不可磨灭的贡献，每一个人都是最棒的！

总结

• 你觉得团队目前的状态属于 CMM/CMMI 中的哪个档次?
• 你觉得团队目前处于 萌芽/磨合/规范/创造 阶段的哪一个阶段?
• 你觉得团队在这个里程碑相比前一个里程碑有什么改进?
• 你觉得目前最需要改进的一个方面是什么?
• 对照敏捷开发的原则, 你觉得你们小组做得最好的是哪几个原则? 请列出具体的事例。
• 正如我们前面提到的， 软件的质量 = 程序的质量 + 软件工程的质量，那团队在下一阶段应该如何提高软件工程的质量呢？

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

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

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

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

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

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

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

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

发布博客时，要附上全组讨论的照片。