beta阶段事后分析

设想和目标

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

  我们的网站希望提供一个课程评价平台，帮助同学更好的了解每一门课的信息和评价。也提供了一个同学发表自己关于课程的想法的平台。
  网站定位清晰。我们面向的典型用户就是每一个选课存在困难的学生，帮助他们在选课时间段很好的了解到上一届学生每一门课的评价。

• 我们达到目标了吗？

  我们beta阶段的目标是在alpha阶段的基础上实现功能的扩充和界面的美化。在实现过程中，我们实现了对评价增删改的支持，对评价下讨论功能时支持，对用户信息以及活动记录的显示，以及界面美化功能的实现。基本达到目标，但细节上仍然不够完美。

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

  我们的开发仍然沿用上一阶段的流程，由于对开发环境有更好的理解，所以开发效率有所提升。但是在软件工程的质量上我们并没有明显的提高。这是我们这一阶段没有仔细思考反思的地方。

• 用户量，用户对重要功能的接收程度和我们时间预想的一致吗？我们离目标更近了吗？

  我们最终的用户量并不多，没有能够拿到有效的用户反馈意见。但是我们从测试人员处得到了一些反馈信息，并根据反馈优化了用户体验和功能上的BUG。我们离目标更近了。

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

  在预想功能设计时需要更加贴近用户需求，设计重点不应是我们想做什么样的功能，哪些功能是方便实现的，而应该思考用户需要什么样的功能，然后才是思考怎样实现这一功能。即从用户的角度思考问题。

计划

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

  相比于alpha阶段，软工的beta阶段和编译等课程冲突较多，因此计划的时间减少，但相对来说还是比较充足。

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

  在计划阶段团队成员共同讨论，过程中存在不同的想法和意见，但在交流过程中全面权衡之后，都能够达成共识，定下合理的计划。

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

  我们在原计划中的工作基本都完成了，并扩充了“讨论中的艾特其他人”的功能。但是细节的处理还是存在一些实现方式问题，这是在实现前没有提出一个好的规范导致的。

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

  我们做了一些功能说明文档和各类流程与数据库ER图之类的说明文档。但是在开发中这些内容我们并没有用到。

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

  有。在GitHub的issue中对每一个任务都有较为详细的描述和需要实现的目标。但是衡量部分做的不够好，不能保证每个任务都有明确的衡量条件。

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

  项目中出现过一些问题。由于跟其他课程冲突，有一个issue在实现过程中进度拖的比较久，导致项目进展拖延较多。在经过协调处理之后完成了这个issue。在这之后项目都按照正常进度进行。与其他课程冲突这一风险我们在计划时有考虑到，因此对最终结果影响并不是很大。

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

  有留下缓冲区，也起到了作用。当项目进度出现问题后，缓冲区起到了作用，并依靠它赶上了进度，让最终开发结果没有受到影响。

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

  将来的计划中应当考虑到不可预知的风险对项目的影响。

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

  好的计划能有效地推进整个项目的进展。在计划前，对项目开发本身有一个较清晰的整体印象，对于做出一个好计划很有用。

资源

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

  我们有足够的资源完成各项任务。开发过程中出现问题后能够通过网络很快的找到解决方案。同时老师也能提供帮助，例如提供网站服务器。

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

  对于任务时间和其他资源的估计没有特别的方法，而是根据对其大致理解进行预估。因此精度并不高。

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

  在beta阶段我们团队转会转出一人，所以在人力上不是特别足够。但是合理分配每个人的工作量之后，还是能够应对。测试的时间比较赶，好在测试人员张华杰工作迅速，又有alpha阶段的经验，在时限内完成了测试工作。我们在非编程方面的预估没有低估其难度，制定了专门的issue完成界面美工设计。

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

  的确会存在这种情况，将任务分给理解项目更好的成员实现将会更有效率。但这只是短期的高效率，长期以来将会导致团队上限由某几个成员决定。只有每个人都对工程有较好的理解，才能使团队上限更高。

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

  合理分配资源和时间，将任务分配到最合适的人。同时留出时间给测试阶段。

变更管理

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

  这一点我们做的比较好，变更消息都能及时在群里通知。同时冲刺阶段密集的scrum meeting也是很好的消息交流渠道。

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

  确定核心功能，和核心功能密切相关的功能时必须实现的功能，相关度不是很大的功能将会推迟。相关决定事宜都会在例会中讨论得出结果。

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

  出口条件就是很好地完成预先定下的目标，整个项目没有功能，性能和用户体验上的bug。并且开发成果符合规范。

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

  项目并不庞大，团队的开发流程相对灵活。因此遇到紧急变更都能够尽快商讨出合适的应急计划。

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

  团队凝聚力较强，团队成员对于项目开发都很积极，都能够有效的处理意料之外的工作请求。

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

  开发过程不可能永远按照计划来，临时的需求都需要对计划进行变更，这对团队对于突发情况的控制和处理的要求较高。同时要求团队成员有较强的凝聚力，遇到困难共同解决。

设计 / 实现

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

  设计工作是在上一项功能完成之后，下一个功能实现前做的，只针对具体功能进行设计。
  后端设计主要由PM刘斯盾完成，前端设计则由易子沐完成。
  针对每一个功能进行设计，能细化设计内容，避免后期因为局部设计考虑不周而推翻重来的情况。关于设计角色的选择，后端让刘斯盾负责，是由于他的编码能力比较强，前端让易子沐负责，是由于他的审美比较靠谱。两个选角都相当合适。

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

  由于是阶段性设计，每次设计的内容都很细致，所以没有出现模棱两可的情况。

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

  很遗憾，我们团队没有使用测试工具来帮助设计与实现。

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

  前端的JS动态效果有一些bug，导致出现一些难以理解的动态效果。但这些问题都不影响正常使用。导致这些bug的根本原因还是我们对前端工程的理解程度还不够，对工具的熟练运用程度还有待提高。

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

  很遗憾，我们没有做代码复审。

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

  由于用工程化方法去设计和实现是一件很繁琐的事情，而且在短期内也看不到它的优势，所以我们在项目开发工程中并没有重视它。另一方面，我们的整体规划与具体分工上出了问题，导致大家没有强制的义务去接手工程化操作。因此，如果历史能重来一遍，我们会把每个人的具体职能划分清楚，而不是分配角色，将工作落实到个人，这样大家就没有理由去避免应该属于自己的那份任务。

测试

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

  我们团队的测试计划大体分为两个部分，一个部分是团队成员完成当前任务编码以后，对自己的代码做自我测试，并且传到本地服务器上进行验证。另一部分是基本功能都实现之后，由测试人员对整合于服务器上做整体的功能、性能、兼容测试。

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

  进行了正式的测试，测试结果发布在beta阶段的测试文档上。

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

  有测试工具，测试主要通过scrapy框架进行模拟访问。通过scrapy模拟访问搜索页面（达到130人每秒），然后通过使用浏览器内置的网络访问插件观测和记录模拟访问过程中和模拟访问前的访问时间变化。

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

  这部分与alpha阶段类似。
  有关功能可用性和兼容性的测试主要通过在不同机型和不同运行环境下通过用户的反馈进行测试。而网站稳定性的测试主要通过scrapy的框架对网站的主页和数据查询页面进行模拟访问进行，再通过浏览器自带的网页反应时间功能获取结果。
  但是测试的结果要比alpha阶段好很多，显著表现就是兼容性方面有了比较大的进步，出错的几率减小了。而且得到了稳定性方面依旧是一个比较大的问题，在130同时访问的情况下，服务器的反应速度明显降低。
  应该部署效能更好的服务器，从而解决稳定性方面的缺陷。

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

  1.预期部署的阿帕奇框架由于时间的原因没有部署成功。
  2.宣传的效果不够好。
  3.稳定性方面还存在一些问题，难以完美支撑较多的用户。

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

  学到了测试方面的一些知识和提前做好风险评估的重要性。
  改进：
  1.提前确定一些框架的学习成本来选择是否选择这种框架。
  2.在开发完成之前就应该制定好一些宣传的方式，来更好的吸引用户。
  3.选择更适合用户实际数量的服务器部署方式。

团队合照