雨后小故事动态邪恶_当您遇到“邪恶”的问题时，使故事变小

雨后小故事动态邪恶

如果您阅读了《小故事的三种选择》 ，您会注意到一件事。 在这些示例中，每个问题都在于团队展示进度和制定临时步骤的能力。 但是，当您遇到“邪恶的”问题，不知道是否可以创建答案时该怎么办？

如果您是项目经理，则可能会从《 邪恶的问题，正当的解决方案：现代工程范例目录 》一书中熟悉“邪恶的”问题的概念。 如果您是设计师/架构师/开发人员，那么您可能对Rebecca Wirfs-Brock的书《 对象设计：角色，职责和协作 》一词很熟悉。

您会在新产品开发，研究和设计工程中看到类似的问题。 当您必须进行探索性设计时，您会看到它，而以前没有人做过这样的事情。

您的问题需要创新。 也许您的问题需要与客户或其他设计师讨论。 您需要就什么是适当的设计达成共识。

当我向一群模拟芯片设计师教授敏捷技术时，他们创建了着陆区 ，在其中不断进行权衡以适应整个项目的时间表，以确保他们在可用的时间内做出最佳设计。

如果您有一个严重的问题，那么您就有很多风险。 您如何处理有风险的项目？

1. 使用可以找到的最好的人员来为项目配备人员。 过去，我使用过一种特殊的“ 泛化专家 ”，即测试人员编写代码的那种。 也是建筑师的那种开发人员。 这些不是您在大街上接的人。 这些人（对不起，他们的工作很棒）。 它们不能与其他人互换。 他们在如何解决这个问题显著领域的专业知识。 这意味着他们了解如何编写代码和测试。
2. 帮助那些泛化专家学习如何在项目中经常问的问题。 在我的“卵石”文章中，我说过，通过一个研究项目，您会使用问题来发现需要了解的知识。 关键是使这些问题足够小，以便您每隔几天或至少每周一次显示进度。 项目中的每个人都需要建立信任。 您通过交付来建立信任。 即使他们没有提供有效的代码，项目团队也会通过提供答案来建立信任 。
3. 您总是打算重新计划。 问题是多久一次？ 我喜欢经常重新计划。 如果您在1999年订阅我的《思考》时事通讯（在“务实经理”之前），我就写过一篇关于邪恶项目以及如何管理风险的文章。
4. 帮助经理停止微观管理。 项目经理的工作是消除团队的障碍。 经理的工作是支持团队。 这些经理类型中的任何一种都可以通过帮助他们产生每周要问的新问题来帮助团队。 也没有问“何时完成此工作”的工作。 请参见亚当·尤雷特（Adam Yuret）的文章《滥用冲刺承诺》。

现在，作为回报，解决这个严重问题的团队需要每周（或最多每两周）更新组织的工作情况。 该更新需要是一个演示。 如果不是演示，他们需要展示一些东西。 如果他们不能参与敏捷项目，我想知道为什么。

有时，他们无法显示演示。 为什么？ 因为他们遇到了一个大毛病。

这是一个例子。 我的内耳失去了（至少）一条半圆形的管，导致眩晕。 我的耳科医生是世界上最顶尖的人之一。 他正在研究植入式陀螺仪。 当我四年前开始见他时，他说该设备将在“五年后”上市。

他每年都这样说。 最后，我受不了了。 两年前，我说：“我是项目经理。 如果您确实想取得进展，请每周而不是每年开始提问。 您不会喜欢这样的事实，它将使您的项目看起来花费更长的时间，但是您会取得更大的进步。” 他去年承认他接受了我的建议。 他认为他们还不到四年，而且正在取得更快的进步。

我了解团队是否得知他们在给定的一周内没有收到期望的答案。 我希望在给定的一周中看到的是某种形式的可交付成果：演示，一个问题或一组问题的答案，或者我们学到了一些东西并且产生了更多问题的事实。 如果我作为项目经理/项目经理看不到这三个结果之一，那么我想知道团队是否正在运行开放循环。

这三个结果中的任何一个我都很好。 他们为我提供了价值。 我们可以决定如何处理这三个结果。 团队仍然信任我。 我可以向管理层提供信息，因为我们仍在交付或学习中。 这些结果都可以提供价值。 （您看到演示，答案或更多问题如何带来这些结果吗？有时，您甚至可以获得生产质量的代码。）

为什么问题起作用？ 这些问题就像测试一样。 他们可以帮助您了解需要去的地方。 因为您（我的读者）使用软件工作，所以您可以使用代码和测试来比我的耳科医生更快地探索。 他必须开发一个原型，在实验室中进行测试，然后与动物一起工作，这使得一切花费了更长的时间。

即使您有硬件，机械设备或固件，我敢打赌，您还是要先模拟。 您可以每周询问所需的问题。 然后，您回答这些问题。

这是我过去从事过的一些项目，例如：

• 用微码编码FFT的内部循环。 我知道如何编写内部循环。 我不知道我在写的其他指令是否会使内部循环更快或更慢。 （大约在1979年。）
• 照明印刷电路板以用于机器视觉检查应用。 我们不知道找到正确的照明需要多长时间。 我们不知道我们需要什么算法。 照明和算法是相互依赖的。 （这是在1984年。）
• 与客户一起，我曾指导团队为各种应用程序开发固件。 我们知道团队必须达到的足迹以及组织要发布的日期。 这些团队不知道他们是否试图超越物理定律。 我每周帮助团队提出问题，指导他们的工作，看看他们是否陷入困境或取得进展。
• 当我为大型IT组织的企业架构师时，我使用了相同的方法。 他代表了一个数以千计的IT组织，该组织希望改进其整个体系结构。 我当然不知道建筑。 我知道如何使项目成功，这就是他所需要的。 他用这些问题来推动项目。

问题就像您的测试。 您采取科学的方法，问自己：“本周我需要回答哪些问题？” 你有个大问题。 您可以将该问题分解为较小的问题，本周可以回答（或希望）一个或两个。 使用可以帮助您探索的人，您会疯狂地探索。

探索性设计很棘手。 您也可以使其敏捷。 不要以为项目的其余部分可以等待您的重大突破。 使用诸如测试之类的问题。 每天进步。

感谢Rebecca Wirfs-Brock对这篇文章的评论。 任何剩余的错误都是我的。

翻译自: https://www.javacodegeeks.com/2014/11/make-stories-small-when-you-have-wicked-problems.html

雨后小故事动态邪恶