***
Эту статью подготовил разработчик Neti. Если вы тоже разработчик и хотите делиться опытом, приходите в Neti.
***
Заказчики очень любят каскадную (водопадную) модель управления проектами. В ней всё параллельно и перпендикулярно, и ничто не валяется где попало. Сначала проводим исследование, потом проектирование, потом разработку, тестирование и шаг за шагом через каких-то пару лет получаем красивый желаемый продукт… который на деле оказывается трудно использовать.
В общем, в противовес водопаду часто ставят подход Agile — в переводе буквально «гибкий». Эта методология основана на интегративном подходе по всему стеку задач в условиях командной работы. А цель всего этого — выпуск продукта, оптимально закрывающего все потребности по бизнес-процессам. Гибкость подхода заключается в более быстрой декомпозиции задач, пользовательских историй и упрощённом планировании.
При грамотном подходе удаётся не просто сэкономить время и силы, но и сильнее адаптировать продукт под реальные нужды ключевого пользователя. Да простят нас коллеги, но лучше, если ключевой пользователь будет максимально заинтересован в реализации комфортного продукта для своих задач. А как следствие, — достаточно придирчивым при тестовых запусках.
Допустим, мы делаем частное решение для работы большого производственного склада —систему учёта с помощью QR-кодов.
Наши ключевые пользователи — это работники склада. Основную задачу мы получаем от топ-менеджера — оптимизировать бизнес-процесс таким образом, чтобы он стал максимально выгодным и эффективным по трудозатратам. Но не всегда видение топ-менеджмента совпадает с видением работников на местах. Да, процесс необходимо оптимизировать и включить в общую архитектуру ПО компании, но чтобы программа заработала, ей должно быть комфортно пользоваться.
Возьмем нашу систему учёта по QR-кодам. В этом задействованы несколько групп ключевых пользователей: одни будут в приложении маркировать применения, другие будут пользоваться этой информацией для поиска материалов к выдаче, третьи будут использовать эти данные для прогнозирования закупок и т.д. При разработке системы необходимо учесть все операции, и часто они никак не оформлены в бизнес-процессах. А кое-что вовсе держится на личных качествах отдельных работников.
В интересах менеджмента — убрать этот личностный аспект и начертить бизнес-процесс твёрдым карандашом. Программисты, в целом, с этим обычно согласны, потому что только с прозрачными взаимоотношениями можно создать рабочую программу.
В этом скрыта глубинная альтруистическая сущность Agile-подхода.
Задача разработки — выстроить решение, оптимально решающие все задачи по бизнес-процессу, и обеспечить взаимодействие для этих задач. Водопадная модель не всегда позволяет выявить весь перечень процессов, необходимых ключевому пользователю для внедрения. Agile же позволяет максимально подстроить решение для каждого участника процесса. Для этого нужно множество итераций, что может доставлять неудобства, но в итоге мы получаем решение, комфортное для всех.
Кратко об Agile
Главные сущности и роли:
- Владелец продукта. У него есть запрос, но он вряд ли понимает тонкости разработки. Зато он в идеале может ответить на вопрос, зачем это делать, какие проблемы сервис будет решать и для кого. Но «в идеале» не равно «всегда и точно может». Об этом поговорим ниже.
- Ключевой пользователь. Это человек, который непосредственно будет пользоваться сервисом. Ключевым пользователем может быть клиент компании или сотрудник (если продукт для внутренней архитектуры ПО).
- Пользовательские истории. Это пожелания заинтересованных лиц по функционалу или интерфейсу. Истории можно собирать не только у ключевых пользователей, но и у всех, кто так или иначе соприкасается с этим сервисом. Продукт не должен ломать всю архитектуру ПО данной компании.Идея — это пока не пользовательская история, преобразовать одно в другое помогает бизнес-аналитик или владелец продукта.
- Команда разработки. С ними вы все знакомы.
- Бизнес-процесс. В российской действительности часто его просто нет, поэтому разработке предшествует длинный этап его прорисовки и/или построения. Без него невозможно создать толковый сервис, разве что какой-нибудь совсем небольшой.
Разработка осуществляется спринтами. Вместо того, чтобы на несколько месяцев запереться в кабинете и в конце выкатить продукт, по Agile можно быстро разработать MVP, протестировать, закрыть базовые вопросы, наметить пути решения. И так провернуть несколько раз, пока результат не удовлетворит всех.
На первом же цикле часто раскрывается то, что не было учтено или озвучено в самом начале. Особенно, если вопрос касается пересечений нескольких подразделений.
4 основных ценности Agile:
- Люди и взаимодействие важнее инструментов и процессов. Важная особенность Agile — персонализированный подход к управлению проектами, когда команды ориентируются на постоянное общение как с заказчиком, так и между собой.
- Работающий продукт важнее исчерпывающей документации. Это бывает сложно принять, но если у нас задача, например, быстро обеспечить MVP или устранить баги, стоит придержать бюрократию на время спринтов. Хотя бы потому что продукт может меняться быстрее, чем редактируется документация.
- Сотрудничество с заказчиком важнее согласования условий контракта. Да, юридические вопросы очень важны для сотрудничества, но Agile по умолчанию предполагает высокую ответственность всех участников, а в этом случае контракт отходит на второй план. Этот пункт — прямой наследник предыдущего.
- Готовность к изменениям важнее следования первоначальному плану. Гибкость на то и гибкость, чтобы быть готовым перечеркнуть собственные наработки, если вопрос зашёл в тупик.
Где нужен и где не нужен Agile
Классическое применение Agile — в решении коротких задач. Когда мы имеем конкретный запрос от бизнеса — его проще решить на спринте, чем включать в годовое планирование. Причём часто одна задача от заказчика преобразуется в 3-5 более мелких, с которыми уже работает команда.
Очень часто Agile необходим для прояснения и анализа ситуации, а не для разработки. Особенно, когда заказчик не может окончательно сформулировать бизнес-процесс и свои пожелания для разработчиков. В этом случае можно проверять гипотезы, пока не найдётся оптимум.
Обычно весь проект строится на Agile, если речь идёт о быстрых решениях — до 2 месяцев на всё. Тут просто нельзя успеть сделать полноценный анализ и предложить одно верное решение. Кстати, длительность оптимального спринта совсем небольшая — неделя-полторы, иногда две. Дело в том, что так проще сохранять фокус всех заинтересованных сторон — заказчика, пользователей и разработчиков.
А вот, где такая система может привести к ошибкам:
- Там, где речь идёт о функциях, с которыми заказчик раньше не работал.
- Там, где требуется планирование сложных архитектурных решений.
- Там, где ключевой пользователь в корне не согласен с тем, как задачу видит начальство.
В этих случаях уместно использовать водопадный метод. Впрочем, внутри него иногда можно устраивать спринты для проработки отдельных задач — так обычно и делают в Neti. Так что, отвечая на вопрос из заголовка, Agile и Waterfall — скорее союзники, просто подходят для разных условий и могут дополнять друг друга.
Успешный Agile. Советы для новичков
- Заинтересованность в реализации проекта, мотивация создать классный рабочий продукт — это одно из главных условий. Спринт предполагает быструю реакцию, креативность и пытливость ума. Разработчик становится немного аналитиком, чтобы выявить неявные знания и использовать их в создании сервиса.
- Для Agile предполагается наличие стандартного набора профнавыков. Надо понимать, что любой процесс разработки на 90% состоит из нудной подготовительной работы.
- Альтруизм. Это важная черта в работе программистов, хоть на неё редко делают акцент. Большинство пользователей наших программ — это всё ещё люди, поэтому важно взвешивать интересы заказчика выше, чем затраты на разработку.
Что почитать по теме:
- Майк Кон, Agile: Оценка и планирование проектов
- Стивен Денинг, Эпоха Agile
- Карл Сьюэлл и Пол Браун, Клиенты на всю жизнь