用非技术人员建模业务逻辑

问题是,客户总能想出一些完全左撇子式的想法。”哦,如果顾客在星期二订购了a级产品,而正好是他们的生日,给他们50%的折扣和免费的B级产品。通知主席给他们打个电话。”

你不能为所有可能发生的事情编写程序。如果您确实计划为业务逻辑构建一个超级duper规则引擎,那应该是因为您的系统将被广泛部署,并且需要由客户定制。不是因为你的客户不知道他们想要什么-在这种情况下,你将建立一个系统来预测客户的需求,而不是一个系统来订购产品(或者不管它的主要目的是什么)。

也许我是个守旧的人,也许是因为我有太多不好的经历,但我对敏捷开发一点也不感兴趣。如果你不知道你想去哪里,你怎么知道该往哪个方向走?对于任何比一个小的、单一函数的普通应用程序更重要的事情,我(大致)遵循一个迭代瀑布方法,保持周期很小。确保你有一个完整的文件,系统将要做的一切。一旦客户签了字,他们就得到了。如果有任何更改,它们都将进入版本2,该版本将在版本1部署到生产中后启动。对他们来说有点恼火,但最后每个人都高兴多了。

我强烈推荐这本书 "Domain-Driven Design: Tackling Complexity in the Heart of Software"

这本书的中心是无处不在的语言的概念…作为一个软件架构师,你可以在与客户的对话中,通过一个叫做建模的工具来创建一种语言。

作为一个架构师,有一个基本的规则是你应该接受的,因为它将极大地帮助你努力向你的客户交付商业价值:客户的工作不是把所有的需求都很好地和整齐地包装在一个漂亮的盒子里,你可以打开和构建。作为客户和开发人员之间的中间人,了解从客户那里提取需求是您的工作是至关重要的。

我为什么这么说?您的客户角色是业务,而不是软件开发。他们关心的是赚钱,所以他们可以支付他们的员工,他们的广告商,他们的其他帐单…也许在这个过程中赚取一些利润。他们不关心软件的细节…他们用来完成工作的工具…工作。他们只关心工具做他们需要的事情。

如果你能从架构师身上学到这一点,你的角色之一就是“需求提取器”,你会变得更加成功。有了这样的成功,你的客户应该会更快乐,这会使你对你的工作和你和你的开发人员创建的软件更快乐、更满意。这不是一件容易的事…它需要一个完全不同的方法。它需要更大的胸襟和远见,让你洞察客户的需求…让你在他们做之前知道他们需要什么。如果你开发并使用一种无处不在的语言,随着你的项目的继续,每次与客户的会面都会得到改善,因为你们两个都学会了如何用定义明确的共同术语进行交流。

鉴于上述情况,以下示例可能有助于您更早地获得更好的需求:

拱门: 业务规则
拱门:
客户: 客户 订购任何 属于

拱门: 太好了,这很有帮助。你们提供联合交易吗,如果 顾客 订购产品X,他们能打折得到产品Y吗?
客户: 促销活动 促销代码
拱门: 等级限制 和 促销活动 . 还有什么可能影响 订单屏幕的?

客户: 嗯,既然你提到了。。。

这是执行DDD时的常见场景(注意,这也是非常灵活的,因为DDD和Agile是手拉手的。)在上面的对话框中,我用粗体和斜体字写了一些术语,这些术语应该成为您和您的客户语言的一部分 通用语言

希望这有帮助。希望《DDD:解决软件核心的复杂性》这本书能起到更大的帮助。最终的目标是,一旦你与客户建立了良好的关系,就不会有任何(或很少)误解。

就我所知 cucumber can be used with .NET

Cucumber 让客户机(通过最少的培训)编写他们希望应用程序的行为。我对一家商店做了一次信息采访,让客户用黄瓜写下所有的BL,这样就没有什么误解,作为奖励,它鼓励非技术人员开始了解我们需要如何思考问题-

开放的沟通,客户的经常性反馈(我不能强调经常性),现实的期望,以及一些关于系统是如何构建的“废话”,改变如何让事情偏离轨道,这让我所面对的大多数人都明白,他们需要投入大量的时间和精力与我进行沟通,从他们的头脑到我的头脑,80%的事情需要做。

剩下的20%是猜测工作,要么会发生耳濡目染,不会发生,或将发生后,推迟到最初的最后期限。

IMO的另一个重要认识是,客户总是会意识到他们想要不同的东西。这是正常的,但不限于此。当他们的愿景变成现实并开始使用时,他们意识到他们的想法在某些方面是完全错误的。有了开放的沟通,频繁而定期的反馈,你就可以很容易地、很早地从这个错误的过程中调整过来,以免造成太大的损害。

既然他们是在支付我和他们的系统,他们可以要求任何他们想要的改变,只要他们也意识到这会带来变化,几乎总是成本和时间。