我注意到了 与任何客户合作与Web应用程序非常相似。 本文介绍了如何使用这些知识来改进流程。
关于谁是控制者，谁是被裁的模型。
本文假定读者知道什么是MVC 。
在构建模型时，我会进行简化。
- 关系中的所有参与者都是负责任的人，希望取得一个单一的结果。
- 考虑一个典型的定制开发。
演员们
客户 -订购产品或项目的人。 它可以是内部的，也可以是外部的。
公司（承包商） -与客户订立合同关系的一方。
经理 -与客户和最终执行者（程序员）互动的人。 它接受来自客户的任务作为输入，将这些任务转换为承包商，然后将结果返回给客户。
最终执行者是执行任务的程序员。 理想情况下，仅与Manager进行通信。
过程
定制开发过程如下所示：
- 客户为公司设置任务。
- 该公司充当路由器，将任务交给经理。
- 经理与客户澄清细节。
- 经理将任务设置给程序员。
- 程序员执行任务并转移完成的任务。
- 管理者确定缺陷并返回步骤4。
- 如果没有缺点，则经理将任务转移给客户。
- 客户确定缺陷并返回第3段。
- 如果没有缺点，则由客户付费。
公司最甜蜜的地方是第9段。但是到达它的路通常是漫长而棘手的。
这样的过程的问题
乍看之下，此过程中的所有内容都是正确的，没有任何可改进之处。 但是，事实并非如此。 我们重点说明问题。
一个非常糟糕的经理只是一个任务路由器。 我希望你很幸运，不要与这样的人一起工作 管理者 路由器。 我很幸运 与真正的经理一起工作时，也会出现问题。
经理通过在程序员的声音或聊天室中说出任务来设置任务。 关于此问题的说明未记录在任何地方。 程序员似乎理解问题的陈述。 但是我当然以我自己的方式理解它，而不是按照经理的解释（从经理的角度）。 由于问题的陈述不固定，因此每个参与者都以自己的方式对其进行解释。
通过这种方法，出现了许多迭代4-6和3-8。 好的管理者与坏的管理者之间的区别在于这些迭代次数之间的比率。 一个好的经理有一定的企图将一项任务移交给客户的尝试。 您猜到了，这种尝试立即成功了。 同时，迭代对于程序员来说可能是很多工作。 路由器不会对程序员进行任何检查，而只是将任务传递给客户。 并且迭代次数3-8达到最大值，并且等于迭代次数4-6。 当然，程序员应该为所有事情负责，因为从经理的角度来看，他做得很差。
在传递任务的过程中，管理器和程序员之间的大量通信导致它们之间的负面联系增加。 此外，完成任务的截止日期，成本超支等也受到干扰。 同时，我不介意在需求说明和任务设定阶段进行沟通。
如何避免此类不良现象？
社团协会
让我们看一下与客户合作的简化方案：
经验丰富的开发人员将看到与MVC的完全匹配：
进行实体比较非常简单。
- 客户=用户
- 经理=控制器
- 艺术家=模特
- 工作结果=查看
- 公司=整个申请
只是巧合？ 我不这么认为。 如果交互方案重合，那么您可以尝试将我们在开发中使用的方法应用于管理定制开发的过程。
解决的第一步
开发时我们拥有哪些工具？
我们定义应用程序层。 我们定义各层之间的交互契约，并将应用程序分解为模块。 让我们尝试在这里应用这些工具。
层数
担任通常职务的程序员不会与客户沟通。 他可以作为专家参与需求说明阶段。 在其他情况下，只有经理与客户沟通，从而将模型层与客户的直接影响隔离开来。
在将任务传递给客户的过程中，不应参与执行任务的程序员。 没关系 绝对不会
分解
大任务需要分为小任务。 一项小任务最多需要几天。
传统知识
每个人都知道这样的表达：没有明确的传统知识-HZ的结果。
在澄清要求时，客户应出现诸如职责范围之类的工件。 然后将问题陈述给程序员 丰富的 以传统知识为辅。 目前，我们不仅将本公司和客户之间，而且还将在经理和程序员之间接受此合同。
在任何一家普通公司中，传统知识都是这项任务必不可少的要素。 是的，这仅适用于大型任务。
在编程方面，传统知识似乎与合同非常相似。 我看到传统知识的问题：
- 对于大型任务，将有400页或更多的TK传统页面，程序员将无法完全适应。 我从第10页开始入睡。
- 对于一般任务，在ToR中将有一个指向节或段落的链接。 然后，程序员将只阅读该项目。 然后，当然可以发现，TOR的另一部分中的一小点将彻底改变整个实施过程
- 对于支持中的一项小任务，传统知识将一无所获。
- 开发过程的各方并不总是清楚地解释传统知识。 所有可能被误解的都是完全错误的和被误解的。
从这里可以看出，传统知识显然还不够。 问题是怎么办？
验收标准
在开发实践中，测试占据了上风。 测试证明了他们对质量开发的需求。
我们可以在实践中应用测试吗？ 是的，所以我们正在测试所有内容，即使是在描述其过程的过程中，一位细心的读者也会说。 是的，但是没有。 我在谈论其他测试。
在上述过程中的测试包括手动检查结果是否与所提供的传统知识相符。 参加此类测试的每个参与者都已经熟悉了TK，并以自己的方式解释了它。 问题在于每个人的情况都不一样。 人是不完善的口译员。 您需要将TK一次编译成二进制文件。 不要多次解释和以不同的方式解释。 并放在“纸上”。 结果，应该出现一组特定的工件。 这些可能是测试用例或验收标准。
经理应与客户一起制定验收标准。 接受标准并不与传统知识相抵触，而只是对其进行解释。 验收标准可以甚至应该成为单独的文件，由客户和公司签署。 然后，客户将按照相同的接受标准接受任务。
有了正确制定的接受标准，程序员就不会在ToR中有任何差异，甚至不会怀疑他应该做什么。
对于小任务，可能没有传统知识，但必须存在接受标准。 验收标准类似于在实施之前编写的测试。 这会让您想起什么吗？
为了描述接受标准，您可以使用BDD提供的Gherkin语言。 为了使其易于入门，您可以使用通常的俄语来描述它们。
异议
我预见到经理们的一个问题：
制定接受标准需要花费更多时间。 在哪里得到的？
您不花时间制定验收标准，而是将这些成本分摊到各个阶段。 很多人都花时间：经理，程序员，测试人员，客户。
但是您仍在制定验收标准。 并且不止一次。 在准备ToR时，分析师和客户的负责人会提出一些接受标准。 设置问题时，会发生相同的事情。 程序员在脑海中塑造它们。 在任何阶段交付任务时，都执行相同的过程。 但是在任何阶段都没有出现任何伪像。 就是全部了。
如果有接受标准，则可以大大减少客户接受任务之前的迭代次数。 负面沟通的数量自然减少了。 相应地，与客户的关系得到了改善，这是公司第一次通过该任务。
我敢向您保证，接受标准的发展将带来丰厚的回报。
结果
在引入验收标准和传统知识之后，流程将如何变化？
程序员按照验收标准进行工作。 经理接下工作。 然后，客户执行相同的操作。 而且他没有理由不为此任务付费。
它会始终正常工作吗？ 我想不是。 首先，在制定，制定验收标准以及与客户达成协议方面会出现问题。 这将导致程序员和客户重复迭代。 但它们的数量已降至最低。
您如何看待？