The future of agile software development
Software penetrates into all the gaps of human society. We know the weather through the Internet, and not through a normal thermometer outside the window. We're going to a new address with a navigator, rather than looking for a G7 square on page 59. We turn on RunKeeper when we ride a bike to find out the average speed and boast on Twitter. We use software every day. Perhaps most of the life we ​​already embrace with your favorite gadgets and software, and not with your loved one.
The problem is that no one knows how to actually write cool software quickly and correctly. Waterfall died safely at the turn of the century, and new development methods (agile) are still unable to solve fundamental problems. We live in a very interesting time. At the moment, there is a rapid development of the entire software development industry and the basis for a qualitative breakthrough is accumulating.
It is clear to all that agile becomes the mainstream and very soon on masters will work separate mastodons with a predetermined end to life. Agile won the race. Microsoft improves agile support for TFS and uses iterative development on many products. IBM launches agile platform Jazz. Even SAP implements agile (I would like to look at it)
')
And here is a quote by Wolfgang Gatner, CIO of Deutsche Bank
“We must move forward. Traditional methods are not fast enough. They are too complex and hinder innovation. This is clearly clear. ”
At least, almost all companies are beginning to understand that previous software development approaches do not work. They try to change things and agile is seen by many as the best solution at the moment. But the question is, how radically does agile software development improve? Improves But does not solve all problems. Still released terrible sucks. As before, the speed of development leaves much to be desired. As before, the quality of many decisions does not stand up to criticism, is full of bugs and makes itself felt at every convenient and especially not convenient occasion.
Take at least the recent drop in Amazon servers that lasted several days. Our server lay for almost a week! Skype regularly crashes (especially after its purchase by Microsoft). Everyone remembers dancing with a tambourine to make it work.
Periodically there are problems with iOS. For example, my phone after the next update refused to go into standby mode and landed the battery for 8 hours, not to mention the occasional clicks and calls. It is terribly annoying. I've been waiting for fix for almost a month!
Do the right thing
Let's go through the three fundamental problems of software development. The main task is to do the right things .
What do you mean right? It means necessary, solving concrete problems, and solving these problems well. There are several thousand project management tools on the market. How many of them are really good? ten? 20? hardly more than 20.
Why were all these terrible monsters with a nightmarish interface created that torment their users, torment their creators and in no way want to part with life for good? Why were these hundreds created as simple rakes for the bodies that do the same thing, differing in the color gamut, platform, and design of the login form? I have no answer. But it is obvious that the world is flooded with software that no one needs, stupidly copied from another software, annoying users with its interface and holding everyone for fools.
One of the first tasks of our industry is to learn how to make the right software. We must fall into the hearts of people the first release.
Do things right
What is the second task? The second task is to do things right .
If we do the right thing, that's half the battle. But if we do it badly, the end goal will not be achieved. Yes, the user will be able to solve their problems, but only quickly, from the fall to the fall of the system.
Poorly written software is strikingly two-faced. He seems to be saying that he is good, and an assistant, but in fact it turns out that he is an old ruin in which the oil mixes with antifreeze in the right mood, the air conditioner only works in winter, the wipers only in good weather, and at a speed of 130 it creaks half shaft But he went through excellent pre-sales training with the help of competent sales managers and quickly went under the hammer. And the fact that the air conditioner does not work, so who includes it in the winter. Yes, and more than 120 on our roads can not go, so this is not a bug.
A few months ago, I tried using the OmmWriter program. Minimalistic interface for writing large amounts of text. Relaxing music. Fullscreen mode that hides everything except text. I liked the program and I started using it.
Once I wrote a great article almost at one go. About 5 pages. Of course, I often saved it. And of course, I did not backup. The next day I came to work, opened the beech and OmmWriter happily hung. I killed the process, launched OmmWriter again and opened the document. He was empty. Have you ever had moments when you thought you forgot to turn off the iron? So I ran a chill down my back, my adrenaline level went up and the feeling of irreparable rose behind my back. With a trembling hand, I found the file in the Finder and checked its size - 0 bytes. That was the last day I used OmmWriter. A program that loses my data loses my trust . I recently bought a very similar program byword. It works like a clock. I am pleased.
Soft, written crookedly, it is extremely difficult to develop and change under the new realities of life. The development of such software is expensive and slow.
At one time, we wrote TargetProcess quickly. Since he wrote after work and on weekends, the main task was to test the idea how viable it is. Unit tests were few. The architecture was weak. For example, the O / R framework was chosen very poorly. Nobody thought about scalability and performance. But the main task was achieved - the concept proved its viability. As a result, everything had to be rewritten from scratch and it took 8 months of full-time work. As a result, appeared TargetProcess 2.0. Was it good or bad? On the one hand, we lost 8 months. On the other hand, they checked the concept and made sure that it works.
Speed
We smoothly go to the third problem - speed.
Software development does not keep up with users. The complexity of the projects increases - the speed drops. The speed factor is becoming more and more important for any company. If we do software quickly, we have the opportunity to try different options, respond to market changes, grope the right way faster than others. If we do software slowly, we will not have a second attempt ...
The industry has appeared its legendary protracted, such as Duke Nukem Forever.
It started in 1996 and was completed in 2011. After several broken deadlines, the developers stopped making public assessments, but simply said that the game would be released “when it’s ready.” Unfortunately, Duke Nukem Forever could not meet the expectations of gamers. Gamespot gave the game a rating of 3.5. The game was boring, unoriginal and outdated.
What a slow country! - said the Queen. - Well, here
you know, you have to run as fast as you can to stay on the same
place! If you want to get to another place, then you need to run at least twice as fast.
In fact, we need to run fast to keep up with others. If we want to be the first, we must run faster, much faster.
Any software development process should focus on these three issues and generally the slogan of any good process is:
Do the right thing right and fast
If we make the right product right, but slowly , we may miss out on the opportunities that exist in the market. We can be late and the reality will change so much that our product will be of little use to anyone.
If we make the right product quickly, but incorrectly , we will encounter problems of product development. Either we will insert props and crutches and bury the product in 10 years, or rewrite it from scratch, which is expensive.
If we make the wrong product correctly and quickly, then obviously it is needed to very few people and there will be no success. Unless we can understand why he is wrong and quickly change in the right direction.
Ideally, we should get to the center.
The future of agile development
Here is the picture of the evolutionary development of agile processes in the near future. By and large, everything can be reduced to two main trends: speed and scale.
We need to learn how to do the right things right and fast on any scale.
This is the foundation.
Why did I take speed as the main entity? By speed, I mean the time to solve a customer’s problem . What happens if we do the wrong thing? We'll have to redo or even abandon the idea. What happens if we do wrong? We'll have to redo to move on. All alterations affect the speed in the most negative way. Therefore, doing the right things right leads directly to an increase in speed in the long run .
Let's start with speed. The speed is determined by two things: expertise and fast feedback.
Feedback
Why is feedback important?
A Swedish psychologist named Anders with the original surname Erickson conducted many learning-related experiments. In particular, he noted that many doctors lose their skills after graduation. However, surgeons are the exception to the rule. Surgeons have constant feedback and clear goals. The oncologists are more complicated. When an oncologist studies the images, he does not know for sure whether the cancer is there or not. He knows this only after a couple of weeks, from the biopsy results. Or even later, after years, when it becomes clear that there is no cancer. Without immediate feedback, the doctor’s abilities deteriorate with time. Erickson proposed a new learning model for old disease histories. You can look at the pictures, make a conclusion and immediately get an answer from a real medical history. In this case, the intensity of training increases by several times, more stories can be considered in one day than in several years of normal practice.
Feedback fundamentally lets you know 2 things. Have we done what we need. Have we done it right. We want to know this as early as possible. Ideally, right after the task. How to find out as early as possible that we are doing the right thing? There are two solutions: sketches and prototypes, fast deliveries.
Sketches solutions
Sketches are a powerful way to clarify requirements. But sketches should not be understood narrowly. A sketch is a quick way to emulate a real system. Sometimes grab a sketch by hand.
And sometimes you need to build a not very simple model.
A few decades ago, IBM decided to create a voice-based computer control interface. A huge number of users dreamed of ordering the operating system, rather than poking a mouse at it. The project was almost launched, but decided to check, and in fact do users like it? The sketch was simple. They brought the user and put him behind the computer. The user enthusiastically gave commands, in another room there was a person who heard and executed these commands. The user saw the process and the result of the command execution on his monitor. Brilliant! As a result, most users did not like to control the computer that way, it was slow and not particularly effective. The keyboard and mouse won, the project was closed. It is easy to imagine what means would be spent on speech recognition algorithms, embedding voice commands into the operating system, and so on. Just a sketch saved a lot of money and helped make the right decision.
Sketching skills development is very important for any software development professional and we often lack this. How is software created now? Requirements gather in one big backlog, important users are selected, and forward to draw UI and write code. At best, a prototype will be made, which at worst will evolve into a real system. This is definitely not enough. In the first stage, the team must make sure that it is going to do the right thing. Yes, this is a business task. But the business is poorly aware of how to make software or design a UI. He can not solve such a difficult task.
Throwing headlong into a new project and starting to do it right away is an almost guaranteed way to release a mediocre product that is not much different from its competitors. If you have only one solution, the behavior of the whole team and the development process are predictable, like a pedestrian.
Bill Buxton, Sketching the User Experience
Currently, there are almost no tools to create fast prototypes of systems. All prototyping tools are flawed and it takes weeks to create prototypes of average complexity. It is very long. In the coming years, tools should appear that allow you to create interactive prototypes in a matter of days . Such a drastic reduction in time will speed up feedback, test several alternative solutions, and make sure that we are going to do the right thing.
Continuous delivery
The second way to speed up feedback is quick deliveries. Delivery after each commit is simply a super-radical idea that cuts feedback to the limit.
For the end user, this is usually of no particular interest. But for the team, such an extreme radically changes the development process, forcing to seriously raise the quality of the code. To provide a CD, a company must seriously push up.
The CD includes almost complete test automation: unit tests, functional tests, performance tests, acceptance tests. The delivery itself must also be automated. This level of automation requires significant effort and often the restructuring of the entire software development process, ranging from the formulation of requirements and ending with the marketing department. That is, the problem of scale is affected, which complicates its implementation.
Expertise
We turn to more human matters. Soft people write. Attempts to put the development of software on the conveyor failed, which is not surprising. The software development industry itself is in childhood and has just celebrated the emergence of secondary sexual characteristics.
People have the expertise and problem solving skills. That is what needs to be developed and improved.
Knowledge of the subject area
Knowledge of the subject area helps to understand whether the right thing we are doing. If you know the device of the car, it is unlikely to agree to add to it the fifth wheel in the center. If you see a car for the first time in your life, nothing will leap up inside you when you add a fifth wheel and you do it mercilessly and mercilessly.
Knowledge of the domain is one of the major failures of all software developers . Of course, everyone somehow penetrates into it, but few people deliberately allocate time to study. When I was working on software in the insurance business, it was only a year later that it occurred to me to read about the device of insurance companies and find out how Carrier differs from Account in real life, and not just at the class level. But if it occurred to me, then none of those with whom I worked next, did not come.
Usually the developer does not care how this or that entity lives in the real world. The set of business rules is important to him. It is important for him to get consistent requirements and implement them. He is important to make a beautiful architecture and write clean code.
Here the initiative lies entirely with the company. It is her task to organize training in the subject area. For example, in our company we send people to conferences and strongly recommend reading books on agile project management, but this is not enough. They must clearly understand what we are doing, why we are doing it and why this is now important .
A team where at least a few people have a decent knowledge of the subject area can discuss its problems with the business and come up with solutions. Confidence in such a team increases many times. The likelihood that the team will not do what is necessary is reduced. This means that development speed increases.
Craftsmanship
Closer to the heart of programmers is the concept of Craftsmanship . The essence of the concept is to improve the quality of decisions and the development of professional skills. Craftsmanship focuses almost entirely on doing things right.
Is it a way to go right.
Uncle bob martin
To improve the quality of solutions, it is necessary to build the right architectures, to have excellent test-coverage, not to complicate decisions without a reason.
For professional development, attempts are being made to apply methods of training athletes or practices of martial arts, such as Coding Dojo and Coding Kata. Of course, this is the big question, is it possible to apply such techniques to train programmers. But in any case, some training is needed. If you work on production code all the time, you can solve the same problems by the same methods and not develop at all. It seems that we really need classes aimed not at creating something concrete, but at honing certain skills. The most effective method may be to solve the same problem in different ways, using a variety of technologies. Continuous improvements to the current architecture are also good. It is necessary all the time to question the current state of affairs and try to improve the decision, make it easier, more flexible, more understandable.
Obviously, increasing the complexity of systems requires a lot from people. Now you can’t just know C, data structures and algorithms. Now you need to know the PLO, patterns, libraries, a bunch of related technologies and disciplines. The amount of knowledge required increases every year. However, the level of programming abstraction over the past few years has not changed much, while the complexity of the systems has changed significantly. The architecture of Facebook or Twitter is extremely complex , I think, no developer out there can imagine how the entire system functions. So the programmer has no right to stop learning.
Problem solving
Perhaps problem solving is the main skill of any person. If there is one, you can easily fill your own gaps and gaps in the development process in the company where you work.
See how a retrospective happens in almost any team. People get together, put forward some problems that often lie on the surface, and offer solutions that also lie on the surface. Root problems are very rarely addressed and resolved. Very rarely, in fact, non-standard, cool solutions are offered. At such meetings, virtually no problem identification tools are used. Systems thinking, TRIZ , brainstorming techniques - most teams ignore all this because they do not have the skills and knowledge. Programmers are not taught systems thinking. Programmers do not learn TRIZ. Programmers are not taught brainstorming. Programmers are not taught to think outside the box .
Problem-solving techniques are not studied either at school, or at the institute, or at the university. This is just incredible! One of the main skills in professional life is not mentioned in any lecture!
Programmers themselves like to learn everything about the strategy and tactics of programming, the rest of the things for most developers are of little interest. Programmers have an algorithmic way to solve problems, but practically do not own a heuristic, creative way. Tasks to improve processes are almost always complex and creative, which cannot be solved with the help of algorithms. Architectural tasks also require creative thinking.
Experienced coaches are trying to bring new practices into retrospectives, but they do not always succeed. Often they themselves are not experts in problem solving, it is often impossible to transfer their knowledge to the team.
Agile hopes for self-organization in teams. So the team itself must identify and solve their problems effectively. Otherwise, it will inevitably step on the same rake. However, no agile methodology contains or promotes problem solving tools.
Interestingly, in the field of design and UX, people use these tools. There it is something trivial, just another set of working tools. Developers often lack this.
An excellent developer must have a creative, innovative thinking. He does not need to be able to write poetry, but to write coherent, good text is necessary. Develop the right hemisphere, gentlemen!
Scale
Scale - a serious test for agile processes. Basically, the problem of scalability concerns the company as a whole and distributed teams.
Company as a whole
Agile works well at the level of individual teams. A single team can really seriously improve its effectiveness by going to Scrum + XP or Kanban. But if you try to develop an idea for the whole company, very often this will meet with serious resistance and misunderstanding.
In the first place, agile conflicts with the corporate culture of many companies. The basic principles of agile, such as transparency, trust, modesty - the world of business meets with bewilderment. Transparency? The trust? Modesty? Hmmm ... Many companies have political games, careerism, boasting and incompetence. For such companies, agile is perceived as a virus that threatens to break the existing system.
Agile seeks to break the traditional company's homeostasis and brings to the surface all the undercurrents, hidden flaws, and everything that does not sink in water under normal conditions.
Even if the company is doing well with transparency and trust, there are still quite complex problems. The HR department should change its approach to hiring people and select those who are suitable not only for skills, but also for the company's culture. The marketing department needs to figure out what to do with frequent releases. The design department must understand how to include themselves in the development team. Top management needs to understand how to organize interaction between many agile teams throughout the company. All this is very difficult and there are no answers to many questions at all. Big companies are just starting reorganization processes with agile account.
Recently, the UX teams and the development team have been actively connected. There is serious progress.
As for the interaction of many teams - everything is much sadder here. Scrum of Scrum has shown its complete inoperability. There are no clear mechanisms yet, everyone steps on the same rake and invents his own bicycle.
Distributed teams
A long-standing agile problem is globalization. The development of the Internet has led to the emergence of distributed teams. There are companies with offices in dozens of countries around the world that have to synchronize the work of hundreds of people. Since agile was born at the level of a co-located team, he initially had serious problems with distributed teams. Continuous communication and feedback cuts are difficult when the product is waking up at 9 am, and the developers sleepily appear at work at 4 pm.
The solution to this problem is complex and, in the first place, should be carried out by increasing the saturation of communication channels. Direct continuous video communication between offices is the best solution. It is always nice to see today's mood on an unshaven face and to know whether a person can now be asked a question, or better wait.
Also, tools for remote programming, brainstorming, and testing are emerging and developing. Tools like TargetProcess are inevitable for any distributed team.
Conclusion
The main task of the software development industry is to get to the center. Learn to do the right thing right and fast.
I am sure it is possible. For this purpose it is necessary (in order of decreasing priority):
- study problem-solving techniques such as TRIZ, develop innovative thinking and systems thinking
- reduce feedback time by all means
- study the subject area
- learn how to scale agile-mindset for the whole company and for distributed teams
PS Yes, I know that the article is big. But I don't see the point in beating her apart.
Source: https://habr.com/ru/post/124241/
All Articles