Evaluation and planning in software projects - without cuts

Good day friends!

We continue a series of “no-bills” publications about development-related projects, often with the “web” prefix. Today we will talk about how to most correctly and quickly conduct work evaluations and plan releases of a software system. Most likely, novice managers and energetic and self-seeking developers will be shocked by the recommendations, but believe me, there is one goal and only one: to help and make you a real Jedi, who brings company benefits, moves projects, and develops people at the same time. Such a Jedi, who sincerely does not deserve to be discovered as a mummy in a dark server between the racks with web servers and databases of a web project flying into the future without a mentally documented code, the TK is only on the energy of pure "X." So let's go!

Performance and close analogues

It is important, extremely important, especially the key project strength - for developers, excellent specialists, who daily shake their skills in modern IDEs, to understand that the lack of common sense in evaluating work begins even before the desire to “conceive an idea”. Especially often it happens in web development, where during the tender you need to take and pretend that the politicized problem of chicken and eggs has a “strict solution”:

The client still does not know what he wants, or he knows very vague and contradictory (that is, he does not know, but he strongly wants and, most importantly, on time!)
The client wants the engineers to calculate the cost of “I don’t know what yet” and is offended if they don’t really fall into this assessment.
The client wants the engineers to fit in with the deadlines and launch “I don’t know what yet”, say, on September 1, and so that, of course, “don’t know what yet” have no mistakes
The client often delegates clarifying the details of “I don’t know what yet” down the hierarchy to employees who, surprisingly, begin to play “hide and seek of the mind”, laugh it off, shuffle with a leg, slam the door and pull the rubber!

It will become a little easier if you find close analogies to the strange performance described above in the surrounding nature:

beautiful courtship of the male to the female ... domestic disassembly in the kitchen
buying potatoes on the market
fortune telling, astrology, numerology
Cthulhu sacrifices, etc.

It is clear that so far it has not become easier, especially if we recall that “certified psychologists” on both sides often participate in the performance, able to look convincingly, decisively, saying “yes, of course, do it!” And not understanding the basic principles of software development. And if you remember that sometimes “looking confidently” at both ends of the project cross the front line, fraternize, join together and begin to sincerely indignantly demand something specific from engineers, without providing clear formalized answers to clearly asked questions ... - I just want to go to academic holidays in Antarctica and forgetting, hugging penguins and cold-water, but no less beautiful from this, mermaids :-)

Push of love

Soberly and analytically strictly perceive the above described performance to engineers rather painfully to the point of bleeding from their eyes, therefore they make several well-known psychological steps approximating specifics and real work:

Need to smile at each other
Need to say yes, even if there is NO confidence
We need to promise to help each other
You need to knock yourself on the chest (like KinKong) and demonstrate confidence!
~~Need to swear in love to the grave~~

But seriously speaking, at this stage it is necessary to realize very clearly all the members of the project team:

that there is still to understand the details and a lot of interesting and unexpected pops up, but once you have smiled at each other, you’ll manage to solve it together
if deadline is appointed, then you need to unravel the emotional mess as quickly as possible, estimate and start to do the most important things on the descending things and something will always not be done and this is correct
the more emotional and political porridge in the beginning, the more time must be allocated to the analysis and design phase

So, at the end of the performance, there should be a steady push forward into an unknown future, and in a good, cheerful mood and mutual desire to listen and hear each other.

“Stillborn” Projects

Unfortunately, sometimes literally immediately there is an understanding that the project being launched ... nobody needs it, twitches, freezes and will be thrown into the archive:

The project has no clear, charismatic goal. You just need to do something, because it is not clear what to do more important. Therefore, you need to do at least ANYTHING, the salary is charged - there must be a reason :-)
Attempts are being made to find not the “engines” of the project team, energetic people who inspire themselves and others and believe in achieving the goal, but are looking for those responsible (who can be blamed for everything in case of problems). Feel the difference.

Effective types of performances

It is gratifying, but often there are also regular starts of projects, which can be distinguished by the following signs. Stick to this list and try to get into such commands by hook or by crook:

There are one or several people burning with ideas and sincerely believing in achieving the goal. The charisma and warmth emanating from them will allow the project team to be flexible and smooth out any misunderstandings and misunderstandings.
From the client’s side, there is an adequate awareness of the uncertainty of one’s own desires, risks, and the desire to meet engineers. There is an awareness that you have to strain your head many times and think, even if you, as a client, have already paid for everything.
On the client’s side, there is either, or ... THERE is an understanding of the need to attract a critical mass of gray matter in the form of adequate analyst (s) and subject matter experts who are capable of explaining the subtleties of the upcoming business logic without "e ... s ... wow ..." project.
On the client side, there is a desire to achieve business goals in the shortest and quickest possible way. I remember the project where the client wanted and spent a lot of time on “a beautiful, clever web-site admin panel” for employees and seriously missed the business problems lying on the surface.

But keep in mind - a meeting with such a prepared client will mean for the engineering team to descend from the promised IT skies, sweat, labor and blood. All knowledge of design patterns will be shaken out of you, they will teach you to write simple code immediately without errors and you will reject the desire to make a class factory out of 20 lines instead of a scripter for PHP as a demonic temptation. In the morning, pouring coffee, you are surprised to find that the client, after (after!) Your testing department, found and registered another 30-40 bugs in the bug tracker and recommends that you (you!) Write unit tests more thoroughly and change testers' brains ... But it pumps well :-)

So how to evaluate a software project?

I will speak straight. Reasonable people, incl. engineers understand that it’s impossible to evaluate something that has not yet been invented, to put it mildly ... One can only lie confidently. But, as you know, formal mathematical logic does not work for everyone, so sometimes, nevertheless, you will meet interlocutors who claim that 1 + 1 = 11, and it is so convincing that even tears may appear in the eyes.

But the way out is: an analogy. Not for nothing in the modern Agile approach exactly the analogy is used as a fundamental assessment brick. Working examples of analogies in web development:

It is necessary to make a typical online store. And we already did them a couple. We voice the assessment adjusted for the adequacy of the client / experience of the team in the form of the Fibonacci number.
We evaluate the feature in story-points , but not in man-hours. And we take 1 store-point as the complexity of creating, say, an information block with a list of news .
Sometimes you can roughly determine the type of web project by the number of standard modules in it and the proportion of customization. If there were similar types of projects with similar or similar sets of modules and customization, you can safely use the analogy.
Sometimes they give an approximate estimate, measuring the thickness of the TK in millimeters. I am absolutely serious - I saw it and, surprisingly, it works.

It is important to use an approach with analogy and to the qualifications of the team:

These boobies were screwed together for four weeks and then 2 weeks the bugs ruled. Multiply the score by 10.
This developer can integrate the site with the layout for the week. Add 3 more days on top for good behavior.

Something like this. Yes, you can argue, what about PMBoK, Gantt chart, Velicity , cards in Kanban, thick books on “Agile Estimation”, team acceleration, metrics, petriks? ~~Frankly speaking, it does not work and I~~ will draw an analogy with “machine learning”.

Machine learning and estimation

You will be taught 5 years of 50 types of mathematics at the university, then another six months on expensive courses about DataScience and MachineLearning, and then in practice you suddenly find out that ... there is no scientific approach in this area, you need to go through all the options for hyperparameters, only time for that no one will give (days and months) and remains divine random brute force and, most importantly, INTUITION. And nothing remains, as ... to return and begin to read the theory on the courses. So with the evaluation of work in software projects - a lot of theory, but only a grain of knowledge, implicated in deep intuition and, what is the same, experience, work in practice.

To really learn how to evaluate the complexity of programming, you need to leave the cities, live with the aborigines, eat raw meat, drink warm pulsating blood flakes - stay closer to nature = code, bugs, production, bearded administrators, sleep a couple of nights in the server room and ... learn how to do plank , instead of toilet paper. Minimalism and the desire to do simple and clear - will allow the team to get into the assessments much more often, and the client - to fly up quickly. In fact, it is necessary to cultivate and introduce this saving culture into the project as quickly as possible.

Known Abuse

It's funny, but sometimes such abuses of evaluations come across, causing a smile to experienced engineers:

It is written a huge TK per 1000 pages, which is beginning to become obsolete and “smell” not the next day. Nobody read it to the end, but they often refer to it. It is contradictory, watery, politically and neerotically. But he was assessed, cut at iteration, they were also assessed, and now everyone is trying to fit into this logical hell.
It creates a huge Gantt chart. Because requirements are constantly being discussed and changed; a department for the movement of stripes in the Gantt chart is allocated - they sit and move all day long
Features are evaluated and stored in the mailbox. No one except the manager saw all the features and ratings. The manager suddenly takes his own life and the project ... closes.
There are boards and markers, but felt-tip pens, either long-standing or permanent, and writing something obscene on the board during a show of communication and evaluation, it’s impossible to erase it :-)

Useful and working evaluation practices in software projects

If you have read the post up to this point, then obviously you are no longer in the category “the more paper there is, the cleaner it is”, “you ask the wrong question”, “you set the task not mathematically”, but really want to do program project in adequate time and for reasonable money. We fix the following really working practices:

"Simple, average, difficult." Yes, we consult with an expert developer, or a team and set a rating of 3 possible for each feature in ProductBacklog. It is advisable to go through all the known features of the project and put at least such an assessment. It is possible and necessary, having only it on hands - to plan releases already.
"Planning poker". There is a lot of information on this topic, but if you ensure during the evaluation a healthy and positive atmosphere of communication and trust between you, the team members and the client, then it works well.
"Call a friend." If you have either a company / team, or on the side, a familiar expert developer, talk to him. Unfortunately, sometimes the teams conspire and try to stretch the time - the expert can give an adequate assessment of the implementation.
Features and communications are maximally visualized. Separate cork boards stand out, leaflets with features hang on them, people come up, discuss, draw on other boards that have attention, not dried flamasters and a working washer. Here is a great resource on this topic.

Tools and effective practices are often more important than plans and deadlines.

I hope it has become clear and obvious that even if the requirements for a software project are very clear and formalized (it happens, though rarely), it may arise, due to the inexperience of an engineer or analyst, so many sudden surprises that ... only intuition and the method of analogies work well. Let us examine the examples of surprises - you need to know the enemy in person:

Even if laws created by legislative authorities all over the world can often contain water and logical contradictions that cause physical brain pain, then what about TK. Naturally, when a contradiction is found, it is urgent to make changes to the code. The change is made quickly, and the system breaks down after this so that N-days are restored and it is impossible to predict N scientifically!
There is a conflict between software libraries and you need to either turn off one of them, or gladiolus. It is impossible to predict a simple one.
During even a small load, the inadequacy of the chosen algorithms is detected (the algorithmic value of the use cases was underestimated ), which is why the system begins to slow down. You can find and fix the problem in both hours and months. It is impossible to predict. Experience, only experience, or boxed solutions .
The lead developer overworked before the release and began, under the influence of surging emotions, to urinate in the server room on a rack with web balancers. Iron shorted out. Sudden simple - 2 days.

Considering the above unavoidable risks, it is customary to act differently - using the system bunker war (remember StarCraft) and tactics: use proven engineering practices and tools and believe that by adhering to this tactic, we will achieve strategic goals. I will say the same thing easier: if you push up, run, press the expander and do the bar in the evenings, then the chance to get to the house in the evening is much higher. If you plan to protect against hooligans in the Gantt chart, calculating the probability of getting 2 or 3 people depending on the way home and the time of year - it will be more difficult, and much longer and any changes in probabilities will need to be taken into account every day :-) We are each other , in general, understood.

Boards, markers, wikis - for maximum open communication with each other and with clients
Rounding project. Instead of killing communication and introducing distorted information and slow-corrupted hierarchy phones, the project is rounded so that all team members and client representatives are available at the elbow distance.
TK is not somewhere, but hung on boards, walls and as many people as possible can “read” and discuss it.
Available assessment tools by analogy, archive of previous assessments, accessible to everyone
Developers write automated unit, modular and integration tests to the code. Roughly tests should be as much code
Usually in any software project there are several places that are covered with fog and demons are found in their pools. It is necessary as soon as possible to raise the prototypes, reflecting these places and carry out load and other tests and get an estimate from them. This assessment is very useful in the later stages of the project.

Covering the project with the right team communication tools and adopting a simple but correct system of tactical values and transferring, as far as possible, to their client - the chances of fitting in the assessments and releases are greatly increased. And no one will give us any more guarantees - this is a fact of life.

Total

Let's sum up. In short, we saw from different sides that smart-long-politicized methods of evaluating software projects in a bunny-parrot-clock only work on test data in ideal conditions, but not in practice. The situation repeats the approaches and results in machine learning - you can learn a lot and for a long time to understand that only intuition / experience / analogy works. It is extremely expensive to sort everything out beforehand in detail into formal cubes and, as a rule, there is no time for that. In the real world, for evaluation it is best to rely on the analogy method, simple prioritized lists of features, without any hierarchies and interdependencies. Developers need to make the code self-documenting, do not rely on the immediately fading TK and write autotests to the code. Implementing and adhering to the values of the most open communications, visualization of the requirements of the software project, a warm and inspired atmosphere, simple categorical assessments - will make for getting on the release date much more than the endless shifting of abstract sticks in Gantt charts and others like it. In this and only this case there is every chance to see the project team with champagne in their hands, with smiles marking the completed release, which coincided with the New Year. And about the mummy of the manager in the server room - it just seemed to you :-)

Happy holiday everyone and a good mood!

Tags: