Agile analysis. Myths and Reality

I Introduction

The booth must be transferred! Season does not happen, so that a couple of not shandarahnulo.
That confused with the toilet, then with a beach cabin ...
(x / f Features of national fishing)

The end of the year, summing up, filling out forms and other pre-holiday tinsel of IT functionaries. I already once again catch the eye of the final questionnaires of IT firms, designed to identify trends in approaches to product development. And every time there is a feeling of some kind of trick when you answer questions like: “You still use the Waterfall method (waterfall model), or you still (like all advanced humanity) practice Agile (flexible methodologies)”. When you start to find out from the author of this survey, and what he understands under Agile, his explanations somehow do not fall much into the outline of the manifesto (Agile Manifesto). He really thinks about many principles for the first time, and these very principles downright stump him. But after a little confusion, heavy artillery is used with reinforced concrete substantiation of its position: “We are not working on the Falls, it means according to Agile”.

The very thesis “Flexible methodologies” is so gutta-percha still in its sound that many try to squeeze anything into it, or rather what is most beneficial for them. Gradually, it became a fashionable screen, which can cover all its shortcomings and even sloppiness, in the process of manufacturing IT products, and at the same time, as it were, stay on the crest of a wave, in a trend. They say we are not - and the technique is.

Let's together, once again “strike with analysis” on the topic of Flexible methodologies, try to spread out the main artifacts and principles on the shelves and separate the sacred meaning that was originally included in this concept from what it was converted into by some careless populists. We also compare the approaches of Agile with other methods for a more accurate understanding of the face that separates them, or vice versa - combines. At the same time, we’ll try to figure out where the use of Agile principles is most appropriate, and where it’s not entirely appropriate?

II Background to the emergence of software development techniques

History is like meat pate: it is better not to peer how it is cooked.
Aldous Huxley

For the sake of objectivity, let’s dive into the history and feel the circumstances that formed the ground on which various principles and methods of developing software products, including Flexible, have grown.

1. Myths and reality about Waterfall

As already mentioned in the introduction, antagonism (sacrificial offering) for Agile (1) was chosen Waterfall technique, which in its pure form was relevant in the last century, during punched cards and tape drives and presented to the world for the first time in the article by W. W. Royce ( WW Royce), published in 1970.

Such a comparison undoubtedly helps any other methodology to look fresh and innovative in comparison with it. For the sake of persuasiveness, some speakers represent the Waterfall model not as an iterative, but as a one-time, monolithic flow of work that passes through the phase: requirements analysis, design, implementation, testing, integration and support. I was especially touched by the phrase about the development methods that was peeped in the article, before the Ajail period: “Before, products were made entirely at once. To do this, went through the chain: the idea → technical task → design → programming → testing → release ". Excuse me, but Royce used the iterative development model in his approach. So cynically simplifying an idea is simply not ethical, especially considering that there was not a vacuum between Waterfall and Agile, but a rather long evolutionary chain still existed.

Although in fairness, one must admit that most of what has been said about Waterfall is generally not far from the truth. If the team was aware at some stage that the result did not meet the expectations, then either “finished off” to the logical end not quite a suitable product, or threw most of the work into the basket, and started the process almost from the very beginning, actually creating a new product. Why, despite some absurdity by today's standards of such an approach, has the technique for a long time remained a popular flagship in the software development world?

To comprehend this phenomenon, we immerse ourselves in the atmosphere of the then Computing Centers (EC). Let me remind you that in those far, distant times, the path from the developers' idea to the execution of its computer was long and thorny. He ran through the already forgotten data preparation devices that perform mechanical punching of punched cards and affectionately called “barmalia”. This operation was carried out not by the developers themselves, but by specially trained people. Having received the cherished stack of holed cartons, in turn, taking into account the efficiency of the computer, these punched cards were laid in a special device (again, specially trained people), which read the code and only after that, he had a chance to be executed by the processor. But if one of the punched cards in the deck jams when reading, you should repeat the procedure for reading the entire deck again. And God forbid, there was an error in the code, it was necessary to re-resort to the help of the bogeyman, to kill part of the punched cards and, without mixing them up in places in the deck, to repeat the whole procedure once more. Such delights work of the then programmers was littered all over. Naturally, the rapid changes in the requirements for the product being developed in the course of its implementation, with such an approach could be. Qualitative requirements for the product being developed and the strictly regulated process of its production were for the then-teams All.

2. What if not Waterfall?

But time passed and everything changed. The personal computer gradually replaced the huge tumbling monsters as a capsule for the digital world. The number of operations performed by processors per unit of time has increased by several orders of magnitude, and the speed of an information I / O operation began to seem simply "cosmic." Programmers got direct and instant access to the execution of the code just typed - by computing resources, on the spot. Now to make changes to the work of the software has become much easier, and already to imagine that someone else continues to work on the method of Waterfall in its pure form is simply ridiculous.

Natural selection and the need to adapt, made the methods mutate. Moreover, most of them borrowed from their predecessors an iterative model of development. Just execution cycles have been significantly reduced and improved.

But then another attack arose. Unprecedented opportunities allowed from the automation of individual production areas to move to automate entire enterprises, and even to wipe the full extent on the industry. With such volumes of operations and the amount of resources involved, it was simply impossible to simplify the methods of developing software products. On the contrary, they have become even more sweeping and formalized.

The Rational Unified Process (RUP) has become one of the most well-known methods using the iterative development model. It was developed and implemented in the second half of the 1990s by Rational Software.

The term RUP is not only a software development methodology, but also a set of tools for managing development processes. Within the framework of the topic under consideration, it is especially interesting to note that the RUP (2) methodology describes an abstract overall process, on the basis of which an organization or project team can create its own unique software development process that is focused on its own needs. What say this approach is not flexible?

In further analysis and comparisons, it can be noted that some of the key features of RUP are also partially inherited from the Waterfall technique.

1. Cyclic software production approach . The life cycle of the RUP project is divided into 4 phases and 9 workflows.
2. Iterative development process . The RUP project consists of a sequence of iterations with a recommended duration of 2 to 6 weeks.
3. Mandatory requirements development . To describe requirements in RUP, use cases or use cases are used. Each use case is a description of the scenario of user interaction with the system, fully performing a specific user task.
4. Incremental approach aimed at incremental increase in product functionality. The basic unit of planning iterations is the use case, which allows you to make the necessary changes to requirements, design decisions and implementation during the project.

Pay special attention to the last point. It argues that it is precisely the presence of detailed requirements, drawn up in a certain form, just provide the opportunity to effectively make changes to the design decisions and implementation of the product during the project. Including in the late stages of the project.

Often, RUP is mistakenly considered a heavy process with a high level of formalism. But this is not entirely true, since the RUP process can (and should) be customized to the specifics of a particular organization and project. Even if the team takes on a small software product that will need to be refined, scaled, or integrated with other systems, then RUP will quite comfortably cope with all the emerging challenges.

3. The overthrow of the foundations

And further more. Having skipped the period of coming to our world of personal computers, let us proceed to the emergence of all sorts of instrumental studios, visualization and modeling tools, automated application builders, etc. In all this variety of helpers, allowing, for example, dragging an element on a diagram with a mouse, and getting automatically changed application code for the final product, began to depreciate the very role of software development techniques. With such advanced tools, with a lack of time or resources, you can abandon some of the workflow methods of the methodology and at the same time virtually nothing to lose. At least in the short term. These freedoms and, as impunity turned out, with due professionalism of the performers, led the most desperate heads to the proclamation of the new IT trend - “Flexible development methodologies”.

Here in this place from the red line, let me stress once again a very important thesis, perhaps the key one - “with due professionalism”! That is, high-class specialists, who have dozens of large realized projects behind them, who are able to sketch a class diagram of a small module in their head for 20 minutes, immediately estimate the processes changing their states, assume critical dependencies, etc. decided that they could, in some cases, do without the mandatory passage of the adopted regulations. At the same time, the project will nevertheless be brought to the expected result with an acceptable quality in a much shorter time frame. Is it bad or good? At first glance, just wonderful. On the second, not everything is so simple. Let us analyze the pros and cons a little later.

Definitely bad here is different. Young and insolent, looking at it from the outside, ask themselves the question: “And what could have been so?”. They have never seen quality requirements in their eyes, they cannot read diagrams, but now they don’t need it. Everything! requirements are now canceled! Diagrams, the process of modeling - there in the furnace. Only code, code and chat. As a bonus - they can leave their comments in the code, for future generations of the same bold.

At this, the historical excursion can be completed and go closer to the body so to speak ...

III Analysis of the phenomenon of flexible methodologies

Every entity should be analyzed in terms of logic, before poking into the mouth.
Woody Allen.

1. Definitions of Flexible Methodologies

Since Ajaila has been around for many years, let's use the available information and first, let's review the definitions and opinions that head the top in the network. And having already pushed off from them, let's move on to the main artifact - the Manifest of flexible software development.

The first thing that was found in a search engine for the term Agile:

Agile software development agile methods (agile methods) - a series of software development approaches focused on the use of iterative development, dynamically forming requirements and ensuring their implementation as a result of constant interaction within self-organizing working groups consisting of specialists in various fields.

The following important points can be distinguished from this definition:

1. Using an iterative approach . There is nothing new about software development methods that deny this principle, I personally have not heard;
2. Formation of requirements is carried out in stages, in the course of product development . This is a key difference from many other methods. In some ways it gives an advantage, in some it introduces fundamental limitations. We will discuss this and that later;
3. The use of continuous close interaction of all team members , including the customer. In most other methodologies, of course, attention is paid to teamwork, including with customers, but positioning this communication as an additional project resource, giving an undoubted advantage, is rather exclusive;
4. Team self-organization . It is assumed that each iteration ends with a debriefing (retrospective) and the introduction of constructive changes in the process, which contributes to the continuous development of the team. Such techniques are most likely borrowed from earlier techniques. For example, it is practicing RUP.

In principle, not much has been found out from this description, so let’s move on to the clarifications:

Most of the flexible methodologies are aimed at minimizing risks by reducing development to a series of short cycles, called iterations, that usually last two to three weeks. Each iteration in itself looks like a software project in miniature and includes all the tasks necessary for issuing a mini-gain in functionality: planning, requirements analysis, design, programming, testing and documentation.

But we have already considered this approach in the good old RUP. That is, there is also nothing fundamentally new here.

Most of the definitions I have found are also abstract and non-specific, very little information allows you to immediately take up and begin to use flexibility. But here another no less important side of the approach opens, bringing clarity to that superficiality, which shows the entire topic under consideration. For example:

Agile does not include practices, but defines the values ​​and principles that guide the teams. Agile is a family of development processes, not the only approach in software development, and is defined by Agile Manifesto.

Adjail is a way of thinking with its own value system. It is similar to philosophy, religion, or culture — the same set of attitudes that a person believes in and that influences his behavior.

Apparently for this very reason, there are countless disputes around Flexible Methodologies. Not so much in the very idea of ​​what you can really touch. Apparently for the same reason, it is possible to call something of your own (almost any), unconventional - flexible methodologies and not be found to be unprofessional. In my opinion, this is acceptable, if you want to be in trend - call your development approach as fashionably as you like, if only the development process and the final product itself do not suffer.

I recall a case from my own practice, when a large IT company decided to improve its technological processes before a large-scale project. To this end (as recommended), a specialist in flexible methodologies was invited, on whose shoulders this responsible mission was assigned. After reading a very short lecture on the way of thinking and the Ajayl system of values, he began to find out what the actual situation with the production of software in the enterprise was. Finding flaws and inconsistencies in existing processes, together with the team of the enterprise, selected the most appropriate ways and methods to solve them. Fortunately, these shortcomings were no secret to anyone, but a number of reasons interfered with their overcoming. For example: lack of time, contradictions between teams subordinate to different management verticals, fear of taking responsibility, etc. Since all this event was patronized by the top management of the company, and the invited specialist was a truly high-class IT professional, the innovations developed were brought to life, almost on time and with a very sensitive, positive effect. But they had nothing to do with the Manifesto of flexible methodologies. As a result, most of the company's employees remained confident that now they completely switched to Adjail, abandoned everything else. All this is very reminiscent of a fairy tale about how a soldier cooked porridge from an ax, cunningly drawing out from the owners the ingredients he needed and improving the taste of the dish. That's just the ax is not boiled down.

But since we are here gathered in order to impartially analyze the Agile phenomenon, we will therefore continue our research. Let us turn to the original source - Manifesto Ajail:

2. Let's analyze the main ideas of Agile Manifesto

Key ideas:

1. People and interaction are more important than processes and tools;
2. A working product is more important than comprehensive documentation;
3. Cooperation with the customer is more important than negotiating the terms of the contract;
4. Readiness for change is more important than following the original plan.

Let's start with a fly in the ointment. For me personally, all points are controversial. Let's go in order:

Item 1 . In my opinion, one of the key reasons for the emergence of Ajail, as I wrote above, was the rapid development of systems for automating software development processes that made it possible to neglect the regulations. That is, it is just the displacement of monotonous human labor by robotic processes and allows to produce more reliable and predictable results, including to maintain the qualitative interaction of the processes themselves. Therefore, about “People - most important of all,” in my opinion, this is just a slogan helping to amuse the human pride of the most sentimental team members.

But in fairness, I note that these young slogans, clapping their hands in retrospect and other sentiments, are quite effective and even (at first) raise the team spirit. It is important that the emptiness and disappointment does not come when the understanding of the holiday leaves.

Item 2 . Development is only a short moment in the life of an automated system, and then begins the harsh everyday life of its operation, modernization and expansion of opportunities. Have you ever tried to maintain a good software product, completely devoid of documentation? What is happening in it and why it is this way, and most importantly, how can it be corrected so that it starts working a little differently? And if it interacts with other software, then what can be changed in it at all, and what cannot be touched? All this is reminiscent of walking on a minefield.

And here we add the principle of phased development. Without documentation, it will still be necessary to determine at what stage of development the product is in general.

But for the sake of objectivity, it should be noted that when the team delivers the finished product to the customer, assembled from a heap of modules, installed on a heap of various equipment, and also under the “non-child” load, then it is highly likely that it will be necessary to modify or change the code. Sometimes the changes can be numerous and profound. And here it is definitely not up to the formalism, it is necessary to save the face of the team. During this period, you can postpone documentation until better times and rush to edit the code. I want to note that it is much more comfortable to do when there is decent documentation at hand that was compiled at the development stage, with a description of how everything worked at the time of the introduction.

Item 3 . Well, for starters, the point itself is not clear the opposition itself. Is not agreement negotiation a collaboration with a customer? If the customer, as a result of clarifying the terms of the contract with the development team, will be able to understand the scope of work, approximately realize the cost of their implementation, and most importantly, imagine the result that he can get in some tangible real-world indicators (automated business functions, form layouts, etc. .). After all, it will be easier for him to make a decision: does he need this particular product, is he ready to finance its production, etc. Isn't that a collaboration?

And what about cooperation then? Just warm conversations for life without any commitment? How not cool, if the project is commercial, all parties first need to achieve their goals in the project. And the terms of the contract - just fix these very goals and how to achieve them. At the time of working out and agreeing on a contract, both parties begin to realize that it is from them that the partners are expected to receive and the degree of responsibility in the event that the agreed result is not achieved. The contract in this case is a motivator and a means of settling differences, for those and others. After all, it is not extremes that are most terrible, but uncertainty.

There is no contract - there is no responsibility, there is no complete understanding of what should result from the completion of the project. This approach suits you - good luck.

Point 4. We have already said above that, given the availability of modern software design and development tools, there is no particular difficulty for a team of professional developers to make changes to the implementation of a product at almost any stage. This is a normal process, depending to a greater degree on the team’s depth of understanding of the product they are developing. Therefore, in this case, the question is not so much about the readiness of the team to make changes, but about who will pay for all these excesses. It is here that the qualitatively drafted contract, which determines who and in what cases incurs material losses from the reformation, comes to the fore. Whether the developers rework at their own expense, what they misunderstood or the customer, who did not correctly explain what he needed.

3. Discuss the principles of Agile Manifesto

Since we want to understand the topic in an unbiased way, let us at least briefly touch on the principles explained by Agile Manifesto:

• customer satisfaction with the early and uninterrupted supply of valuable software;
• welcome changes in requirements even at the end of development (this can increase the competitiveness of the product received);
• frequent delivery of working software (every month or week or more often);
• close, daily customer communication with developers throughout the project;
• the project deals with motivated individuals who are provided with the right working conditions, support and trust;
• The recommended method of transmitting information is face-to-face conversation;
• working software is the best measure of progress;
• спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
• постоянное внимание улучшению технического мастерства и удобному дизайну;
• простота — искусство не делать лишней работы;
• лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
• постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Большая часть из перечисленного не противоречит другим методикам и является весьма целесообразной.

Но не всегда этими принципами можно реально воспользоваться на практике. Например, заказчик далеко не всегда может сотрудничать с командой при обсуждении решений. У него зачастую банально нет времени, а иногда и особого желания. Тогда нужен профи – аналитик, способный в сжатые строки, ненавязчиво, втершись в доверие и используя всякие свои психологические “штучки”, вытянуть из него полезную информацию и уже причесав ее гладко, гладко, донести до коллектива разработчиков в форме максимально пригодной для реализации. Вот интересно если такое происходит работа команды перестает считаться гибкой?

По этой же причине не всегда удается организовать частые поставки. А еще на это процесс может серьезно влиять некоторое количество интегрируемых модулей, разрабатываемых разными командами, собрать которые (модули) в одно время, на одном оборудовании бывает весьма проблематично. Да и специфическое оборудование, бывает так, что поставляется уже непосредственно ближе к сдаче. Это тоже необходимо учитывать.

А еще чувствуется диссонанс в утверждение, про «лучшие технические требования, дизайн и архитектуру» при том, что принципы Agile, в принципе не приветствуют документирование и все такое прочее. Если вы “обижаете” формальный подход к документации, то вряд ли она получится лучшей (народная мудрость).

Так же, с моей точки зрения, вызывает нарекание — возведение в ранг лучшего метода передачи информации — «личный разговором (лицом к лицу)». На мой взгляд, передавать информацию в проекте гораздо эффективнее, например, при помощи трекера задач или вики-системы, не исключая конечно и личное общение.

IV Применение гибких методологий

В новаторстве вы должны быть одновременно упрямыми и гибкими.
Если вы не упрямый, вы будете отказываться от экспериментов слишком рано.
Если вы не гибкий, вы будете биться головой о стену, и вы не увидите другое решение проблемы, которую вы пытаетесь решить.
Джеффри Престон.

Если во время рассмотрения возникло столько критических оценок, как же это все работает?
Успеху Agile, видимо способствует эффективность использования методики в небольших проектах и общность (одновременность) употребления всех перечисленных выше пунктов.

1. Преимущества, предоставляемые использованием Agile

За счет использования Пользовательских историй команде разработчиков удается достичь нужного уровня понимания в обсуждениях с заказчиком. Для заказчика понижается порог вхождения в тему, ему проще оперировать с контентом проекта, выставляя приоритеты, подправляя неточности и т.п. Более того, даже менеджеры проекта, продукта и прочие управленцы команды, с напрягом разбирающиеся в спецификациях требований, на основании простых Пользовательских историй, получают возможность гораздо проще жонглировать в проекте задачами и понимать ожидания клиента.

За счет же частых поставок прототипов, удается избежать больших расхождений между ожиданиями заказчика и вариантами, предлагаемыми исполнителями решений. С каждым новым релизом, все больше сближая их друг с другом. Просадки во времени исполнения и соответственно финансовые потери так же не велики и прогнозируемы, их можно заложить сразу в план проекта.

Выглядит это примерно так: Заказчик ожидает получить некий новый функционал, возможности которого он сам не до конца представляет. Происходит “тесное сотрудничество”, в результате коего исполнитель предлагает пилотное решение, как правило не совсем удовлетворяющее ожиданиям заказчика, о чем тот и извещает команду. Этот эпизод побуждает к новому “тесному сотрудничеству”, в результате которого исполнитель вносит коррективы в прототип и снова презентует продукт заказчику. И так по кругу до полной победы определенного функционала над разумом заказчика, или до того момента, как в сотрудничестве станет настолько “тесно”, что оставаться в нем будет уже не комфортно. Если сложность продукта и количество автоматизируемых функций позволяет выполнить 3-6 таких циклов для полного и безоговорочного счастья заказчика, то почему бы и нет, вполне работоспособный схема.

Единственно, хочу акцентировать внимание на принципиальном моменте, который часто остается без должного внимания – необходимость фиксации в документах (хотя бы постфактум), технического решения которого удалось достичь в результате проб и ошибок. Это важно, как заказчику, который может в дальнейшем для доработки или масштабирования продукта нанять новую команду, так и для самой команды, которая во-первых, сможет тиражировать решение или его части, а во-вторых, при повторном привлечении для модернизации продукта, сможет быстрее и качественнее влиться в процесс.

2. Небольшие проекты – комфортная среда для Agile

Для небольших проектов использование Пользовательских историй, вместо полноценных требований к разрабатываемому продукту, позволяет упростить и сделать более комфортным общение с заказчиком. За счет частого взаимодействия с клиентом и простоты формы общения, команда не мытьем, так катанием вырабатывает приемлемые требования к функциональности продукта. При отсутствии сложных алгоритмов и интеграции с другим ПО, это может происходить без особых потерь. Уровень домена проблем – закрывают Пользовательские истории, а домен решений – комментарии в коде.

Используя команду профессионалов, можно не заморачиваться на проработку архитектуры решения и спецификаций требований к продукту. Наверняка нечто подобное команда или ее члены уже решали и у них есть за плечами подходящие шаблоны и наработки.

Если этот продукт разовый и его не планируется развивать, то этого вполне достаточно.

3. Как можно использовать Agile в средних проектах

Использование в средних проектах Agile, тоже может быть весьма эффективным.

В более масштабных проектах могут использоваться разнообразные платформы автоматизации, снабженные готовыми шаблонами, наработками, средствам самодокументирования и т.п. Это значительно упрощает формальные процессы, включая проектирование, моделирование и документирование. Решения, представленные в подобных случаях чаще всего тиражируемы, с ограниченным количеством доработок и изменений.

Наибольший эффект можно получить, если предыдущие подобные решения документированы. Оттолкнувшись от этого базиса, можно уделить больше времени не проектированию и моделированию, а подбору, совместно с заказчиком нужного прототипа. «Примерьте это, наденьте –это и пройдитесь. Не жмет?». Важно, чтобы новые, внедренные решения, были также хорошо задокументированы. В этом случае, команда получает набор кубиков и инструкций по сборке из них различных моделей, которые можно предложить на выбор будущим клиентам.

В данной модели работы, важно понимать, что Agile не отрицает важность процесса документирования, она просто позволяет отсрочить его формирование, отдавая приоритет построению самого продукта (если это возможно в текущей ситуации). Документация может формироваться уже после получения устойчивого продукта, закрепляя достигнутые результаты и, как было отмечено выше, помогая не потерять в дальнейшем нить понимания правил функционирования системы.

4. Как эффективно использовать Agile в больших интеграционных проектах

В больших и сложных проектах, в которых ведется качественная документация, есть архитектурное представление о продукте и процессе его производства, “куски” продукта могут раздаваться на аутсорсинг небольшим командам. Эта передача происходит после детальной проработки общей архитектуры и составления высокоуровневых требований к новым подсистемам. И вот уже эти относительно небольшие части могут вполне эффективно реализовываться с применением Agile.

Это же схема применима для небольших доработок или постепенного развития большой сложной системы, особенно если требуется провести какие-то исследовательские работы.

Еще один вариант использования Agile в больших проектах, может быть эффективно применен, при авральной сдаче продукта заказчику. В виду критической нехватки времени и ресурсов для его доработки и исправления, помочь предотвращению фиаско, может именно гибкость в подходе. В подобных ситуациях, на мой взгляд, именно эта методология является оптимальной.

В данном разделе стоит упомянуть и о существующих методиках, основанных на Agile, но тяготеющих к решению масштабных задач.

Гибкий унифицированный процесс (AUP, англ. Agile Unified Process) — упрощенная версия унифицированного процесса Unified Process (UP), разработанная Скоттом Эмблером. Данная методология разработки программного обеспечения соединяет в себе элементы гибких методологий и унифицированного процесса. В частности, AUP предполагает разработку через тестирование (TDD), применение гибкого моделирования (англ. Agile modeling) и рефакторинга баз данных, гибкое управление изменениями.

OpenUP — это итеративно-инкрементальный метод разработки программного обеспечения. Позиционируется как лёгкий и гибкий вариант RUP. OpenUP делит жизненный цикл проекта на четыре фазы: начальная фаза, фазы уточнения, конструирования и передачи. Жизненный цикл проекта обеспечивает предоставление заинтересованным лицам и членам коллектива точек ознакомления и принятия решений на протяжении всего проекта. Это позволяет эффективно контролировать ситуацию и вовремя принимать решения о приемлемости результатов. План проекта определяет жизненный цикл, а конечным результатом является окончательное приложение.

5. Как не надо использовать Agile

Не менее важный раздел, возможно ради которого и затевался весь анализ.

1. Лидером в моем антирейтинге является ситуация, когда Agile, а вернее некоторые ее принципы, пытаются использовать не для достижения каких-то конкретных целей, которые они позволяют обеспечить, а просто #ПОТОМУШТО. Потому, что это тренд, это у всех на устах. Например, кто-то поделился на ИТ тусовке положительными отзывами, немного эфемерными и даже заносчивыми, но пошла молва, появился антураж. И вот уже назвавшиеся последователями Agile, ощущают в общении с остальными — принадлежность к некому элитарному клубу. Всему этому способствует кажущаяся простота методологии и туманные очертания ее границ. Внедрения по такому принципу происходит бездумно и формально. Люди, формально и беспринципно внедряют принципы, призванные снизить формализм.
   
   Вот например, один из совсем свежих случаев. В одной фирме проводя Ретроспективы, запретили их посещение тимлидами. Вот такая фишка. Suddenly. Первая мысль: ну может быть они и правы, чтобы типа не было давления авторитетов на коллектив при обсуждении проблем и т.п. Но тимлиды обижаются, они в недоумении и хотят разобраться. Я попытался переубедить, что мол может так то оно и лучше, главное, чтобы Вам по итогу выдали список пожеланий, с перечнем, что надо менять, что улучшать и т.п. И вот тут-то и открылась страшная тайна. А ни каких итогов и пожеланий к улучшению процессов в результате этих посиделок не возникает. Господа ИТ_шники, а зачем же тогда такая ретроспектива? Просто похвалить друг друга и поднять командный дух? Сказали А, говорите и Б. Ведь основная цель этого процесса методологии и заключается в том, что: «Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы».
2. Вторая в моем рейтинге ситуация, когда команды решают сэкономить на подготовке требований в проектах со сложными поведенческими или логическими алгоритмами. То есть, когда пользовательская история является лишь небольшой вершиной айсберга проблемы, а его основная часть не видна и для реализации требует детального, тщательного анализа и проектирования . Что при этом происходит?
   
   Перед началом работ ни заказчик ни разработчики даже приблизительно не понимаю, тот объем работ, который им необходимо проделать. А соответственно: либо заказчик будет платить, платить и платить, каждый раз, когда ему будут растолковывать, что все оказалось горазда сложнее и теперь еще конца и края работам не видно. И ведь бросить будет жалко и постепенно начнет гложить суровое понимание, что этот «золотой» продукт уже никогда не окупится. Либо разработчики, подрядившись выполнить работы за определенную сумму/время, будут за свой счет (бесплатно) доделывать и переделывать продукт, пока у заказчика не иссякнет фантазия, или он не сжалится над жертвами гибкого подхода.
3. Почетное третье место занимает ситуация, когда в большом многофункциональном проекте (а вдруг еще и интеграционном) команда решает сэкономить на проработке архитектуры решения и начинает короткими итерациями реализовывать отдельные пользовательские истории. С большой долей вероятности случится так, что через 3-5 итераций, при попытке создать новый функционал, окажется, что надо переделывать весь предыдущий, так как не учли фундаментальные принципы, на которых этот функционал должен был базироваться. Еще хуже, если уже после 10_ой итерации обнаружится, что выбранные технологии не позволяют удовлетворить все потребности заказчика и надо начинать все сначала. Возможно, поменяв команду.
4. Не попала в тройку ситуация, в которой резкий и неимоверно гибкий стратап врывается на просторы вялого сегмента рынка. Стартап, он на то и стратап, что в нем нет ни каких устоев, скрепов, привязанностей, а вместе с тем устойчивости и стабильности. А проще говоря, нет почти никакой документации, коллектив не слажен и часто меняется. Рынок буквально рвет команду, требуя все новых и новых решений в застолбленной области, а все последующие проекты просто разваливаются на глазах. Чаще всего, все объясняется тем, что в команде нет понимания процессов промышленного производства ПО , организации поставки и поддержки продукта.

Let's sum up

Готовя эту статью, я попытался помочь командам, интересующимся подходом Agile, высветить и формализовать вызовы, с которыми они так или иначе должны сталкиваться, а так же подобрать возможные решения для их преодоления. Я постарался рассмотреть тему максимально толерантно, как для апологетов внедрения одной или нескольких методологий из этой группы, так и для противников, желающим развенчать ореол гибкости и мотивировано отказаться от ее использования.

Надеюсь, что анализ поможет и командам, использующим другие методологии, в случае необходимости применить преимущества подхода Agile.