设置： Winform / ASP.NET MVC项目。 学习NHibernate SQL-Server驱动的应用程序
我与不知道如何为应用程序建模的客户合作。这就是我的意思。但是，我们在验证，误解等方面存在很多冲突。
例如，客户端将要求订单输入屏幕。屏幕应该需要“产品”。这很好，花花公子。但是，客户不知道告诉我用户不能订购“A级”产品，除非是星期二。
或者，他们需要一个时间输入屏幕。在投入生产前2天，他们随便忘了提到某些活动仅对某些情况有效。这些情况是一周的编码。
当然，这是一些粗略的例子（不是很多！）。但问题是让这些非技术客户布置他们的业务逻辑。他们不知道两周后会出现“A级”问题，等等。
我是敏捷编程的全部，但有一种简单的方法可以使这样的业务逻辑几乎每天都能轻松实现和更改吗？
我当然正在将项目分成有希望的智能部分，使用NHibernate等。但是，使这个BI逻辑变得如此动态，实际上很难设计时间线等。
有什么建议吗？我知道永远不会有一个完美的客户（或一个完美的提供者），但你们如何应对不断的错误理解？
感谢。
答案 0 :(得分：3)
问题在于客户总能提出一些完全离开的想法。 “哦，如果客户在周二订购了A类产品，而且恰好是他们的生日，请给他们50％的折扣和免费的B类产品。并通知主席给他们打个电话。”
您无法针对所有可能性进行编程。如果您计划为业务逻辑构建超级duper规则引擎，那应该是因为您的系统将被广泛部署并且需要由客户自定义。不是因为您的客户不知道他们想要什么 - 在这种情况下，您将构建一个系统来预测客户需求，而不是订购产品的系统（或其主要目的）。
也许我是老式的，或者也许是因为我有太多糟糕的经历，但我对敏捷开发并不感兴趣。你怎么知道旅行的方向，除非你知道你想去哪里？对于任何小于单个功能的简单应用程序，我（大致）遵循迭代瀑布方法，保持循环小。确保您拥有系统将执行的所有操作的完整文档。一旦客户签署了该协议，这就是他们所得到的。如果他们有任何更改，他们都会进入“版本2”，这将在版本1部署到生产中后启动。对他们有点恼火，但最终每个人都快乐得多。
是的，总有例外情况，例如管理层需要在2天内建立数据输入系统。但是要明确表示，如果他们按照你的要求添加任何要求，他们会自动给你额外的时间来实现它们。
答案 1 :(得分：2)
我强烈推荐埃里克埃文斯的书"Domain-Driven Design: Tackling Complexity in the Heart of Software"。这是一本优秀的书，教授如何与您的客户沟通，以便您更好地为他们的需求建模。
本书的核心是无所不在语言的概念......作为软件架构师，您在与客户交谈时通过称为建模的工具创建的语言。
作为一名建筑师，有一个基本的规则，你应该接受，因为它将极大地帮助你努力为你的客户提供商业价值：客户的工作不是很好地满足你的要求并整齐地包装在一个漂亮的盒子里，你可以打开和构建。作为客户和开发人员之间的中间人，您必须了解从客户那里提取需求是您的工作。
我为什么这么说？您的客户角色是业务，而不是软件开发。他们担心赚钱，以便他们可以支付他们的员工，广告商，他们的其他账单......并且可能在这个过程中赚取一些利润。他们并不关心软件的细节......他们用来完成工作的工具......工作。他们只关心工具是否能满足他们的需要。
如果您可以了解作为架构师，您的一个角色是“需求提取器”，您将变得更加成功。通过这种成功，您的客户应该更加快乐，这将使您更快乐，更满意您的工作以及您和您的开发人员创建的软件。这不是一件容易的事情......它采取了一种完全不同的方法。它需要更多的思想和远见，让您深入了解客户的需求......在他们做之前让您知道他们需要什么。如果您开发和使用无处不在的语言，随着您的项目的继续，每次与您的客户的会议都将得到改善，因为您们两个人将学习如何以具有明确定义的通用术语进行交流。
鉴于这一切，以下是一些可能帮助您在之前获得更好要求的示例：
<小时/> 客户： 因此，我们需要一个订单输入屏幕，我们可以输入产品订单。
Arch： 如果可以的话，我有一些关于业务规则的想法：
Arch： 对可订购的内容有任何限制吗？
客户： 哦！是的，我们不希望客户订购任何产品 A类，除非是星期二。
Arch： 很棒，这很有帮助。您是否提供任何组合优惠，因此如果客户订购产品X，他们可以以折扣价获得产品Y
客户： 嗯，不完全是。我们确实有促销优惠，如果客户输入某个促销代码，他们可以就一种或多种产品达成交易。
Arch： 好的，所以有类限制和促销优惠。还有其他可能影响订单屏幕的行为的内容？
客户： 嗯，现在你提到了它......
这是执行DDD时的常见情况。 （注意，这也是非常敏捷，因为DDD和敏捷一起工作。）在上面的对话框中，我有粗体和斜体的术语应该成为你和你客户的无所不在的语言的一部分。大胆的事情是客户用来描述有关其业务的某些事情的术语。这些术语成为您的“软件域”的一部分，这是您的客户业务的软件模型（至少是您为其编写软件的部分。）我使用了建筑师和开发人员使用的斜体术语，例如业务规则。如果您阅读Evan的书，他会更详细地解释如何开发无处不在的语言，以及如何使用特殊的可视化建模来使用无处不在的语言来设计您的软件。
希望这会有所帮助。希望“DDD：解决软件核心中的复杂性”这本书将会有所帮助。最终目标是，一旦与客户建立了良好的关系，就不会有任何（或很少）误解。
答案 2 :(得分：0)
让他们写下来！
AFAIK，cucumber can be used with .NET
Cucumber让客户（通过最少的培训）写下他们喜欢应用程序的行为方式。我对一家商店进行了一次信息采访，让客户用黄瓜写出所有BL，所以几乎没有误会，作为奖励，它鼓励非技术人员开始了解我们需要如何思考问题.-
答案 3 :(得分：0)
能够引出需求在任何行业都很困难，不仅仅是在IT领域，尽管围绕IT发生的“神秘”以及人们因此而做出的假设可能会有点复杂。
开放式沟通，频繁而有规律（我无法定期和频繁地强调）来自客户的反馈，现实的期望和一些关于如何构建系统的“切废话”，以及变更如何能够解决问题轨道导致了我处理的大多数人的理解他们需要花费大量的时间和精力与我一起预先从他们的头脑沟通到80％的需要做的事情。
剩下的20％是猜测工作，并且将通过渗透发生，不会发生，或者在延迟到最初截止日期之后发生。
但是因为他们事先知道这一点，所以他们并不感到惊讶，最终这一切都很好。
制作IMO的另一个重要实现是客户总是意识到他们想要不同的东西。它是正常的，而不仅限于IT。随着他们的愿景变得生动并且他们开始使用它，他们意识到在某些方面他们的想法是完全错误的。通过开放的沟通，频繁和定期的反馈，你可以很容易地及早地调整这个错误的过程，不应该造成太大的伤害。
由于他们付钱给我及他们的系统，他们可以要求任何他们想要的改变，只要他们也意识到它会带来变化，几乎总是花费成本而且往往是时间。