Что касается аспекта кода программной разработки,
методология Agile всегда сводится к тем же понятиям и процедурам (ежедневные
планерки, разработка через тестирование/реализацию поведения, обзор кода/парное
программирование, истории, ревью и т.д.). А вот требования крайне изменчивы.
Полученная рекомендация и степень ее соответствия корпоративным правилам и
стилю работы очень непостоянны.
Тем не менее, я нашел три повторяющиеся стиля, где
требования неразрывно связаны с разработкой: итеративный, инкрементальный и
эволюционный.
Итеративный
Команда разработчиков выполняет множество полезных практик:
ежедневные встречи, совещания по планированию, короткие итерации или поток
Kanban, разработка через тестирование, обзор кода, рефакторинг, непрерывная
интеграция и т.д. Наверное, точнее было бы сказать "Надеюсь,
выполняют", потому что часто некоторые из данных пунктов игнорируются. Но
здесь это не имеет значения.
Все требования содержатся в специальном документе. Что
интересно, остальная часть организации продолжает работать как будто ничего не
изменилось (на самом деле, это может быть желание компании). Нередко можно
услышать фразы "Agile -- механизм поставки" и "Agile для
разработчиков".
Документ с требованиями может быть написан консультантом или
аналитиком, больше не работающим в компании. Он переходит другому аналитику или
руководителю проекта, который за установленный период времени и в рамках
определенного бюджета должен поставить все элементы/свойства. Поставка, как
правило, является "громким событием" в конце проекта (когда команду,
возможно, уже распустили).
Для этого им нужна техника "салями".
Задача владельца продукта -- разбить требования на небольшие порции для
выполнения в каждой итерации.
Команда разработчиков изолирована от остальной части
организации. Существует комиссия по рассмотрению изменений и любое расширение
масштаба проекта воспринимается как проблема.
Итеративный стиль подходит крупным корпорациям, компаниям с
годовым бюджетом, старшим менеджерам, которые не смыслят в ИТ и, особенно,
банкам.
Инкрементальный
Данный стиль напоминает итеративный. Команда по-прежнему
выполняет действенные практики и итерации. Есть огромный документ с требованиями,
используется техника "салями".
Однако, согласно этой модели, команда поставляет ПО
клиентам. Как минимум, участники демонстрируют ПО и выслушивают отзывы. Скорее
всего, они развертывают ПО и (потенциальные) пользователи могут использовать
его в тот же день.
В результате, клиент/пользователи предоставляют обратную
связь со своими пожеланиями по проекту. Иногда это может быть дополнительное
свойство и функции (расползание границ проекта!) или устранение прежде
требуемых (отступление от границ проекта!). Проект все еще выполняется в
традиционном понимании, но задачи не обозначают как выполненные, а вычеркивают.
Я назвал данный стиль инкрементальным, поскольку
клиенты/пользователи/участники проекта наблюдают за поэтапным развитием
продукта.
Собственно говоря, я полагаю, что это самый распространенный
метод программной разработки. Все же, в отдельных средах он считается
неправильным, потому что предварительные требования "ошибочны" ,
требуются многочисленные поставки или команда не выполнила всех начальных
требований.
Эволюционный
Опять-таки, команда разработчиков выполняет итерации.
Однако, на этот раз документа с требованиями нет. Работа началась с идеи. В
идеале, стоит сформулировать цель, которая будет служить ориентиром -- и эту
цель стоит изложить в одном предложении, максимум -- абзаце. Хотя иногда о ней
забывают.
Группа по рассмотрению требований и разработчики коллективно
обсуждают идеи и определяют задания. В то время, как представитель первой
излагает клиентам и участникам проекта суть проблемы и какие шаги необходимо предпринять,
техническая команда (может, лишь один человек) берется за лучшую на тот момент
идею.
Через некоторое время (2 недели максимум) они снова
встречаются. Представитель группы по рассмотрению требований рассказывает, что
узнал, а разработчики показывают, какую работу сделали. Затем они решают, что
делать дальше.
После, все возвращаются к своей части задания. Как только
появляется возможность, команда поставляет ПО пользователям и клиентам. Таким
образом, они поставляют функционал и обеспечивают обратную связь.
Эволюционный стиль очень эффективен для стартапов. На самом
деле, он довольно распространен, но чаще называется сопровождением или
исправлением ошибок.
Комментариев нет:
Отправить комментарий