The following text is a partial translation of the original English article, performed by ChatGPT (gpt-3.5-turbo) and this Jekyll plugin:
在这篇文章中，我将尝试用谜题驱动开发（Puzzle Driven Development，简称PDD）的精神来引导您完成一个项目。在此过程中，我将试图传达各个项目成员的典型观点。
基本上，任何软件团队中都有几个关键角色：
系统分析师—记录产品负责人的想法
架构师—定义系统组件如何相互交互
设计师—负责实现最复杂的组件
程序员—实现所有组件
测试人员—发现并报告错误
每个人都会以两种方式影响项目，除了项目经理：他们既会修复项目，又会同时破坏它。让我用一个简单的例子来解释这个问题。
让我们为简单起见假设一个项目是我为一个亲密朋友编写的简单软件工具。我创建了第一个草稿版本0.0.1并交给了他。对我来说，这个项目已经完成了。我完成了工作，希望再也不用回头了。
然而，项目的现实情况却非常不同。仅仅几个小时后，我接到朋友的电话，说他在这个工具中发现了一些bug。他要求我修复它们。现在，我可以看到项目还没有完成。实际上，它是有问题的。它有一些bug，这意味着还有一些任务需要完成。
我将修复这个项目，去除这些bug。我实现了一个新版本的软件，命名为0.0.2，并将其发送给我的朋友。再次，我相信我的项目已经完成了。它被修复了，应该关闭了。
这种情况一次又一次地重复，直到我的朋友停止打电话给我。换句话说，直到他不再破坏我的项目为止。
很显然，我的朋友破坏我的项目越多，最终交付的软件质量就越高。0.0.1版本只是一个非常初步的版本，尽管我在发布时认为它是最终版本。几个月后，当我发现并修复了数百个bug后，3.5.17版本将更加成熟和稳定。
这就是这种“修复和破坏”方法的结果。
图表显示了项目的时间和混乱之间的关系。我的朋友报告给我的bug会破坏这个项目，增加其不稳定性（或者简单地说，增加混乱）。我发布的新版本解决了这些bug，并修复了项目。你的GitHub提交动态应该类似于这个图形，例如：
当项目开始时，混乱程度相当低，然后开始增长。然后，混乱程度达到顶峰并开始下降。
项目经理的工作是尽一切可能来修复项目。他必须利用赞助人的时间和金钱，以消除所有的错误和不一致，并将项目恢复到“已修复”的状态。
当我说“错误”时，我指的不仅仅是软件错误，还包括：
尚未实现的功能
功能性和非功能性错误
测试覆盖率不足
未解决的
@todo标记缺乏风险分析
etc.
项目经理给我一些任务，他希望完成这些任务以修复和稳定项目，将其恢复到一个无缺陷的状态。
作为软件团队的一员，我的工作是帮助他进行所需的修复，并同时尽力破坏项目！在我朋友的例子中，他不断地通过向我报告错误来破坏项目。这是他帮助我们两个人提高产品最终质量的方式。
我应该做同样的事情，并且在我正在开发某个功能时，始终努力报告新的错误。我应该同时进行修复和破坏。
现在让我们更详细地了解项目角色。
产品负责人提交一个非正式的特性请求，通常以“有…会很好”开始。我是一名系统分析员，我的工作是将产品负责人的英语翻译成程序员和我自己都能理解的正式规格，在SRS中进行规范化。我不负责实现这个特性。
当SRS的新版本由变更控制委员会签署时，我的任务就完成了。我是产品负责人的口译员，将他们的语言翻译成SRS文档所需的正式语言。我的唯一客户是产品负责人。只要她关闭了特性请求，我就会得到报酬。
除了来自产品负责人的特性请求，我经常收到关于SRS质量的投诉。对于一些团队成员来说，文档可能不够清晰。因此，我的工作是解决清晰度问题并修复SRS。这些团队成员也是我的客户。当他们关闭他们的错误报告时，我会得到报酬。
在特性请求或错误报告的两种情况下，如果有足够的时间，我可以立即对SRS进行更改。然而，这并不总是可能的。我可以提交一个错误报告并等待解决；但是，我不想让我的客户等待。
这就是谜题驱动开发对我有所帮助的地方。我不是提交错误报告，而是在SRS文档中添加”TBD“谜题。这些谜题是通常非常严格的正式需求的非正式替代品。它们满足我的客户，因为它们是用简单的英语编写的，技术人员可以理解。
因此，当我没有时间时，我不会等待。我会在我无法创建适当和正式的需求描述或者不知道如何准确书写的地方使用TBD进行SRS的更改。
现在，我是架构师，我的任务是实现在SRS中明确规定的需求。项目经理期望我提供一个可工作的功能，而我只有在架构清晰且类已经设计和实现的情况下才能交付。
作为架构师，我负责将所有组件组装在一起，并确保它们适合。在大多数情况下，我并不是自己创建它们，而是告诉每个人应该如何创建它们。我的工作流程如下：
[SRS] -> [UML] [UML] -> [源代码]
我从SRS接收需求，生成UML图表，并向设计人员解释如何根据我的图表创建源代码。我并不真正关心源代码是如何实现的，我更关注组件之间的交互以及整个架构是否满足功能和非功能(!)需求。
当系统分析师在SRS中将其状态更改为”已实现”时，我的任务将被关闭并支付。系统分析师是我的唯一客户。我必须向他销售我的解决方案。当系统分析师将功能需求的状态从”已规定”更改为”已实现”时，项目经理将关闭我的任务并支付我。
任务听起来很大，而我只有半个小时的时间。显然，谜题驱动开发应该能帮助我。我将创建许多票据和谜题。例如：
非功能性需求不明确
UML图表不够清晰。
组件尚未实现
构建不是自动化的
持续集成未配置
代码的质量无法控制。
性能测试不是自动化的。
当我解决了所有的难题之后，我就可以回到我的主要任务上，完成功能的实现。显然，这可能需要很长时间——几天甚至几周。
但是，主要任务所需的时间不到一个小时。这一切辛勤工作的目的是什么呢？很简单；我会通过报告的所有错误来赚取我的时间。通过这个小任务，我将生成许多工单，每一个都会给我额外的现金。
设计师和程序员之间唯一真正的区别在于他们各自任务的复杂性和收费的小时率。设计师通常进行更复杂和更高级别的实施，而程序员则实现所有低级细节。
我是一个程序员，我的任务是实现一个类或方法，或修复一些功能性错误。在大多数情况下，我只有半个小时可用。而且，大多数任务比这需要更多的时间。
迷题驱动开发帮助我将任务分解为较小的子任务。我总是从单元测试开始。在单元测试中，我试图重现一个错误或模拟该功能。当我的测试失败时，我提交它并确定我剩下多少时间。如果我还有时间让它通过——我就这样做，提交更改并向项目经理报告。
如果我没有时间来实现修复，我会标记那些没有“@todo”标记的代码片段，提交它们，并向项目经理报告我已完成。
正如你所见，我同时修复和破坏代码。我用我的新单元测试来修复它，但用“@todo”谜题来破坏它。
这就是我如何通过同时修复和破坏来提高项目的整体质量。
我是一名测试员，我的主要动力是发现错误。这可能与你之前听到的相矛盾；但在xdsd中，我们计划在项目的每个阶段发现一定数量的错误。
作为一名测试员，我从项目经理那里接收任务。这些任务通常是“审查功能X并找出其中的10个错误。”项目经理需要找到一定数量的错误来修复项目。从他的角度来看，当发现了200个错误时，项目就被修复了。这就是为什么他要求我找到更多错误。
因此，为了响应这个要求，我寻找错误，以在整个大局中尽自己的一份力量。与此同时，我也可以自己找到缺陷并报告它们。这是我任务中的“破坏”部分。
Translated by ChatGPT gpt-3.5-turbo/42 on 2023-12-16 at 15:12
