The book “Pure Agile. The Basics of Flexibility

Hello, habrozhiteli! We have handed over to the printing house another novelty! Nearly twenty years have passed since the Agile Manifesto appeared. The legendary Robert Martin (Uncle Bob) realized that it was time to shake off the dust from the principles of Agile, and again to tell about the flexible approach not only to the new generation of programmers, but also to specialists from other industries. The author of the books “Clean Code”, “Ideal Programmer”, “Clean Architecture”, which was loved by IT people, was at the origins of Agile. Pure Agile eliminates the misunderstanding and confusion that, over the years of Agile’s existence, have made it harder to use than the original plan. In essence, Agile is just a small selection of methods and tools that helps small teams of programmers manage small projects … but leads to great results, because every large project consists of a huge number of bricks. Five decades of working with projects of all imaginable types and sizes allow Uncle Bob to show how Agile should actually work. If you want to understand the benefits of Agile, do not look for easy ways – you need to use Agile correctly. Pure Agile tells you how to do this for developers, testers, managers, project managers, and customers.

Excerpt. The first thing to know

What is the first thing you need to know about the project? Before you find out the name of the project or the requirements for it, before you make any movements at all, you need to get some more information. Of course, these are the deadlines. After the dates are selected, they need to be fixed. There is no point in discussing the terms, because they are set in connection with objective business reasons. If September is due, it’s not just that. Perhaps in September some kind of exhibition or shareholders meeting is planned, or maybe the funds will simply run out. Whatever the reason, it has some important background. And the reason will not change simply because to some of the developers the volume of tasks seems overwhelming.

At the same time, requirements can change in a continuous stream that cannot be fixed.

And there’s also a reason for this – customers often don’t know what exactly they want. They seem to know what problem they need to solve, but translating such knowledge into project requirements is always difficult. Therefore, there is a constant reassessment and rethinking of requirements. New features are added.

Some old ones disappear. The user interface changes quickly – in weeks, if not days.

This is what the world of software development looks like. In this world, deadlines are fixed, and requirements are constantly changing. And somehow, in the context of all this, developers need to successfully complete the project.

Collection

The cascading model prophesied to us a way to bypass this task. To explain how seductive and ineffective it was at the same time, I will cite one meeting as an example.

It was the first of May. Big boss called subordinates to the conference room.

The boss began: “We have a new project. It is necessary to finish it by the first of November. We have no requirements yet. They will be announced to us in the next couple of weeks. How long will it take to analyze the project? ”

We began to look questioningly at each other. Everyone was silent, afraid to say too much. No one had any idea what to answer. Someone mumbled: “So we have no requirements, what should we start from?”

“Imagine that they are! Yelled the boss. “You know how everything works.” You are experts! I do not need exact dates. I just need to fill out the schedule somehow. Keep in mind that if it takes more than two months, you can confidently forget about the project. ”

Someone muttered questioningly: “Two months?” The boss took it as agreeing to the conditions: “Great! Just what I was thinking. Now tell me how much the design takes? ”

And again everyone froze in bewilderment, the room was filled with dead silence. We count. And we realize that until the first of November only six months. The conclusion suggests itself. “Two month?” – you ask.

“That’s right! – the big boss smiled radiantly. – As I thought. And we have two months left for implementation. Thanks to everybody, you’re free!”
Many readers probably remembered that something like that already happened to them. Who did not have this, well, you are lucky!

Analysis stage

So, suppose we left the conference room and scattered around the offices. What to do next? The analysis phase begins – that means you need to analyze something. But what exactly do we call analysis?

If you read books on the topic of analysis in software development, you will find that each author gives his own definition. There is no consensus on what analysis is. It may be the creation of a structural decomposition of requirements. Or maybe – detection and specification of requirements. It may be the creation of a fundamental data model or object, and so on … The best definition of analysis is this: that is what analysts do.

Of course, there are obvious things. We need to evaluate the size of the project, to forecast indicators of the main technical, economic and human resources. You need to make sure that the work schedule is feasible. This is the least that the company will expect from us. Whatever is called analysis, this is exactly what we were going to do in the next two months.

This is a kind of favorable phase of the project. Everyone calmly browses the Internet, conducts small transactions, meets with customers and users, draw beautiful graphics, simply put, have fun.

Then the first of July a miracle happens. The analysis is complete.

Why do we think so? Because it is already the first of July. If, according to the schedule, the analysis stage should be completed on the first of July, then this stage is completed on the first of July. We’re not late, are you? Therefore, we will arrange a small party with balloons and fiery speeches, celebrate our transition from the analysis stage to the design stage.

Design phase

What to do now? Of course, we will design. But what constitutes design?

We know a little more about the software design phase. At this stage, we break the project into separate modules and design the interfaces between these modules. At this stage, we also assume how many teams we will need and how these teams will be interconnected. In general, the schedule of work needs to be clarified in order to draw up a plausible feasible implementation plan.

Of course, at this stage, something unexpectedly changes. New features are added. Old functions disappear or adjust. And it would be nice to look back and analyze the changes again, but time is money. Therefore, we are trying in every possible way to make changes to the design.

And then a new miracle happens. On the first of September we suddenly complete the design. And why? Yes because. The first of September. According to the work schedule, we should have already finished. No need to hesitate.

So one more party. Balloons and speeches. And we break through to the next stage – implementation.

It would be great to crank up such a scheme once more. Oh, if in the same way it would be possible to complete the implementation phase! But it will not work out that way. Because upon completion of the implementation, it is required to complete the entire project. Analysis and design do not bear fruit in binary form. They do not have unambiguous criteria for completeness.

There is no objective way to know if they are held in reality. Therefore, it turned out to complete these stages on time.

Implementation phase

But the implementation just has distinct criteria for completeness. Here it is no longer possible to accurately fool around, giving the imaginary result as valid.
At the implementation stage, the ambiguity of the tasks is completely absent. We just write the code. And we have to write the code in a hurry, sticking out our tongue, because four months were simply thrown into the wind.

Meanwhile, project requirements continue to change. New features are added. Old functions disappear or adjust. We would have to go back, conduct a new analysis and make changes to the design, but … there are only two weeks left. And at an accelerated pace, we drive all these changes into the code.

As we look at the code and compare it with the design result, we realize that we must have been out of place at the design stage, because the code itself has little to do with what was originally depicted on the wonderful graphs. But there is no time to think, because the clock is ticking, and overtime is becoming more and more.

Around October 15, someone says, “Hey, what’s the date today?” When to take it? ” And here we understand that there are only two weeks left and by the first of November we will never finish. And suddenly, for the first time, our customers find out that there are some problems with the project.

Imagine their indignation. “And at the stage of analysis it was impossible to say about this? Wasn’t it then that you should have estimated the size of the project and carefully calculated the work schedule? And why didn’t they say at the design stage? Wasn’t it then necessary to divide the project into modules, distribute the work throughout the team and calculate the human resource? Why do we find out everything two weeks before the deadline? ”

And they are right, aren’t they?

Survival marathon

And the survival marathon begins. Customers are angry. Stakeholders have come to the extreme. The pressure is rising. We work overtime. Someone leaves the project. Just hell!

And already around March, we grieve in half with a result that only half meets the requirements of customers. Everyone is upset. Everyone gives up. And we swear to ourselves that the next time this will not happen. Next time we will do everything wisely. The next time the analysis and design will be performed in good faith.

I call it the bloating out of control process. We are going to work even better next time using a method that does not work.

»You can pre-order at publishing site

Upon payment of the paper version of the book is sent by e-mail pdf with the first 105 book pages.