[软工顶级理解组] Alpha阶段事后分析

目录

• 设想和目标
• 计划
• 资源
• 变更管理
• 设计/实现
• 测试/发布
• 团队的角色，管理，合作
• 总结
• 质量提高
• 会议截图

设想和目标

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

  我们的App主要解决的是，北航学生每次查询课表、空教室、成绩或是课程中心作业时，都需要经历繁琐的过程，如打开微信，搜索北航小程序，继而进行操作，抑或是小程序没有相关信息的课程中心作业，更是需要登录北航vpn，选择课程中心后进行查询，然而使用我们的App即可这些功能一步抵达。

  典型用户就是北航所有在校本科生，而典型场景有在校外想要查询自己成绩时，或是上课前查找教室、或是在校外需要查看自己的课程中心的作业时刻表。

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

  • 功能：原先计划设计功能四个（成绩查询，空教室查询，课表查询，课程中心DDL查询），已全部实现。
  • 交付时间：按照计划在4月29日完成交付上线。
  • 用户数量：原先计划用户数量200，实际峰值达到226人，达到了目标。

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

  没有上一个阶段。

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

  • 用户量：用户量部分其实比我们想象的要艰难，主要原因还是有现在大部分学生都在家中，目前提供的功能可能在校园内需求更大，如空教室查询等，几乎不会被使用，但我们相信开学后会有一波用户数量增加的时段。
  • 接受程度与我们的设想大致一致，课程中心的DDL功能饱受好评，但也存在相关问题，比如有些专业的学生，老师使用课程中心的频率较低，因此我们也在考虑增加新功能，确实离我们的目标更近了。

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

  爬虫阶段，我们使用的爬虫方法存在问题，占用服务器运行内存极大，原因是我们使用chrome来模拟登陆。我们没有调查清楚最合适的技术栈，就进行了初版的开发，使用了大量的服务器，达成的效果却不太尽如人意。若是历史重来，我们会在最开始的确定爬虫方法阶段，进行更仔细的调研，找到真正可以为我们所用的合适方法。

计划

• 是否有充足的时间来做计划？

  因为较早的确定了我们的项目，所以我们有接近一周的时间来做计划。我们在Alpha阶段的设计阶段基本上确定了每个人的任务，在设计阶段的最后我们在GitHub上创建Issue，规划所需时间，以及完成时间。在开发过程中我们在组会上相互沟通，大家在PM的统一协调下对自己的计划进行微调。

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

  在组会上大家在PM的统一协调下提出并解释自己对计划的不同意见，大家讨论后由PM权衡利弊决定方案的修改与否。

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

  我们在计划阶段规划的工作全部完成。

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

  我们所做的工作基本上全部投入使用，只有后端开发的旧加解密算法由于安全性能较差而被淘汰掉，替换为更安全的算法。

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

  是的。我们每一项任务都有明确的交付标准，对于开发者来说，主要是代码、文档和apk文件。对于PM来说，主要是博客、Issue管理等。

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

  • 我们的项目进行过程中出现了一些前后端、后端与爬虫的数据格式不统一的问题。这主要是由于设计阶段数据格式没有确定下来，导致开发阶段需要进行沟通，从而一定程度上拖慢了开发。
  • 在爬虫开发过程中发现爬虫的速度远远低于预期速度。导致前后端某些功能的设计需要临时修改。这主要是因为设计阶段没有对爬虫的速度进行初步的测试。

• 在计划中有没有留下缓冲区，缓冲区有作用么？

  存在缓冲区。我们将最后的一周作为测试阶段，它同时也发挥了缓冲区的作用。我们在最后一周进行了一些针对开发阶段暴露出的设计阶段的问题的修改。

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

  • 将来的计划依然会留出足够时间的缓冲区，用于测试和弥补开发阶段的失误。
  • 同时会进行准确的每日任务分配，尽可能不要出现某几天疯狂加班补进度的情况。

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

  • 计划对于团队项目开发来说，是非常重要的事情。本次Alpha阶段的所有成果得益于我们先前做好的计划，而大部分不足都归因于计划上的缺陷和不足。
  • 如果历史重来，我们需要制定更全面完善的计划，考虑到软件的每一个使用细节，多多听取用户反馈，尽量避免加班。

资源

• 我们有足够的资源来完成各项任务么？

  在人力上，我们团队一共有7个人，3人前端，2人后端，1人爬虫，在整个项目完成的情况看来人力是充足的，而物力上也有老师提供的服务器，目前来说4个服务器足够支持目前的用户量。而我们也在逐步优化，降低爬虫的负载。

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

  首先，大体的人员分布由第一次例会讨论得出。然后在每日例会中，每个人说出自己昨日完成的任务，然后再自己估计明日完成的任务，总体来说精度十分准确。

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

  我们拿了一周的时间来进行单元测试和用户内测，总体来说测试时间和人力等资源是足够的。而对于不需要编程的资源，例如美工等，我们是找其他由设计基础的同学来帮助我们完成，当然美工方面目前我们考虑的是简洁性更好，未来也有可能更炫一点。

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

  没有，我认为我们小组每个人都在自己的职位上充分发挥了自己的用处，可以说每个人都对自己的任务尽心尽力，注入了自己的心血。

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

  代码风格检查用插件实现，而不是团队口头约束。目前，我们团队代码风格虽然不是很好，但是在大体方向都做得不错，每一个方法，类都写了注释。而主要是一些细节方面没有体现到，而如今如果用代码风格检查插件的话，则整个代码会有一些细节的改变。

变更管理

• 每个相关的员工都及时知道了变更的消息？

  • 我们的项目变更大概分为部门内变更和跨部门变更。我们的团队有前端、后端、爬虫、服务器部署与管理四个部门。部门内的变更一般会部门内在微信进行沟通（如果部门有多个员工），每个相关员工可以及时知道变更的消息。如果需要部门间协作进行变更，我们往往会在每日例会中全组共同讨论，规范变更内容，以减少额外的沟通成本；对于一些紧急变更，我们会在团队微信群进行沟通与通知。
  • 通过上述沟通机制，每个相关员工基本能够知道及时变更的消息。不过也偶尔出现了一两次由于变更未能通知到部分相关人员导致的bug，经过反思我们发现是人员对变更的理解出现了偏差，或者是员工没有意识到在其进行某些改动后会影响其他员工的工作。

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

  • 首先，用户信息的安全性保障是我们认为必须实现的功能。由于我们的APP需要使用用户统一认证账户密码，因此在保证项目可使用的前提下做好用户信息安全的保障成为了我们的必做工作。
  • 其次，从待实现的功能角度分析：一是用户当下最需要的功能，就是我们“必须实现”的功能。比如今年用户都在家中通过网课进行学习，简单方便的查看DDL就是用户当下最需要的功能。相较而言，空教室查询、校车时间查询等功能便可以推迟。二是受制于当下情景，一些功能只能延迟上线，比如当前教务考表为空，博雅网站课程信息为空，所以这些功能我们只能推迟实现。

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

  • 兼容性：对于几乎所有Android机型和主流版本都能够实现兼容。
  • 易用性：按钮功能明确，功能入口醒目，弹窗提示易懂。
  • 稳定性：所有功能都能正常运行，进行常规操作时几乎不出现运行时Bug。
  • 及时性：后端能及时更新学生的信息变化，并反馈给前端。

• 对于可能的变更是否能制定应急计划？

  能。在进行每日例会时，一些员工会提出一些意见和建议，当经过讨论被采纳后，我们会制定应急计划，将任务分配到人并约定好完成变更的DDL。

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

  能够有效的处理，我们在开发过程中也出现了许多意料之外的请求。对于意料之外的请求，我们的团队成员都比较积极主动，空闲的员工会主动接下请求并有效的处理好，在大家都没空时，也会积极沟通协作处理好请求。

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

  • 变更可能是团队开发中必上的一课。开发过程中，很难保证一切工作都能如计划一般如期进行，且开发过程中也会发现当初计划的不足。
  • 历史重来一遍，我们会更加审视计划，尽量减少变更。如果有所变更，团队成员需要更及时地提出困难，更早的分配任务和DDL，尽量保证其对正常开发任务的最小影响。

设计/实现

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

  设计工作是在Alpha阶段开始前的一次会议进行的，这个时间比较合适。是由PM来主持会议，组员一起讨论完成的。

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

  模棱两可的情况也有，比如前端的导航栏设在下面还是侧面，以及课表、DDL前后端交互的格式是什么样的。这种问题由于还没开始开发，如果把格式定死的话，碰到新的问题不好处理。这种问题我们一般是通过开发过程中前后端进行讨论来明确。

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

  我们使用Django自带的单元测试模块对我们的后端进行单元测试，同时我们使用GitHub的Pull Request进行代码管理、使用Issue进行进度管理、使用墨刀进行原型设计。这些工具对我们的开发起到了重要的指导作用。

  考虑到大家都是初次接受此类软件的开发，在具体实现上面可能会和计划有较大出入，所以我们没有使用UML文档。后续如果有必要的话，我们会使用。

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

  课表查询功能的bug是最多的，因为教务的课表格式千奇百怪，爬虫遇到未知的格式就会解析错误。这是因为我们在开发初期无法获得大量的样本，所以只能用团队内部几个人的账号进行格式获取，后续在测试阶段，遇到其他同学的新的课表格式，我们也是第一时间做修改并发布更新。

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

  我们的分工是PM进行后端和爬虫的Code Review，单彦博同学进行前端的Code Review。在每个人更新代码后，都会向总仓库发起一个pull-request，Code Reviewer在检查PR中的代码后，将其合并到总仓库。我们前后端都有统一的代码规范，比如驼峰命名等。

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

  • 我们学到了团队协作时怎么进行代码管理，学到了怎么写代码方便他人阅读，学到了接口说明文档的重要性。
  • 如果历史重来一遍，我们会做一下TDD，因为我们前端的测试都是手动做的，并没有量化，用TDD的话可能效果会更好。

测试/发布

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

  我们团队有较为完善的测试计划：

  • 在开发阶段，由前端、后端、爬虫各自构造小规模数据验证功能的正确性。
  • 在测试阶段，前端、后端、爬虫三者共同运行，用开发人员的统一认证账户获取数据，详细测试各个功能是否正确运行。
  • 在验收阶段，进行小规模的压力测试，保证对于用户量较多的情况下能及时响应请求。

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

  如上一个问题所答，我们进行了正式的验收测试，包括功能、压力测试。

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

  有，例如：Postman、PyCharm、Coverage等。

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

  根据用户的请求响应速度与正确性来测量。通过实践我们肯定了这些测试工作是有用的，只有“防患于未然”才能带给用户更好的体验。唯一的不足就是我们的错误处理机制还不够完善，否则我们可以更快地定位bug所在。

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

  由于我们没有能获得教务数据库的读权限，因此我们完全是通过爬虫爬下来的数据进行解析的，因而出现了很多想不到的格式，从而运行出错了，例如：

  • 教务课表显示格式不统一
  • 课程中心的作业状态千奇百怪
  • 成绩查询模块缓考科目的存在

  出现这些问题并不是因为我们没有考虑周全，而是很多显示格式是我们没有遇到过的，也无从调研，因此只能在出现问题的时候及时予以更改。

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

  对于我们来说，印象最深刻的应该是测试出问题以后，因为教务界面的千奇百怪，导致爬虫对bug定位时的迷茫，如果重来一遍，我们会更加注重错误处理这一部分，提高代码质量。

团队的角色，管理，合作

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

  • 首先，确定好团队的大致分工，将开发工作分为三类：前端、后端、爬虫，另外还有一名PM。
  • 经过讨论、商议、自愿分配，最终确定了这四类工作的人数和人员。
  • 每位同学都进行自己自愿选择的工作，可以说人尽其才。

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

  团队成员的互相帮助是必不可少的。无论是同部门之间的相互扶持，还是跨部门的会议讨论，商议工作，都是团队成员互相帮助的体现。下面的感谢内容也体现了团队之间的帮助。

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

  目前来说，我们团队没有遇到这方面的障碍。不过，在出现相关问题的苗头时，我们会及时在Scrum Meeting中提出，共同商议，是否需要更换岗位，重新分配工作，或者重新计划相关任务。

每个成员明确公开地表示对成员帮助的感谢 。

成员	感谢内容
乔玺华	想感谢张艺璇同学，最开始配环境的一天晚上，配置虚拟机环境当时配到凌晨，我在前端讨论群里提了各种问题，张艺璇耐心的进行了部分解答，且一起熬夜到挺晚，非常感谢，那晚真的心态有点崩溃。
张艺璇	感谢乔玺华、单彦博同学，因为在一起进行前端开发的过程中，自己踩坑在群里求助的时候，他们会根据自己的经验提供意见和帮助。
单彦博	感谢乔玺华为我的DDL页面添加新功能。 感谢张艺璇承担了最复杂的课表设计页面。 感谢胡彬彬和我一起研究AES加密算法，保证前后端的一致性。 感谢李嘉铖为我添加GPA和加权平均分接口。 感谢杜博玮为我解决DDL的格式问题。 感谢郭骏跟踪整个项目开发，为服务器部署和项目展示做出的贡献。 感谢我的“顶级理解”团队的所有人。
李嘉铖	我感谢胡彬彬对我的帮助， 当不知道如何解决bug的时候，他经常能给我启发。 我也感谢前端、爬虫、PM的帮助，没有PM的服务器部署、爬虫和前端的数据配合与协调，我们团队就不会有今天的成果！
胡彬彬	我感谢李嘉铖对我的帮助， 因为在后端框架的学习上，一些文档，知识点都是他去寻找的，而整个后端的代码编写过程中也是积极和他进行讨论，互相学习。 我感谢郭骏对我的帮助， 因为每次更新服务器上部署的速度都十分及时，对于后端的一些缺陷也提出了有意义的建议。
杜博玮	我感谢郭骏对我的帮助，花费大量时间帮助我找到爬虫的bug。 我感谢乔玺华对我的帮助，帮忙询问同学获得爬虫的优化方案。
郭骏	我感谢单彦博对我的帮助，承担了许多计划失误带来的额外工作。 我感谢杜博玮对我的帮助，在爬虫界面解析bug层出不穷时一起挺过难关。 我感谢顶级理解团队的所有人，对项目一心一意、不离不弃、和谐共处、共同开发，从零开始一步一步搭建起框架，披荆斩棘，造就了Alpha阶段的成功。

总结

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

  我们团队应当属于CMMI的第二级，即管理级。我们不仅能够遵循第一级“执行级”中的所有内容，实现目标，团队成员也能遵守计划，权责到人，避免完成任务的随机性，保证了成功率。

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

  我们团队应当已经进入规范阶段。团队成员可以公开讨论流程和工作的方式，自动建立起了一些成文或不成文的规则。大家都有更强的集体意识，愿意在工作中互相支持，互相尊重，互相欣赏。

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

  这是我们团队的第一个里程碑，相对于团队成员初相识时的一盘散沙，我们已经共同经历了一个月的开发过程，增进了互相的了解，更加团结，更加上进，也更加为团队和项目着想。

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

  最需要改进的可能是计划方面的问题。在Alpha阶段从零开始时，我们的计划不够完善，在稳定测试阶段进行了许多额外的开发任务。这些任务本可以在一开始就计划好，但是我们并没有想到这些问题。原因可能是大家都第一次开发此类软件，且也是从零开始开发，没有原型系统支持。在下一个阶段，我们会改进计划，且落实到执行。

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

  • 经常发布可用的软件，发布间隔可以从几周到几个月，能短则短。

    我们的软件从两周的开发任务结束之后产出第一版1.0.0版本的app开始，就一直在更新，目前已经更新到1.0.5版本。半个月内，我们发布了6个可用的软件版本，其中实现了不少额外的功能，如加密算法优化、版本更新提示等。这些功能为我们的软件提供了良好的保障。

  • 业务人员和开发人员在项目开发过程中应该每天共同工作。

    打地基的开发阶段，PM每日需要审核大家的代码，进行Code Review，体现了共同开发。而测试阶段，大家发动起身边的同学一起进行测试，遇到bug实时反馈到微信群中沟通，由PM进行bug定位后，将错误信息交付给相关同学，进行debug。业务人员（PM）保证了每天的工作和开发人员一起进行。

  • 保持简明——尽可能简化工作量的技艺——极为重要。

    虽然在设计之初，我们有很多很多想要实现的功能，但是在敏捷开发的时间面前，我们为了能够交付更可靠的可用软件，尽可能的简化了工作量。我们围绕目前的四个核心功能：课表查询、DDL查询、成绩查询、空教室查询进行了开发和测试，保证了工作量的明确和简化。虽然任务不算很多，但是在一个月的时间里进行不断的打磨，使得软件较为完善。

质量提高

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

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

  我们将继续使用GitHub作为我们的代码托管工具，善用GitHub的Issue和Pull Request功能，并且尝试使用Wiki和Release功能，让代码管理更加清晰。代码规范尝试引入pylint等代码风格审查软件，代码复审将继续依赖Pull Request，保证代码的签入质量。

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

  目前程序的架构方面，还没有感受到有很大的问题，所以提高可能会通过规定一些代码规范来提高代码的可读性和复用性。质量的提高可以通过进行Code Review时的主观感受来进行，也可请其他与项目无关的人来阅读代码，从而感受代码质量。

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

  我们会考虑使用pylint等代码审查工具来严格我们的代码规范，使用postman进行测试时，也会对相应的请求进行保存，从而记录测试内容。

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

  Issue需要更详细，PR需要与Issue进行绑定，之后增加的新需求或者bug也需要通过Issue来进行记录。

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

  目前我们通过在收到请求时，将数据库内相应字段+1来跟踪用户的活跃数据。我们计划更加准确记录用户数据，例如请求的成功次数和失败次数等。

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

  首先文档要全面。然后，为了保证质量，我们可以请项目之外的人来阅读参考我们的文档，如果能够看懂，或者成功配置好环境运行，就可以认为文档的质量较高。

• 对于人的领导和管理， 有什么具体可以改进的地方？

  需要在开发之前拟定更多的成文条例来进行管理，并且可以模拟开发阶段的情况对条款进行评估，否则后期会出现许多模棱两可的情况，让PM和开发者都不太愉快。

• 对于软件工程的理论，规律有什么心得体会或不同意见？

  如果一款软件的开发需要做到“敏捷”，在开发时间长度固定的情况下，必然会缩短计划时间和测试时间。但是实践表明，计划和测试的缺少会导致开发阶段出现许多不必要的麻烦，从而带来“欲速则不达”的情况。所以，敏捷开发任务中，如何在计划时间、测试时间、开发时间三者之间做好取舍，是敏捷开发的艺术。

会议截图

会议使用腾讯会议进行，在5月7日12:30开始，13:30结束。

由于PM在主持会议，所以疏忽了会议截图。目前能够提供的是会议时间约定和开会的微信聊天证据。