UltraSoft - Beta - Postmortem事后分析

UltraSoft - Beta - PostMORTEM

设想和目标

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

   解决的问题和定义都在[软软软]功能规格说明书和Beta阶段的计划中详细说明了，都有典型用户和典型场景的清晰描述。

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

   原计划的核心功能都完成了，非核心功能差两个，分别是群组功能和设置头像功能，由于冲刺后期有计算机网络实验和计算机网络安全等课程结课导致开发进度降了下来。

   我们的Web应用一直在交付，每个核心功能都立即上线。

   原计划是达到300个翻倍，但是和学校公众号的老师交流过后，认为我们使用的爬虫技术不太适合大面积推广，小面积内使用最好，所以在周围进行传播，没有预期的使用校内公众号宣传，最后是从Alpha阶段的148人到现在的239人，增长了91个用户。

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

   项目的质量提高了，因为在Beta阶段我们痛定思痛，借鉴其他小组的项目管理，在Gitee上使用issue和pr进行管理，得到的效果非常好，每一个迁入都有迹可循，每一个功能都有issue可循，每一个功能对应的负责人都十分明确，在最后的计算贡献中也起到了非常有用的效果。

   

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

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

   大体上是一样的，因为我们自始至终都是面向用户需求开发，加入了课程的通知和期末考试的提醒，但也砍掉了一些小部分群体用户的需求，比如课程的测试，这是我们小组讨论之后基于需求的重要程度做出的决定，阶段性达成了目标。

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

尽早使用Gitee、Github等成熟完善的项目管理工具，有了项目管理工具之后感受非常不同！

计划

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

   有的，一周的时间做计划，具体见UltraSoft - Beta - 设计与计划。

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

   比如对于想要在这一阶段加入的功能比较多，我们比较功能的重要性，按照用户的优先级排序，征求实际使用产品的用户的建议，比如课程中心的通知和测试，我们最后选了通知，因为通知面向的范围更广，测试面向的用户群体很少。

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

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

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

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

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

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

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

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

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

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

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

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

   拒绝加班，拒绝熬夜

资源

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

   有的，服务器自给自足，也不需要项目资金；技术栈的学习资源丰富，使用的组件Vuetify有清晰的说明文档。

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 中的哪个档次?

  达到了CMMl三级，明确级。在明确级水平上，所有第二级的要求都已经达到，另外，软件组织能够根据自身的特殊情况及自己的标准流程，将这套管理体系与流程予以制度化。这样，软件组织不仅能够在同类项目上成功，也可以在其他项目上成功。科学管理成为软件组织的一种文化，成为软件组织的财富。

  Gitee的项目管理的引入让我们从Alpha阶段的二级跃升到了三级。

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

  创造阶段，大家在基本的需求之外，都对我们的产品和团队有了一份不可割舍的归属感，大家共同为打造一个更好的产品而努力，不需要PM进行督促，自己会按时甚至提前完成任务，还有组员能够主动完成一些在规划阶段没有分配的任务，我们对其他的组员都特别信任，并且大家也会按照我们的团队规范进行自己的开发，在测试完备之后签入主分支，都在为这一个项目付出心血。

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

  团队方面：我们有了更明确的分工和项目管理，而且成果已经展现，大家也更加上心，不需要PM进行督促会自觉完成分配的任务，大家进入了一种齐心协力自治的境界。

  产品方面：实现了Alpha阶段使用用户提出的新需求

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

  站在PM的角度来说，我们组员的各方面都做的已经很满意了，可能需要改进的地方在于文档的及时更新和维护，及时搬运到Gitee进行公开。

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

  • 无论是团队内还是团队间，最有效的沟通方法是面对面的交谈：我们在Beta阶段进行了每日例会，每日进行pr，组员遇到了难题直接在Scrum Meeting后直接留下解答，在Scrum Meeting中提交Pr，不会因为沟通而影响项目的进度
  • 欢迎对需求提出变更 - 即使在项目开发后期，要善于利用需求变更，帮助客户获得竞争优势：我们一开始并没有想到做考试日程的DDL提醒，但是后来在迭代的过程中发现这是用户在期末的重要需求，于是加上了这个特性。

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

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

     继续使用Gitee进行分支的开发，在自己的分支开发后充分测试再PR到主分支进行发布。

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

     后期可以考虑将前后端分成两个仓库，目前虽然已经分离但是依然在一个仓库内。

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

     我们使用的测试工具是mock.path，现阶段已经足够使用，但是后期如果规模更大可能需要考虑其他的测试工具。

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

     Pr和Issue分条列点，对应到负责人，每个人的贡献清晰可见。

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

     目前已经有详细的Log记录，记录用户的登录和同步课程中心的操作。

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

     及时更新前后端链接的API的JSON格式，加入适当的教学文档方便其他人接手我们的项目。

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

     通过了Alpha阶段后，我们的团队已经有了凝聚力和向心力，大家都对这个项目非常上心非常负责，PM的感受特别强烈，从Alpha阶段的每天Push担心项目完成不了到Beta阶段的大家完成自己的任务之后甚至主动来找我领任务，主动开发一些在Beta阶段的设计中没有涉及到的东西，这个我觉得是非常难能可贵的。我们独具特色的采用的shimo文档开发在Beta阶段也被弱化，我认为这是一件好事，因为大家都已经迅速习惯了在Gitee上新建Issue和Pr，有问题直接在项目中解决，我认为这是能够真正说明我们的项目管理确实取得了进步。

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

     1. 在Beta阶段对代码中的冗余部分进行了抽离，从自己的实际体验意识到了行数论是一个很扯的东西，删除了重复的大段逻辑，用一个函数调用形象具体描述之后瞬间清爽
     2. 用户主导，面向用户开发的思想尤为重要：我们的产品就是面向用户的，用户需要什么，我们交付什么
     3. 软件工程不是聚众打码，里面有相互协作，里面有需求分析，里面有项目迭代，里面有成员之间的互助...团队没有凝聚力一个项目很难成功，或者说可能会漏洞百出，因为没有人考虑项目的未来发展，干完这个学期就走人的思想十分可怕，幸好我们团队大家都愿意在这门课中真心付出，并且愿意为之继续开发、继续维护。

在我们的“介绍一下自己吧”——记2020BUAA软工团队介绍和采访中，我们说过：“虽然我们都没有大型的工程经验，是一直拼装起来的军队，但是我们相信通过我们团队的配合一定能够在软件工程这门课中发挥出色，不只是取得成绩，而且能做出像样的、能流传的、实用的项目出来。”，现在一个学期的两次冲刺已经结束，我们的成果也已经展现在了大家的眼前，我认为我们的初心已经达到，我们收获了用户的好评，得到了老师的认可，感觉这个学期最用心的就是这个项目，感觉就像是自己的亲生宝贝一样，从一行行代码到一个个函数到一块块功能到每一个界面，感觉太不可思议了。

说实话在选择这么课程的时候我们也听说了这门课非常难啃，有无数的博客，有个人的项目还有结对的项目还有阶段的迭代，有一次次的评审，其他两位老师的课程压力就没有那么大，也不用博客，也不用迭代，只有最后的评审。但是回过头来感觉这一切值了。在个人博客中我们真正重新认识了自己；在个人项目中我们得到了热身；在结对项目中我们为后面的分离开发做了准备；在时长一个多月的团队开发中我们结实了一群可爱的人，做出了令自己惊叹，令自己感激的产品。

如果下一年有学弟学妹问我：软件工程哪个老师的课好？

我会如实回答：如果你对自己有要求，如果你想这个学期不碌碌无为，如果你想学期结束收获满满，如果你想逼自己一把，选择罗杰、任健老师的班级吧。过程会很痛苦，你会看到别人都在玩的时候你在写博客，你会看到别人开发的时候你在写博客，你会看到别人只开发一次就结束的时候你在写博客，你在开例会，你在Beta阶段开发，但是当你的博客得到了老师的认可，得到了助教的赞赏，得到了《构建之法》作者邹欣老师的点评，得到了轮子哥Vczh对你的提问的亲自回复，得到了《持续行动》《刻意学习》作者Scalers为你特地开账号的留言，你会感觉，这一切都值了。

全组讨论的照片。

BUAA - UltraSoft - 软软软小组 2020春大三下学期的软件工程， 全剧终。

但我们DDLKiller的故事还在继续，不要走开，马上回来