问作为一个单独的敏捷(PXP/PSP)开发人员，什么是正式的项目死后合适的结构？

EN

对追溯性文档施加严格的结构本身并不是非常灵活。

在敏捷中，您不会发现您必须不惜一切代价地遵守严格的规则，例如：

• “单元测试应在编写代码之前编写。”
• “代码至少应有95%的代码覆盖率。”
• “每个公共和受保护的方法都应该有说明其用法、每个参数、返回值以及可能产生的异常的文档。”

原因是，您可能会发现，很明显，规则对整个项目的危害大于好处，因此要求团队根据他们的具体情况调整规则，而不是使流程适应规则：

• 一个团队可能会注意到，与其他团队不同的是，遵循TDD会阻止他们在编写代码时具有灵活性，而对质量的影响却很小。
• 另一个团队可能会发现，开发人员花费数周的时间试图从94%提高到95%，这增加了延迟交付软件的风险，同时也降低了代码质量，因为他们花在代码评审上的时间较少。
• 第三个团队可能会发现，程序员在编写样板代码时士气低落，而不是进行真正的编程。而且，他们现在倾向于少用方法的自记录名称来编写自文档化代码。

这正是回顾工作的目的。那么，为什么不调整回顾本身呢？

请注意：

• 回顾是不一样的:如果过程不断发展，你每次都会遇到不同类型的问题，这会对回顾产生影响。第一次回顾可能以项目的整体组织为中心:新的团队刚刚开始项目，并不是所有的事情都足够令人满意。他们选择了Scrum，但是Scrum的一些指南似乎不适合这个团队；另一方面，他们想使用XP的一些指南。团队还在两栋楼里，使得沟通变得更加困难。该小组还指出，还有一百多个障碍有待解决。第二次回顾主要是在估计的基础上进行的:事实上，团队估计能够做到实际完成的两倍。造成这种情况的两个主要原因是：(1)团队中最熟练的开发人员在sprint的第二周就生病了(团队应该如何更好地处理“被总线击中”的场景？为什么失去一名队员会造成这样的后果？他们队里有牛仔编码员吗？)而且(2)系统管理员太忙，无法定期部署项目( DevOps对此有帮助吗？)第三次回顾主要关注在代码评审过程中发现的一些代码的可怕质量(程序员是否受过足够的培训？)团队中的每个人都读过代码完成吗？最后期限是否鼓励草率的编程？)事实上，客户的代表根本无法回答这些问题(我们是否需要聘请专家呢？)我们是否需要对客户坦诚相待，并要求更多地参与项目？)您可以注意到，对追溯性报告强制采用严格的结构并不明显，只会使报告不那么清楚。例如，第二次回顾的最直接的结构是：
  1. 实际估计过程
     • 对实际估算过程的描述，
     • 与公司其他团队使用的方法相比，这一过程的特殊性。

1. The actual issue 1: “Hit by a bus” scenario  
    - The code is not documented enough,
    - There are no enough communication inside the team during the sprint, so members sometimes ignore what other members do.

1. The actual issue 2: cowboy coders  
    - The lead developer don't care matching the common rules used by the team,
    - The lead developer is not a team player and should look for another team.

1. The actual issue 3: no DevOps  
    - System administrators are too overwhelmed to deliver the product on time,
    - DevOps can help.

同样的结构对于第一次或第三次回顾是没有意义的。

• 回顾本身应该适应团队的需要和限制。这意味着，从一个团队到另一个团队，从一个公司到另一个公司，您会发现在处理回顾会议方面存在差异。在每一次回顾之后，CEO想要一份报告的公司会组织不同的回顾，而公司在回顾过程中所说的只有团队才知道。一个由三个开发人员组成的团队将有一个不同于12个开发团队的回顾。回顾一组害怕被批评的人，与他们的团队的回顾毫无关系，因为他们欢迎建设性的批评，认为这是一个很好的改进方法。