Programmer, Manager, MVC and Acceptance Criteria

I noticed. that working with any customer is very similar to a web application. The article shows how you can use this knowledge to improve processes.

About who is the controller, and who is the model under the cut.

This article assumes that the reader knows what MVC is .

When building a model, I go to deliberate simplifications.

1. All participants in the relationship are responsible people and want to achieve a single result.
2. Consider a typical custom development.

Characters

Customer - a person who orders a product or project. It can be both external and internal.

Company (contractor) - party to the contractual relationship with the Customer.

Manager - a person who interacts with the Customer and the final executor (programmer). It accepts tasks from the Customer as an input, translates these tasks to the Contractor and returns the result to the Customer.

The ultimate executor is a programmer who implements the task. Ideally, only communicates with the Manager.

Process

The custom development process looks something like this:

1. The customer sets the task for the Company.
2. The company, acting as a router, brings the task to the Manager.
3. The manager clarifies the details with the customer.
4. The manager sets the task to the programmer.
5. The programmer performs the task and transfers the completed task.
6. The manager identifies the flaws and returns to step 4.
7. If no deficiencies are identified, then the Manager transfers the task to the Customer.
8. The customer identifies deficiencies and returns to paragraph 3.
9. If there are no shortcomings, then the Customer pays for the work.

The sweetest point for the Company is paragraph 9. But the path to it is usually long and thorny.

Problem of such a process

At first glance, everything in this process is correct and there is nothing to improve. However, it is not. We highlight the problems.

A really bad manager is just a task router. I hope that you are lucky and you do not work with such managers routers. I got lucky. When working with a real manager, there are also problems.

The manager sets the task to the programmer by speaking it in his voice or in a chat room. Clarifications on the problem are not recorded anywhere. The programmer seemed to understand the statement of the problem. But of course I understood it in my own way, and not as the manager explained (from the point of view of the manager). Since the statement of the problem is not fixed, each of the participants interprets it in its own way.

With this approach, many iterations 4-6 and 3-8 appear. A good manager is distinguished from a bad manager by the ratio between the number of these iterations. A good manager has a unit number of attempts to hand over a task to a customer. And the attempt, you guessed it, is immediately successful. At the same time, iterations can be a lot of work with the programmer. The router does not double-check anything for the programmer and simply passes the task to the customer. And the number of iterations 3-8 reaches its maximum values ​​and is equal to the number of iterations 4-6. And of course, the programmer is to blame for everything, because from the point of view of the manager he did a poor job.

A large number of communications between the Manager and the Programmer in the process of passing the task leads to an increase in the negative between them. In addition, the deadlines for completing the task, cost overruns and so on are disrupted. At the same time, I do not mind communications during the specification of requirements and at the stage of setting the task.

What to do to avoid such undesirable phenomena?

Associations

Let's look at a simplified scheme of working with the Customer:

An experienced developer will see a complete match with MVC:

It is very simple to carry out a comparison of entities.

• Customer = User
• Manager = Controller
• Artist = Model
• Work Result = View
• Company = Entire Application

Just a coincidence? I don’t think so. If the interaction schemes coincide, then you can try to apply the approaches that we use in the development to the process of managing custom development.

First steps to fix

What tools do we have when we are developing?

We define application layers. We define the interaction contracts between the layers and break the application into modules. Let's try to apply these tools here.

Layers

The programmer in his usual role does not communicate with the customer. He can be involved at the stage of specification of requirements as an expert. In other cases, only the manager communicates with the customer, thereby isolating the model layer from the direct impact of the customer.

In the process of passing the task to the Customer, the programmer who performed the task should not be involved. Never. Never ever.

Decomposition

Big tasks need to be divided into small ones. A small task is a task for a maximum of a couple of days.

TK

Everyone knows the expression: Without a clear TK - the result of HZ.

When clarifying the requirements, an artifact such as the Terms of Reference should arise with the Customer. Then the statement of the problem to the programmer enriched complemented by TK. For now, we will accept this as a contract not only between the Company and the Customer, but also between the manager and the programmer.

In any normal company, TK is an indispensable element to the task. True, this applies only to large tasks.

It would seem that TK is quite similar to a contract in the context of programming. What I see problems with TK:

1. For a large task there will be TK of pages of 400 or more, which the programmer will not fit in his head entirely. I'm starting to fall asleep on page ten.
2. For an average task, there will be a link to a section or paragraph in the ToR. Then the programmer will only read this item. Then, of course, it turns out that one small point in another section of the TK drastically changes the whole implementation
3. For a small task that is part of the support, TK will not be at all.
4. TK is not always clearly interpreted by the parties to the development process. And all that can be misunderstood will be exactly wrong and misunderstood.

It can be seen that TK is clearly not enough. The question is what to do?

Acceptance criteria

In development practice, testing takes pride of place. Tests have proven their need for quality development.

Can we apply tests in our practice? Yes, and so we are testing everything and even in the description of the process it is, an attentive reader will say. Yes, but no. I'm talking a little about other testing.

Testing in the process described above consists in manually checking the compliance of the result with the established TOR. Each participant of such testing, having familiarized himself with TK, somehow interprets it in their own picture. The problem is that everyone has a different picture. Man is an imperfect interpreter. You need to compile the TK into the binary once. Do not interpret many times and in different ways. And once on the “paper”. As a result, a certain set of artifacts should appear. These may be test cases or acceptance criteria.

Acceptance criteria should be developed by the manager together with the client. Acceptance criteria do not contradict TK, but only explain it. Acceptance criteria can or should even become a separate document, which is signed by the Customer and the Company. Then the customer will accept the task in accordance with the same acceptance criteria.

With correctly formulated acceptance criteria, the Programmer cannot have any discrepancies in the statement of work and even doubt what exactly he should do.

For a small task, there may not be TK, but acceptance criteria must be present. Acceptance criteria are similar to tests that were written prior to implementation. Does this remind you of anything?

To describe the acceptance criteria, you can use the Gherkin language that BDD offers. In order to make it easy to start, you can describe them in the usual Russian language.

Objections

I foresee a question from managers:

The development of acceptance criteria takes extra time. Where to get it?

Without taking the time to develop acceptance criteria, you are spreading these costs at all stages. And very many people spend time: manager, programmer, tester, customer.

But you still develop acceptance criteria. And more than once. In the preparation of the ToR, some acceptance criteria arise in the head of the analyst and the customer. When setting the problem, the same thing happens. The programmer shapes them in his head. At the time of delivery of the task at any stage, the same process is performed. But at no stage did any artifact appear. That’s the whole difference.

If there are acceptance criteria, the number of iterations before the customer accepts the task is significantly reduced. The number of negative communications is naturally reduced. Correspondingly, the relationship with the Customer is improved, to which the Company passes the task the first time.

I dare to assure you that the development of acceptance criteria pays off handsomely.

Result

How does the process change after the introduction of acceptance criteria along with TK?

The programmer does his work in accordance with the acceptance criteria. The manager takes the job. Then the Customer does the same. And he has no reason not to pay for this task.

Will it always work without any glitches? I guess not. First, there will be problems with the development, formulation of acceptance criteria and their agreement with the Customer. And this will cause repeated iterations with the Programmer and the Customer. But their number is minimized.

What do you think about this?