Или Как похоронить безумного менеджера при помощи лопаты без черенка
Что такое Agile
Считается, что принципы Agile (пер. с анг. быстрый, подвижный) так или иначе применялись всегда, но официально годом рождения методологии является 2001. В феврале 17 отцов-основателей этого движения выпустили в штате Юта США манифест Agile , содержащий основные ценности и принципы эджайл.
Четыре главные идеи:
· люди и взаимодействие важнее процессов и инструментов;
· работающий продукт важнее исчерпывающей документации;
· сотрудничество с заказчиком важнее согласования условий контракта;
· готовность к изменениям важнее следования первоначальному плану.
Из них вытекает 12 принципов:
· наивысшим приоритетом признается удовлетворение заказчика за счёт ранней и бесперебойной поставки ценного программного обеспечения;
· изменение требований приветствуется даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
· частая поставка работающего программного обеспечения (каждые пару недель или пару месяцев с предпочтением меньшего периода);
· общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта;
· проекты следует строить вокруг заинтересованных людей, которых следует обеспечить нужными условиями работы, поддержкой и доверием;
· самый эффективный метод обмена информацией в команде — личная встреча;
· работающее программное обеспечение — лучший измеритель прогресса;
· спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
· постоянное внимание к техническому совершенству и хорошему проектированию увеличивают гибкость;
· простота как искусство не делать лишней работы очень важна;
· лучшие требования, архитектура и проектные решения получаются у самоорганизующихся команд;
· команда регулярно обдумывает способы повышения своей эффективности и соответственно корректирует рабочий процесс.
Таким образом, Agile – это не какой-то отдельный прием или техника. Это система ценностей, или, если кому-то угодно, образ мышления, философия, объединяющая ряд подходов и практик для эффективного взаимодействия в быстро меняющейся среде. В число этих практик входят и такие, как Cunbun и Scrum .
Отличия от других концепций
Agile часто противопоставляют, так называемому, каскадному или водопадному (Waterfall ) методу достижению целей. Сторонники эджайл указывают, что их методы позволяют добиться большей эффективности и скорости выполнения задач.
Каскадный фреймворк существовал задолго до появления гибкой методологии разработки. Он предполагает, что команде разработчиков четко известно, что именно должны получить на выходе. Исходя из этого понимания, разрабатывается техзадание, которому следуют все члены команды на протяжении жизненного цикла:
Требования заказчика=>Проектирование=>Реализация (разработка) продукта=>Тестирование=>Приемка=>Сопровождение.
Это довольно громоздкая и неповоротливая конструкция, которая весьма уязвима в условиях постоянно меняющихся требований. Если на определенном этапе закралась ошибка, то ее исправление потребует огромных ресурсов.
По другую сторону барикад - техника Do &Fix (сделать и исправить), исповедуемая небольшими командами, выполняющими простые проекты. У разработчиков нет определенного плана действий или техзадания, а четкое видение конечного продукта содержится только в их (безусловно, умных) головах. Сотрудники действуют по принципу «война план покажет», решая задачи по мере возникновения. Схематично процесс выглядит как беспорядочное броуновское движение, которое, впрочем, тоже может привести к результату.
Принципы Agile исповедуют итеративный подход, который более упорядочен, чем детище адептов вселенского хаоса, но не так громоздок, как махина водопада. Весь процесс делится на небольшие кусочки – итерации. Каждый этап тестируется, проверяется и согласовывается с заказчиком, если требуется – вносятся изменения. Если нет - продукт может быть выпущен на рынок без предусмотренных изначально функций, которые могут быть добавлены в дальнейшем.
Каждый, кто готовил суп, пользовался итеративным подходом. Когда бульон уже сварен, ты его пробуешь (тестируешь). Можешь посолить, поперчить, добавить лавровый лист, а можешь снять с огня и потреблять как готовый продукт, если того потребует твой заказчик, лютый голод. По мере приготовления тестирование происходит постоянно, и в зависимости от результата в рецепт (техзадание) могут вноситься изменения. Если так захочет product owner , мы так увлечемся новыми фичами, что к обеду вместо борща получим черепаховый суп. Все равно оба продукта закрывают одну и ту же потребность.
Какая методология лучше
Спорить о том, какой подход лучше: водопадный или итеративный также бессмысленно, как рассуждать, кто сильнее: Шварценеггер или Сталонне. Или, допустим, что нам пригодиться сейчас: нож или лопата. Если (продолжая кулинарную тему) требуется нарезать хлеб, то решать задачу лопатой будет только истинный «гений», получивший свои полномочия явно через блат. Если же мы роем могилу для такого менеджера, то адекватный исполнитель выберет именно этот инструмент.
Каскадный фреймворк эффективен в проектах, когда четко известна конечная цель, причинно-следственные связи очевидны, процессы имеют высокую степень определенности. Он применяется и будет применяться за неимением ничего лучшего в такой деятельности, как, например, строительство домов или производство самолетов.
Итерации часто используется в IT , где в любой момент можно внести изменения в программный код продукта или его дизайн.
Здесь применима модель Cynefin (среда обитания), разработанная консультантом по менеджменту Дэвидом Сноуденом. Для начала определяем, с какой системой имеем дело.
Для хаотичной системы (Chaotic ) подходит do&fix . По крайней мере, на начальном этапе, пока процесс не приобретет какую-то структуру. Упоминаемый нами водопад целесообразен в простой упорядоченной среде (Simple Orders ).
Для запутанной (Complex ) среды характерна неопределенность построения системы и неочевидность причин и следствия до контакта с контекстом. Здесь и применяется наш любимый эджайл.
Подводя итог, гибкую методологию разработки отличают следующие признаки:
· Постоянное формирование требований на основе целевого видения продукта;
· Короткие горизонты планирования (1-2 мес.);
· Разделение процесса на короткие итерации (спринты);
· Реализация внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля;
· Каждый участник процесса «конвейерной сборки» вовлекается в процесс переосмысления своих задач и общего дела; каждый может вносить изменения и даже остановить разработку;
Scrum
Scrum – один из фреймворков, построенный по принципам Agile .
Что имеем на входе.
· Команда (Team ) из 7 (плюс-минус 2) человек.
· Требования (Backlog) для будущего продукта.
По правилам итерации время на изготовление продукта делится на короткие промежутки (спринты) по 1-4 недели. Сам бэклог дробится на задачи (user story ), в которых содержатся пожелания клиента.
В центре скрама находится команда. Руководителя в классическом понимании коллектив не имеет, взаимодействие построено на самоорганизации и сознательности каждого из исполнителей. Лидеры появляются в отличие от выполняемой задачи.
Однако есть пара человек, изначально наделенных особой ролью.
Первый – это Product owner , который представляет владельца бизнеса или заказчика и зачастую делегируется ими. Это специалист, который знает, что именно должно получиться на выходе, а чего получиться не должно.
Второй - Скрам-мастер, координирующий ежедневные собрания и создающий комфортные условия для команды.
Работа запускается с того, что владелец продукта при помощи коллектива распределяет по приоритетам задачи бэклога. На основании этого приоритета команда формирует бэклог спринта, то есть user story, которые предстоит проработать в ближайший промежуток времени.
Зачастую карточки с задачами наносятся на специальную доску с тремя колонками:
- Надо сделать (to do )
- В процессе (Working process)
- Готово (done)
По мере прогресса карточки перемещаются из одной колонки в следующую.
Отличительная черта скрама – ежедневные совещания (Daily meeting). По традиции они проводятся стоя, в одном и том же месте и в течение 15 минут. Скрам-мастер задает участникам 3 вопроса:
- Что было сделано вчера?
- Что будет сделано сегодня?
- Какие есть проблемы?
По окончании спринта команда демонстрирует результат product owner , который фиксирует, какие задачи выполнены, а какие – нет. Также коллектив проводит ретроспективу, на которой обсуждает, что надо сделать, чтобы улучшить процесс.
Kanban
Доска с карточками («надо сделать» - «в процессе» - «сделано»), используемая в Scrum , - это элемент другого инструмента из семейства эджайл – Канбан. Метод был внедрен на заводах «Toyota » в 1962 году, и в переводе с японского его название означает «рекламный щит» или «вывеска».
В отличие от Скрама, в Канбане может использоваться не три колонки, а гораздо больше. В этом методе нет обязательных совещаний или четкого разделения ролей в команде.
Для чего нужен Канбан:
· визуализация рабочего процесса;
· разделение работы на задачи;
· для гибкости планирования, всегда можно изменить приоритеты;
· увеличивает вовлеченность всех членов команды в работу;
· помогает уменьшить длительность итераций. Вся команда видит, кто из ее членов тормозит общее дело и может помочь, чтобы восстановить поток;
· Быстрое выявление проблем.
К недостаткам метода относят то, что он применим только к небольшим командам 5-10 человек. Чем больше участников, тем запутанней и сложнее получается схема рабочего процесса. Подходит в первую очередь для краткосрочного планирования. В долгосроке эффективность может быть нулевой.
Lean
Также, как и Agile , бережливое производство Lean – это не инструмент, а отдельный подход, позволяющий добиться эффективности. В основе концепции лежит управление предприятием, основанное на постоянном стремлении снижения потерь. Стала применяться на заводах «Toyota », как и описанные выше таблички.
Основатель концепции Тайити Оно выделял 7 видов потерь:
· из-за перепроизводства;
· потери времени из-за ожидания;
· при ненужной транспортировке;
· из-за лишних этапов обработки;
· из-за лишних запасов;
· из-за ненужных перемещений;
· из-за выпуска дефектной продукции.
Впоследствии к этой группе добавили восьмой пункт - нереализованный творческий потенциал сотрудников.
Вся деятельность предприятия делится на операции и процессы, добавляющие ценность продукту и не добавляющие ее.
Бережливое производство применительно к стартапам было описано американским предпринимателем Эриком Рисом в книге «Бизнес с нуля».
Концепция бережливого стартапа позволяет проектировать продукт или услуги, имеющие ценность для клиента, без использования значительных ресурсов.
Выделяют 3 ключевых принципа:
- Обобщение гипотез предпринимателей в виде канвы бизнес-модели, представляющей из себя инструмент управления в виде схемы, описывающей все бизнес-процессы компании: предложение, инфраструктуру, потребителей и финансы. Проще говоря, это схема, иллюстрирующая, как компания создает ценность для клиентов и себя;
- Проверка гипотез и получение обратной связи с помощью подхода «выйди за пределы офиса»: так называемый, CustDev (Развитие пользователя). Для того, чтобы продукт имел реальную ценность для клиента, нужно выяснить, что ему нужно. Причем, процесс осложняется тем, что сам пользователь не всегда может внятно ответить на этот вопрос.
- Использование методики гибкой разработки продукта. Создание минимально жизнеспособного продукта (MVP ), чтобы проверить, имеет ли наша идея какую-то ценность для клиента. Перед тем, как производить партию лопат, дадим огороднику детский совок. Сможет ли клиент посадить картошку или закопать безумного менедера из первой части этой статьи? Просит инструмент повнушительней? – Ок! – Запускаем линию по изготовлению полноценных лопат.
Общее правило бережливого стартапа Эрик Рис сформулировал как «создавай-измеряй-учись».
Обратная сторона бережливого стартапа.
Концепция Lean Startup сконцентрирована на экономии времени, финансов и других ресурсов. Позволяет резко увеличить скорость выпуска продукта, однако, многие знают, что спешка нужна только в двух случаях, и бизнес в их число не входит. Отсюда возникают некоторые издержки.
1. Продукт может получиться «сырым», лишенным ряда необходимых для пользователя функций. Лопату сделали – а черенок приделать забыли.
2. Высокая скорость работы может способствовать выгоранию членов команды.
3. Сосредоточение на постоянной генерации MVP не позволяет заняться «фундаметом» продукта – его архитектурой.
При подготовке статьи использовались
лекции Алексея Таченкова https://www.youtube.com/channel/UCfAYkkvrrjRp_DS010HtYOQ
Ресурсы https://vc.ru/ и https://habr.com/ru/
