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