您如何在没有接受标准的情况下开发软件？

在没有接受标准的情况下，您如何在4-5个开发人员的团队中协作开发软件，而又不知道测试人员将针对哪些产品进行测试以及与多（2-3）个人充当产品所有者。

我们所拥有的只是一个粗略的“规范”，其中包含一些屏幕截图和一些要点。

我们被告知，这很容易，因此不需要这些东西。

我对如何进行一无所知。

附加信息

我们有一个艰难的截止日期。

客户是内部人员，理论上我们有产品所有者，但是至少有3个人测试该软件可能会使工作项失败，原因仅在于该工作项无法按他们认为的工作方式工作，并且对他们的预期或期望几乎没有透明度他们一直在测试直到失败为止。

产品负责人无法随时回答问题或提供反馈。没有定期安排的会议或与之通话，反馈可能需要几天的时间。

我可以理解，我们不能有一个完美的规范，但是我认为对于每个sprint中实际进行的工作都具有接受标准是“正常的”。

一个反复的过程将很好地做到这一点，没有详细的规格。

只需创建一个粗略的原型，征求客户的反馈，根据反馈进行更改，然后重复此过程，直到应用程序完成即可。

客户是否足够耐心地这样做，这是另一个问题。实际上，有些客户和开发人员更喜欢此过程。由于客户总是亲身实践，因此他（最终）将获得他想要的一切。

不用说，您不会以这种方式制定固定成本或固定时间的合同。

如果您说的是正确的，并且说明还差得远，甚至无法开始使用（并且您对此评估很诚实），我建议您采取以下方法：

1. 阅读草图和给出的“粗略”规范。
2. 将您自己的规范写到足以使您能够编码的水平。您可能必须做出大量猜测。
3. 向客户展示您的规格以供审查。注意他们喜欢的部分，并获得有关他们认为错了的部分的更多信息。
4. 重复步骤2和3，直到您和客户同步。
5. 您现在已经有了足够的规格。

如果您的客户说“这很容易”是对的，那么此练习应该只是小菜一碟。

如果您的客户错了，并且实际上需求中存在各种陷阱，那么您的规范草案将迅速说明问题并与他们沟通，指出他们错了（无需您指责或争论），因为这样做会就在他们面前并且很明显。同样，您的规范将成为解决这些歧义的绝佳讨论工具，并在您根据反馈的意见进行修改时将其作为关键决策的记录。

产品负责人将原型交给您。递给他更好的（直到您完成）

听起来您已经获得了一个纸制原型，可以开始该项目。那不是一个糟糕的开始。我建议您通过提供逐步可用的原型，以相同的语言与业务所有者进行交流。

您的原型应从纸张开始，移至数字样机，然后使用“真实”技术构建。

Treehouse为此提供了出色的指南，其结论是：

使用框架进行原型制作的奇妙之处在于，原型通常只是成为真正的网站，因为其结构和样式已经到位。如果要使用相同的框架，则无需从头开始重新创建网站。

您可能还希望提供正式的规范，尤其是如果您仍然担心因不良后果而受到指责时。但是您可能会从原型中获得更多反馈。

按时完成

请注意，您以后的工作将不会全部成为经典的“原型”，因为它们将不会是一次性的（或部分不会）。您在截止日期之前完成的最后一次，最有效的迭代。

截止日期是您定义的最明确的要求。有一些完整，连贯的东西可以按时交付。

与您的测试人员合作

如果这个松散的过程对您的公司来说是新事物，那么您的测试人员可能比您蒙受的损失更大，并且可能正在寻求您的指导。您必须在此过程的早期获得一些时间。让他们的老板知道您正在尝试帮助他们提供有意义的测试而又没有收到正式的接受标准。

找出测试人员是否有需要提供的公司，例如可以“返回”的测试证明文档。

尝试测试优先设计

由于您没有正式的要求，因此要开发测试用例就可以提供一些结构。

使您对Test First设计和/或测试驱动的开发有所了解，并根据需要为测试人员提供有关过程的指导。对于这样的快速项目，您无需在此过程中成为专家。但是，使用经过验证的方法论将对您和您的测试人员产生良好的影响。

坚持标准，尤其是对于UI

您对外观没有任何要求，但确实有最后期限。使用其他人的设计工作来最小化创建专业外观工件所需的工作。

为您的网站选择一个标准UI，除非/直到定向，否则请不要自定义它。我不知道您正在开发什么平台，但是Bootstrap或Google Material Design是两个示例。

交流但不要纠缠

我建议每天发送一封电子邮件给产品所有者。仅在紧急情况下发送更多。

如有疑问，请描述如果没有得到指导，将如何进行。例如：

此应用程序的用户是否需要通过移动设备访问它？现在，我们假设这将是仅台式机/笔记本电脑的系统。

不要惊慌

我参与了许多不了解“需求”一词的人们的项目。大多数项目都是成功的。放手的产品所有者可以让您自由地构建出色的解决方案。

请注意，这些项目中的某些项目所有者无法讨好他们，他们躲在“我太忙了...”后面，以此为借口。但是大多数人对最终结果感到“高兴”。

项目是在达到确定性之前减少不确定性的行为：

• 一开始总是存在一定程度的不确定性。有时，需求中有些含糊。有时候，这是非常粗略的。您必须将工作作为工作的一部分。
• 诀窍是迭代地减少这种不确定性（结合分析，设计和实现），完善用户案例并实现您的系统。
• 测试用例/方案和验收标准必须以相同的方式阐明。它们将有助于减少有关质量和正确性的不确定性。
• 最后，达到了足够的确定性：客户获得了满足其需求并且可以使用的经过测试的产品。

这就是逐步详细说明的原则：需求，标准和结果将逐步详细说明，客户也将通过参与开发过程来了解自己的期望和要求。

这有问题吗？

初始要求越粗略，不确定性越高，执行任务所需的时间也越长。因此，仅由谁来承担额外的工作以及由谁来承担费用的问题。

这两个问题的答案应该在合同中。或将进行谈判。客户必须接受其他参与（主要论点是“垃圾进，垃圾出”，尽管我强烈建议您以更外交的方式提出；-)）

“ 没有定期安排的会议 ”。那么，为什么不从安排定期会议开始呢？拥有多个产品所有者的事实本身就保证了您的项目将不容易，因为每个人都会有相互矛盾的要求，必须与在场的所有利益相关者亲自讨论。

另外，我真的，真的，真的建议您保留详细的决策日志。至少要写下某人已决定的所有内容，以及作出决定时的日期和在场人员清单。如果您可以写下原因，那么更好的决定是那样。不管是PC上的文件，Intranet Wiki中的页面还是桌面上的笔记本，都没有关系。日志保护了您和项目：当测试人员说某项“失败”时，您可以指出，与这些人决定的方式是这样，这不是您的问题，而是他们与测试人员之间的问题。如果这导致规格被更改，那就很好了，但是在这一点上，他们不能指望在他们所想到的任何截止日期前完成，否则他们必须将范围缩小。

一个没有明确要求，松散领导，没有完成定义（DoD），没有人愿意负责确保您拥有及时完成工作所需的信息并在截止日期之前完成的项目是项目的秘诀失败。

迭代开发不是一个坏建议，但是它需要产品所有者和开发人员之间的密切合作。尝试通过说：“我们知道我们将要遇到的问题。”可以定期与谁联系，确保他们得到答复，从而不会延迟项目交付？与某人安排定期的时间，以检查进度并消除障碍。如果他们没有显示或拒绝，则应进行有礼貌的书面信函跟进，并记录延误或未答复的情况。如果没有产品所有者，请他们提供可以的代表。

同样，迭代开发的另一个标志是需求的改变需要时间表的改变。 如果您不能制定时间表，则不能承诺按时完成任务；如果您不知道需要做什么，则不能制定时间表。不用徒劳地索要规格，而是查看当前规格，记录您或团队对应如何运作的任何疑问，安排与产品所有者的讨论时间，并记录答案。完成后，您将根据他们的决定获得规格，然后可以让产品所有者同意（以书面形式）。规范的目的是消除歧义并创建DoD，这正是Q＆A会话可以提供的功能。如果有人反对规范，请不要称其为规范。

当他们告诉你这会很简单时，不要相信任何人。有时候它确实听起来很简单，并且我可能相信（如果（且仅当））我足够了解产品所有者，以完全相信需求确实像他们所说的那样简单，而且我所遵循的规格提供的内容不言自明（如果没有，我安排一次问答环节并记录下来）。从操作的角度来看，我遇到过很多情况，从简单的角度讲很难做到从开发的角度来看，或者您认为自己已经完全完成，并且听到了绝望的话（“哦，顺便说一句，我们忘记了……”）。示例...“您所要做的就是从文档存储库中读取这些PDF文件，”在验收测试过程中，结果变成“哦，我们忘记了其中的某些内容是以完全不一致的方式横向读取的，并且有些人定义了错误的页面大小，有些人需要附加这三个页面，我们都需要它们显示相同的页面。这真的很容易修复，对吧？”

关键是，这可能真的很容易，快速会议可以确认这一点，使您可以记录所有假设并确认它们是正确和正确的。我确实建议站起来，以消除您编写符合他们期望的工作代码所遇到的障碍，因为无论您是否踩脚趾，无论如何最终都会有人不满意。如果您坚持要回答问题并激怒某人，当您按时交付符合要求的优质产品时，他们会忘记它。如果您无法得到澄清并且不发表意见，那么没有人会记得他们告诉过您不要对它们进行调试。

没有规格，您就有团队合作精神。敏捷。

坐在PO上，充实一个/一些小的开始故事。“我们将只提供这个屏幕，只有这个按钮会'bing！'。” 安顿一些AC。讲故事。 演示的故事。原来按钮应该是红色的。提出错误或新故事。传递会发出砰砰声的按钮。等等。

协同指定并交付经常展示的小的垂直切片。

如果客户不会以这种方式与您合作，请寻找出路。

正如您所概述的，我已经花了一些工作来做项目。只要PO知道您正在做出哪些设计决定以及为什么必须做出决定，您就可以了。另一方面，如果他们不理解设计决策，则需要至少按下它们以获取书面的用户接受测试文档。

在开始编写代码之前，您需要一个详细的，可验证的规范。这是事实，没有解决之道。

如果没有其他人愿意编写该规范，则开发人员必须编写它。因此您得到的规格不完整。您将其变成一个完整的规范（这意味着“除非有人告诉我，否则这就是我要实现的”）。您将该规范交给利益相关者，并给他们机会修改规范。只是一次修改规格的机会-不能通过说“我不喜欢这种方式”来取消规格说明。那时，这是您的规范，或者他们可以提供其他规范，但不能删除该规范。

从您的同事那里快速回顾一下，这可能会改善规格，这是一个好主意。但是无论如何，您都有一个规范，您可以相应地编写代码，测试人员也可以相应地进行测试。您已经完成了自己的工作：您已制定并实施了一个规范。如果规格不是客户想要的，那么这就是产品所有者或客户的责任，他们不愿意编写一个好的规格。