事后分析

设想和目标

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

  Beta阶段我们首先要对文本标注方式进行优化，其次时添加好友系统，实现邀请好友共同标注的功能。具体的定义和典型用户场景在博客Beta设计与计划中又描述和展示。

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

  • 实现了的的功能有：自定义关系的添加与删除，实体的查找，实体名称的修改，实体之间关系的修改和删除，项目创建与删除，添加好友，邀请好友加入项目，多用户协同标注，文本导入，知识图谱的导出。所有的功能都实现了
  • 交付时间：原计划6.5交付，实际交付时间未6.7中午，稍有拖延。
  • 用户数量：我们预计发布一周后用户注册量为200，截止6.9日，我们的注册量为135人，未能达成预期用户数量。分析原因：
    • 推广力度不够，只在北航6系内部进行了推广。
    • 项目功能不够吸引人。今年6系烤漆基本没有考试，相对而言计算机学院的专业术语较少，知识脉络也比较清晰，构建知识图谱进行复习不是刚需。

  总体来说，Beta阶段较好的完成了所有的任务。

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

  Beta阶段工作量大大增加，代码量提高的同时也暴露出了了很多问题。后端代码的质量下降，bug层出不穷，前端代替后端做了debug 的工作。在项目管理方面提高了，采用了不同的分支存储前后端代码，测试完之后合并到master分支。这样我们代码被覆盖的次数大大减少。

• 用户量，用户对重要功能的接受程度和我们事先的预想一致么？我们离目标更近了吗？有什么经验教训？如果历史重来一遍，我们会做什么改进？

  • 实际上用户量略小于目标，但也没有太出人意料。
  • 我们的确离目标更近了，我们从Alpha阶段简单的网页做到现在的功能比较完善的网页，功能上更接近要求。用户数量几乎是Alpha阶段的3倍。
  • 如果再来一次，我们要让开发人员自己写单元测试，降低bug。负责测试的同学一定要认真负责，工作及时。

计划

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

  是的。PM跟前端协商，先做原型设计，再去实现。

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

  团队成员会在每日例会上进行讨论，PM会根据成员的意见对设计或者计划进行调整。技术上的问题会修改原型设计，时间上的问题PM会调整目标和计划。

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

  做完了。

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

  没有。开发、测试、PM都做了有价值的事情。

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

  有，依据PM的原型设计

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

  项目出现的意外：李健同学原计划一周的工作实际两周才完成，柴博同学接替李健同学做了第二周的工作。没有估计到是因为右键添加实体这个功能耗费了李健大量的时间学习。

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

  项目整体的缓冲区留在最后一周的稳定发布阶段。每周周六也不会安排任务，留给大家处理本周没有完成的任务。

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

  总体来说Beta的计划并没有大的问题，重来一遍我们依旧没法预估学习新技术需要的时间成本。但是在Beta阶段预留了很多缓冲时间，使得我们的项目能够顺利进展。

资源

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

  后端在Beta阶段的开发任务依旧不是很大，需要解决的技术难点在Alpha阶段已经有了一定的积累。但前端的技术难点依旧没有解决，耗费了很多时间来进行学习、重新设计。

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

  每日例会时由PM和组员协商讨论，精度还可以，基本都在预期之内。

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

  Beta阶段后端的测试压力不是很大，时间充足，有专人进行测试。前端测试由PM兼顾，事后发现测试得不是很充分。

  美工设计主要由PM负责，但是由于技术的原因，很多设计都没能实现，都针对现有的、能实现的方式进行了重新设计。项目的美术风格很简朴。

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

  我们团队的分工还是比较明确的，大家的任务都比较具体，从技术上来讲专攻的方向也不尽相同。所以可能没有这种感觉。PM觉得自己的工作可以被替代，如果由更了解前后端技术的人来做效率会高上不少。

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

  前端因该安排3人进行开发，或者PM应该尽早参与前端的开发，这样才能更好地完成前端的任务。应该将团队的资源集中到核心功能的开发上。

变更管理

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

  是的，每日例会上会对任务进行安排，如果有变化，PM会随时和各位组员联系。

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

  在例会上进行讨论，前后端会提出意见，由PM整体把握进行决策。

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

  总体参见功能规格说明书，Beta阶段参见【二食堂】Beta - 设计和计划

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

  能，紧急调整目标要求。

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

  我们在前后端对接时发现后端出现了很多bug，后端虽然修改及时，但是希望能在开发时更加细心，更早发现并改正这些bug。

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

  开发和修改bug应该集中安排时间。有时会出现修改bug影响到开发进度的情况。

设计/实现

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

  设计工作在Beta初期由PM完成。PM进行了功能设计和原型设计。时间合适，PM和前端进行了沟通，得出了最合适的设计方案。

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

  有，针对这些情况，主要解决方式是开发人员与PM沟通。

• 团队是否运用单元测试、测试驱动开发，或者其他工具来帮助开发？

  我们团队进行了单元测试、压力测试、issue进度管理、原型设计等工具，这些东西都很大程度上帮助了我们的开发。

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

  • 好友添加、删除以及Graph显示上bug最多。因为前后端沟通不及时以及后端自身的bug很多。
  • 发布之后最重要的bug就是关系添加太多实体会消失、未进入项目自定义实体会显示很多奇怪的文本。
  • 这些bug都是意料之外的，我们预留了一天时间解决其他问题，但是不是很够。

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

  代码复审由测试人员进行。将front和back分支下的代码进行测试、合并，没有问题之后push到master分支。后端严格执行了代码规范（IDE自带），前端没有严格执行。

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

  设计一定要清楚详细，尽量能准确清晰地描述出功能的细节。单元测试十分重要，在前后端对接出问题时后端的单元测试能提供很大的帮助。若历史重来，PM会花费更多的时间让网页变得美观。

测试/发布

• 团队是否有一个测试计划？

  有

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

  是。在发布前，后端进行了压力测试和单元测试，前端进行了兼容性测试。

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

  后端采用了Django的测试框架。前端没有使用测试工具，在Win10环境下使用主流的浏览器进行兼容性的测试。

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

  访问服务器上的网站与本地不一致，服务器无法访问到静态资源。后对服务器进行了重新配置，解决了这个问题。

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

  关于测试，我们会进行更详细的测试，测试与开发同步，减少后端的bug。

团队的角色，管理，合作

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

  大家沿用Alpha阶段的分工。因为有技术积累，很多同学都是不可替代的，算是做到了人尽其才。

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

  有，PM会帮前端做一些工作。后端与测试之间也会进行一些沟通交流。测试也会帮前端进行对接上的工作。

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

  在每日会议上交流讨论，PM也会组织小会议与出问题的组员进行商讨。

• 成员的感谢

  姓名
  李健	我感谢刘阳对我的帮助，因为他帮助我修改UI
  柴博	感谢李健，他完成了文本的有关功能
  刘享	感谢博哥的测试，帮我找了不少bug
  窦铮	我感谢刘阳同学，帮我积极与前后端沟通交流，及时解决测试所发现的各种bug
  左正	我感谢窦铮对我的帮助，因为他帮助我对代码进行了测试，修复了一些bug
  刘阳	我感谢柴博和王政对我地帮助。柴博和我一起解决了一些bug，在项目的设计上也给我提出了很多意见。王政同学协助了我一些代码复的工作，在项目进展缓慢的时候对我进行了鼓励，感谢。

总结

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

  CMMI二级，管理级。基本实现了权责到人，软件开发流程有监控、审查。

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

  磨合期，大家在这一阶段都进行了很多合作，已经有一个不错的合作模式了。

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

  做好任务安排，在功能设计上要花费更多的时间。做好测试，减少对接时的困难。

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

  • 欣然面对需求变化，即使在开发后期也一样。为了客户的竞争优势，敏捷过程掌控变化。

    前端修改之后会对后端提出新的要求，后端能及时反应，做出修改。

  • 业务人员和开发人员必须相互合作，项目中的每一天都不例外。

    几乎天天都有例会。前后端开发人员与PM进行讨论。

  • 可工作的软件是进度的首要度量标准。

    只有前后端对接完成，确定没有bug后，才会关闭相应的issue。以软件可用为验收标准。

会议照片

标签：团队,事后,bug,Beta,测试,进行,食堂,PM
来源： https://www.cnblogs.com/esthnpd/p/13080163.html