Agile структура: Гибкая методология разработки — Википедия – Agile/Scrum для начинающих. Что такое гибкая методология?

Agile/Scrum для начинающих. Что такое гибкая методология?

Что такое Agile и Scrum?

Что такое Agile?

В переводе с английского языка «agile» означает «живой, подвижный», но переводят его чаще как «гибкий». В отрасли разработки программного обеспечения этот термин появился в начале 2000-х годов, когда в штате Юта был издан «Манифест гибкой разработки ПО». С тех пор под «agile» понимают набор подходов по “гибкой” разработке программного обеспечения.

Agile Manifest

Суть agile-подхода изложена в “манифесте”, но для заказчика ее можно коротко сформулировать так:

• разработка ведется короткими циклами (итерациями), продолжительностью 1-4 недели;
• в конце каждой итерации заказчик получает ценное для него приложение (или его часть), которое можно использовать в бизнесе;
• команда разработки сотрудничает с Заказчиком в ходе всего проекта;
• изменения в проекте приветствуются и быстро включаются в работу.

В настоящее время agile-принципы используются в работе десятки тысяч команд по всему миру.

Основополагающие принципы Agile.

Краткое видео о том, что такое Scrum (english).

Что такое Scrum?

Scrum – это одна из нескольких методологий гибкой разработки ПО:

• • Scrum
  • Lean
  • Feature Driving Development
  • Extreme Programming

Scrum процесс на одном листе

Scrum – это спортивный термин, который пришел к нам из регби, и представляет собой фигуру, которую образуют игроки перед началом игры.

Артефакты в Scrum

В скрам используется всего четыре артефакта:

• Product Backlog
• Sprint Backlog
• Sprint Goal
• Sprint Burndown Chart.

Я рекомендую вам посетить наш тренинг “Scrum для проектных команд“. Тренинг помогает изучить Scrum-процесс от начала и до последних нюансов.

Product backlog:

• Это список всех требований, которые нужно сделать по проекту. Когда в Backlog’e нет требований, проект считается завершенным.
• Все требования описаны по единому шаблону, который называют User Story (пользовательская история).
• Требования составлены так, что очевидно и понятно, какую ценность они представляют для пользователя
• Требования отсортированы по приоритетам, которые пересматриваются каждый спринт.

На снимке ниже представлен Backlog проекта. Команда проекта выбрала 2 требования в Sprint#3.

Project Backlog (JIRA)

Sprint backlog:

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

Sprint Backlog – это обязательство команды: что они должны выполнить за ближайшие 2 недели. Каждое требование разделено на задачи, которые представлены на Kanban-доске.

Kanban Доска в Спринте

Sprint Goal

• это краткое описание того, ради чего выполняется данный спринт.
• цель на спринт помогает команде принимать обоснованные решения.

Этот артефакт необходим для того, чтобы команда проекта могла самостоятельно принимать решение в случае появления альтернативных путей решения задачи. Чтобы решения команды были осознанными, Product Owner определяет цель спринта.

Sprint Burndown Chart

• дословно “диаграмма сгорания”
• в качестве “сгорающих” элементов выступают человеко-часы или идеальные единицы (Story Points).
• диаграмма обновляется каждый раз, когда завершается какая-либо задача.

Внешний вид диаграммы на рисунке ниже. На практике такая диаграмма очень наглядна: каждый день можно быстро узнать, насколько команда продвинулась вперед.

Burndown диаграмма в Jira

Если есть время, посмотрите мою запись о книгах, которые можно скачать для изучения Agile/Scrum.

Роли в Scrum

В скрам используется всего три роли:

• Product Owner
• Scrum Master
• Team.

Роль Product Owner

• формулирует требования
• приоритезирует требования
• корректирует приоритеты на каждом спринте
• несет персональную ответственность за ценность требований для рынка/пользователей
• отвечает за взаимодействие с рынком
• только один человек

Product Owner – это представитель подразделения, которое владеет разрабатываемым продуктом. Например в банке это может быть Департамент карточных продуктов. Правильно определить Product Ownera не просто, т.к. эта роль требует сочетания следующих качеств:

• иметь личную вовлеченность в проект и его результаты;
• хорошо владеть навыком написания требований.

В некоторых случаях допустимо назначить более одного человека на роль Product Owner. Но в этом случае необходимо назначить среди них “главного”, который будет авторизовать требования в Bcaklog’e и лично расставлять приоритеты.

Роль Scrum Master

• следит за корректным применением принципов Agile и процессов (ритуалов) Scrum
• организует работу команды и обеспечивает её всем необходимым
• защищает команду, несёт ответственность за её эффективность
• только один человек.

Очень сложная роль. В классическом project management есть Руководитель проекта. В Scrum такая роль не предусмотрена. Лучшим синонимом роли Scrum Master будет “администратор”. Скрам Мастер организовывает работу команды проекта, но не вмешивается в её работу.

• Скрам мастер не назначает людей на задачи – это делает сама команда;
• Мастер не заставляет людей делать работу – это ответственность команды;
• Мастер не указывает Product Owner какие требования он должен написать – это работа владельца продукта.

Тем не менее, если скрам-процесс проходит с нарушениями (кто-либо из команды опаздывает на daily-meeting), то мастер должен вмешаться и исправить ситуацию.

Функции Scrum Master’a существенно шире, но чтобы пояснить их все нужна отдельная статья. Пишите в комментариях, если таковая нужна.

Team (команда проекта)

• кросс-функциональная
• взаимозаменяемая
• самоорганизующаяся
• с фиксированным составом (в ходе спринта)
• 4-10 человек.

Команда отвечает за разработку продукта итерациями (спринтами). Команда определяет самостоятельно:

• продолжительность спринта
• емкость (capacity) команды
• размер её фокус фактора (коэффициент слаженности)
• трудоемкость требований, которые будут реализованы в спринте
• очередность выполнения задач и много другое.

Команда НЕ принимает решений:

• какие требования являются приоритетными – это делает Product Owner.

На снимке ниже команда проекта проводит обязательный “ритуал” – Daily Meeting (см. ниже).

Команда проводит “ритуал” Daily Meeting

Для компаний, которые решили системно перейти на методологию Scrum, я рекомендую ознакомиться со структурой проекта внедрения и рекомендациями заказчику.

Ритуалы (процессы в Scrum)

В скрам есть несколько процессов, которые принято называть ритуалами. Каждый ритуал выполняется неукоснительно и в строгом соответствии с подходом. На практике такие процессы стараются немного адаптировать, но ключевые принципы не изменяют.

Ритуалы в скрам это:

• Sprint Planning Meeting
• Daily Meeting
• Sprint Review
• Retrospective

Sprint Planning Meeting (встреча по планированию спринта)

• выполняется всей командой перед началом спринта
• команда выбирает требования из Product Backlog и формирует Sprint Backlog
• если требуется учесть взаимосвязи между операциями, то это делается здесь
• команда декомпозирует требования на задачи (tasks)
• каждая задача проходит оценку в трудозатратах или универсальных единицах
• во время встречи Product Owner отвечает на вопросы команды.

Встреча, которая проводится перед началом каждого спринта. Структура встречи:

• представление и пояснение Product Owner’ом списка требований
• вопросы со стороны команды
• /рекомендуется перерыв/
• декомпозиция требований на задачи (tasks)
• оценка задач по методу Planning Poker.

Встреча простая по сути, но крайне сложная по содержанию. В начале проекта может занимать 5-6 часов. И только после 3-4 спринта встреча становится более оперативной и длится 2-3 часа. Крепитесь.

Daily Meeting (ежедневная встреча команды).

Из названия понятно, что встреча проводится ежедневно. Основные принципы:

• проходит ежедневно и только в одно и то же время;
• встреча проходит только стоя;
• поэтому длительность встречи не более 15 минут;
• чтобы успеть каждый должен ответить всего на 3 вопроса: что я делал вчера, чем я занимаюсь сегодня, какие есть проблемы?

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

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

Встреча команды эффективно проводить напротив Kanban доски, на которой отражены все задачи спринта.

Что такое Agile — методология управления проектами

Agile в управлении проектами — это применение принципов гибкой разработки в проектном менеджменте с высокой степенью
неопределенности и рисков.

Agile (англ. – проворный) – это семейство
«гибких» подходов к разработке программного обеспечения.

Многим до сих пор непонятно это слово. Давайте разберёмся и поймём, что это не страшно, а даже классно и полезно.

Agile – не методология!

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

На стадии инициации проекта нужна большая часть информации о производстве продукта. Чем ближе к нулю времени, тем больше гипотез и меньше результата.

«Водопадный» подход описывает метафора автономной подводной лодки,
которая уходит в плавание в Северный Ледовитый океан. Загрузили команду, продукты, отдано
боевое задание. Всё готово, инструктаж проведён, и лодка ушла под лёд на 3 месяца. Там она что–то
делает–выполняет без всякой связи с внешним миром. Через 90 дней экипаж прибывает обратно и отчитывается о проделанной работе.

А ведь старый приказ могли отозвать, он мог потерять свою актуальность и необходимость. Выходит, время потрачено зря, а результат не несёт ценности.

Нам проще и быстрее понять, что нужно сделать по–другому

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

Мы привыкли мыслить водопадными проектами

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

Концепция Agile предлагает: «Давайте не тянуть до последнего, чтобы увидеть результат, а будем действовать
разумно. Разобьём всю длину проекта на недельные интервалы, будем создавать план работы на будущий отрезок,
выполнять поставленные задачи и смотреть, что получилось. А потом принимать решение, куда двигаться
дальше».

Совсем не обязательно в конце одной маленькой итерации отдавать клиенту что–то работающее. Смысл в получении
обратной связи. Можем показать просто упаковку без продукта внутри. За счёт отклика клиента появится множество возможных вариантов что–то исправить.

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

Поговорим о некоторых тонкостях внутри Agile

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

Вот кейс на примере реальной жизни. Промышленной IT–компании нужно было создать интернет–магазин сопутствующих
товаров, а они никогда такого не делали. Каким бы был ваш первый шаг?

Ребята сделали аналоговый макет стартовой страницы магазина на маркерной доске, поставили рядом с ней человека,
который ловил мимо проходящих и просил их протестировать ассортимент, цены, внешний вид сайта. Так предприятие получило много комментариев путём устного анкетирования. Очень быстро и дёшево.

Обратная связь – самое важное, что нужно получать как можно быстрее. Какие бы проекты мы не делали.

Cтруктурная составляющая проекта

В традиционной команде есть руководитель проекта, который за него отвечает. У него есть исполнители, которым нужно раздать задачи: что и в каком объёме сделать. Но не
существует управленцев, которые могут создать идеальный план, который будет точь–в-точь совпадать с реальностью.

К тому же возникает такая проблема: как только появляется управляющий, указывающий что
делать, в этот момент мозги команды уходят в «спящий режим». Пропадает инициатива, исчезает ответственность, появляется отрицание.

В современном мире «люди–руки» уже изживают себя. Даже в таких крупных индустриальных предприятиях, таких как
Северсталь или Сибуре, обычные исполнители не нужны. Если человек не думает, он не приносит ценности.
Лучше его роботизировать. Поэтому нужно создать такие условия, при которых будет максимальная вовлечённость и высокая ответственность за конечный результат. Тогда руководитель будет не нужен. Совсем.

У команды должен быть тот, кто её вдохновляет, направляет к цели и говорит, куда и зачем они идут. В
Agile–сообществе он часто называется Product Owner (владелец продукта).

С ним «люди–руки» становятся «людьми–головами».
И для них ВП создаёт такие условия, в которых они могут договариваться. Никто в Agile не отменяет бюджеты
проекта, его сроки. Пусть люди ежедневно встречаются по 10 раз и решают, кому и чем лучше заняться
сейчас, чтобы был максимальный результат.

У Agile–команды чаще возникают неорганизационные вопросы

Её интересуют вопросы по продукту, который они будут совместно
делать. И ответы знает человек, который понимает, что они создают.

Представьте, что нужно внедрить SAP (автоматизацию бизнес–процессов) и получить на выходе какую–то
бизнес–ценность: уменьшить количество ошибок или операций.

Как мы привыкли поступать?

Сначала описываем все
требования и отдаём их на разработку подрядчику. Он у себя что–то делает, тестирует и возвращает нам. Готовый
результат мы тестируем уже у себя, потом внедряем. Внести изменения в него в случае неудовлетворённости уже сложно,
потому что деньги уже уплачены.

Как применить Agile в этом случае?

Очень просто! Есть огромное количество бизнес–процессов, которые можно
автоматизировать. Мы даём подрядчику
недельный план, в котором указываем, что наиболее важно в данный момент.

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

Когда мы двигаемся короткими отрезками, велика вероятность, что мы будем что–то переделывать. Но это единственный
современный способ идти верным путём. Да, придётся что–то переделывать, никто не совершенен, ошибки и недочёты
неизбежны. Но качество конечного результата окупит все промежуточные переживания.

Как быть, если не хватает бюджета на единовременный контракт?

Мы можем договориться с подрядчиком о передаче
специалистов в наш офис. Пусть они на месте делают автоматизацию бизнес–процессов. А мы будем платить не по
fix-price контракту, а месячную зарплату.

Так мы будем видеть появление результата сразу и будем
корректировать их действия постоянно, дополняя обновлёнными пожеланиями. Нам понятно, чем они занимаются, значит, обеспечивается полная
прозрачность в расходовании денег.

Почему это сложно сделать в крупной компании?

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

Например, мы Agile–команда. Мы понимаем, что получим согласование на
разработку продукта через 2 недели. Тогда пытаемся командно придумать, как получить одобрение
быстрее.

Как правило, есть возможность ускорить реализацию за счёт личных
взаимоотношений. Поверьте, это возможно сделать и в Сбербанке, и в Газпроме – компаниях с очень сильной бюрократией.
«Люди–руки» получат ответ только через 2 недели, поэтому они
не могут конкурировать в эффективности с «людьми–головами».

Как же переходить на новый подход?

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

В Сбербанке было так: Герман Греф однажды пришёл в офис и прокричал «Всем Agile!». Идея отличная, только люди
были к ней не готовы. Поэтому процесс её внедрения сильно растянулся и сейчас почти не двигается. Лучше,
когда есть пилотные команды внутри организации. Они начинают работать по–другому и заражают этим методом всех
остальных.

Но есть и обратная сторона. Корпоративная культура ест Agile–процессы на завтрак, как говорится в поговорке. Поэтому
нужна сильная поддержка менеджмента.

Также людей нужно постоянно обучать. И Сбербанк начал проводить сумасшедшее
количество тренингов. Но прежде чем требовать что–то от людей, мы должны им рассказать, что хотим от них. И
помочь выстроить у них в голове необходимость и правильность новых изменений.

Agile – история про здравый смысл, а не про регламентированность

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

Самый большой минус

Удалённость, она мешает коммуникациям.

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

Как реализуется agile в управлении проектами? Для agile–подхода к проектному менеджменту характерно несколько ключевых элементов.

Они по разному реализуются, в зависимости от конкретного фреймворка. Здесь мы рассмотрим все базовые особенности проектного менеджмента в agile.

Фокус на взаимодействие людей

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

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

Фокус на ценность продукта

Работая по agile, нас интересуют прежде всего не дедлайны и “правильность” рабочих процессов, а работоспособность и ценность итогового продукта, который получит клиент/заказчик.

Все внимание agile–команды направлено на работоспособный продукт.

Принцип инспекции

Для проектного менеджмента в духе agile важно находиться в контакте с новой поступающей информацией (например, новые конкуренты, новые технологии, изменение ситуации на рынке). Реализовать такой контакт с реальностью позволяет принцип инспекции.

Реализуя agile мы регулярно отслеживаем те изменения, которые происходят как внутри команды и в командных процессах, так и в “среде” — на рынке.

Принцип адаптации

Мало просто отслеживать изменения, если с этим ничего не делается. Принцип адаптации позволяет команде и проекту изменить свой продукт и свою работу таким образом, чтобы максимально точно попадать в потребности и задачи заказчика.

Для реализации принципа адаптации в проектном менеджменте важно, чтобы все члены команды были открыты новому опыту и изменениям. Как правило в agile–команде есть человек, который отвечает за то, чтобы новые изменения были встречены позитивно (например, Скрам–мастер в Scrum).

Инкрементальный и итеративный подход

Реализуя управление проектами по agile, мы стремимся к тому, чтобы максимально часто и быстро давать заказчику результат.

Такой подход позволяет получать обратную связь чаще, и за счёт этого — еще лучше адаптировать реализацию проекта под заказчика, гибко подстраивать реализацию проекта в соответствии с обратной связью.

Планирование всей командой

Команда несет общую ответственность за результат.

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

Оценка при этом дается не в днях и часах, а условно — относительно относительно других задач, что позволяет принимать решения о том, что делать в следующую очередь в проекте, несмотря на неопределенность.

Резюме

Управление проектами в agile — позволяет гибко подходить к реализации проекта, снижать возможные риски и действовать эффективно в условиях повышенной неопределенности и рисков.

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

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

Подведём итог

Agile–философия подходит вашей компании, если:

• над проектом работает опытная, высококвалифицированная команда
• вы работаете над стартапом
• нужно быстро получить рабочую версию продукта
• за

Scrum и Agile для чайников

Автор Елена Трускова На чтение 8 мин. Просмотров 7.5k. Опубликовано 10.05.2017

Комментарий Котиков

Для начала. Scrum и Agile — в чем разница? Если коротко, Agile — это философия, семейство гибких подходов к разработке ПО. Scrum — один из таких подходов. У него есть братик — Kanban. Он тоже подход, используемый в Agile.

Елена Трускова рассказывает:

На этой неделе я прошла двухдневный тренинг по Agile/Scrum (произносится «эджайл» и «скрам»). По гибким методологиям разработки программного обеспечения написано много заумной и не очень литературы, многое я читала. Но только после двухдневного погружения в тему у меня наконец собралось базовое понимание предмета, из которого я пишу эту заметку.

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

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

Принципы скрама можно применить совершенно ко всему: например, к работе над творческим продуктом. Это, конечно, не «канонический эджайл», скрам-евангелисты будут скрежетать зубами, зато ваши процессы будут двигаться бодрее. Шашечки или ехать?

Кое-что из эджайла и скрама можно взять даже в индивидуальную работу. Обеспечить регулярную публикацию постов, отмерять нагрузку на исполнителя, оценивать будущие задачи по времени и не забывать анализировать качество проделанной работы — смотрите, за нас уже всё придумали. Осталось внедрить.

Эджайл

(англ.agile —«проворный, шустрый, сообразительный»)

Концепция гибкости:

Подставьте свой вид деятельности вместо слова «разработка» — и эти принципы станут близкими и понятными.

«Работающий продукт — основной показатель прогресса», «простота как искусство минимизации лишней работы» и «люди и взаимодействие важнее процессов и инструментов» — правда, звучит разумно?

Книжку «Открывая организации будущего» Фредерика Лалу я читала совсем недавно. Вполне бодрый подход ко всем отраслям на свете

Скрам

(англ. scrum — толкотня в борьбе за мячик в регби)

Тут стоит напомнить, что это моя личная и субъективная точка зрения на скрам. Здесь я размышляю о применимости элементов скрама как в творческих проектах, далеких от IT, так и в индивидуальной работе (скажем, над блогом). Много точных деталей для этого придется упустить; я стараюсь сохранить простоту текста и не перекормить читателя терминологией.

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

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

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

Иметь такую уверенность в скраме не страшно, поскольку каждый марш-бросок длится ровно один спринт (четкий отрезок времени, обычно от одной до четырех недель). После того, как спринт закончился, наступает момент анализа: а как мы его прошли? Что можно было бы сделать еще лучше в следующий раз?

Поэтому даже если мы все уверенно побежали в неправильном направлении, у нас будет в конце спринта возможность его скорректировать и починить то, что нас направляет не туда. Команда в скраме самоорганизующаяся и самонастраивающаяся.

Команда в скраме

Стандартный размер скрам-команды — 7 плюс-минус 2 человека. То есть от пяти до девяти. Бывает скрам-масштабирование: можно из 25 команд состроить систему работы над гигантской задачей. Но основная единица скрама — команда.

В каждой команде есть:

• участники (в случае IT — разработчики, кто эти семь человек у вас — решите сами)
• продакт оунер (product owner, владелец продукта). Его роль: понимать рынок и пользователя, формулировать задачи на языке бизнеса и пользователей, держать в голове осознание того, в каком направлении должны развиваться ценность и польза, придумывать и отбирать задачи для развития продукта. Что-то вроде руководителя продукта (не команды).
• скрам мастер (scrum master, скрам-евангелист). Его роль: следить за процессом, наблюдать за внутренней жизнью команды, мотивировать людей, устранять препятствия. Что-то вроде тренера.
  Вокруг команды есть пользователи и стейк-холеры (stakeholders, заказчики). К этим людям продакт оунер ходит советоваться.

Устройство спринт

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

У продакт оунера есть список идей от бизнеса для осчастливливания пользователей. Он называется «продакт бэклог» (product backlog, список продуктовых идей). В нем идеи отсортированы по важности и значимости.

В каждом спринте есть спринт бэклог (sprint backlog, список задач на спринт) — отсортированный список идей, которые команда решила сделать за ближайший спринт. Смысл скрама в том, что команда сама оценивает сложность каждой задачи и решает, какие задачи войдут в очередной спринт.

Задача в спринте имеет известный команде вес (известно, сколько времени на неё уйдет), к ней прикреплен исполнитель, она является понятной и важной. Если неизвестно, сколько времени уйдет на задачу, нужно её разбить на более мелкие части.

В начале своей жизни команда всегда плохо планирует. Это объективная реальность. Но она ведет статистику того, что ей удается сделать за спринт, и со временем планирует всё точнее. Ей помогает итоговая встреча спринта — ретроспектива. На ней можно обсудить слабые моменты уходящего спринта и придумать способы делать по-другому.

Обычно в спринт влезает 5 плюс-минус 2 идеи. Если идеи слишком большие, команда их дробит так, чтобы в каждом спринте можно было что-нибудь маленькое, да показать.

В скраме идеи называются юзер-сториз (user stories, истории про пользователей) и формулируются так: «Я как (роль?) хочу (что?) для того, чтобы (зачем?)». Таким образом команда видит не только функциональность, но и смысл её создания, причем для конкретной роли: пользователь, заказчик, покупатель.

Результатом спринта всегда является что-то, что можно показать. Показывает работу команда на демо в конце спринта.

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

Структура спринта

Спринт начинается с планирования: команда садится и обсуждает: вот эту идею берем, вон ту не берем. В IT этот процесс может затягиваться на пару часов, потому что обсуждение идет вплоть до деталей. В случае работы с блогом это может превратиться в обсуждение тем и плана статей, которые потом останется сесть и написать — понимая, что пишем, когда и зачем.

Каждый день есть стендап-митинг (stand up meeting, совещание стоя) на 15 минут. Делать его стоя важно: если кто-то заболтается, остальные красноречиво будут переминаться с ноги на ногу и чесать ухо. Можно использовать какой-то предмет, чтобы говорил в один момент времени только один участник, и передавать его по кругу.

Каждый участник стендапа по очереди отвечает на три вопроса:

• что я сделал вчера
• что я сделаю сегодня
• что меня тормозит

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

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

В конце спринта происходит демо (demo, демонстрация) с показом того, что удалось создать в течение спринта, спринт-ревью (sprint review, обзор спринта) с пересмотром продакт-беклога и разговорами о том, ЧТО мы делаем, а также ретроспектива (retro) — что мы делали не самым лучшим образом весь спринт и хотим улучшить далее — о том, КАК мы это делаем.

«Если бы у меня было восемь часов для того, чтобы срубить дерево, я бы шесть часов потратил на заточку топора». (приписывается лесорубу и президенту Аврааму Линкольну)

Подпишитесь на рассылку новостей. Никакого спама!

Email*

Подписаться

что это и как внедрить в свою компанию

Из этого материала вы узнаете:

• Что такое agile и в чём его преимущества
• Что такое agile маркетинг
• На каких принципах основывается agile
• Как внедрить agile в свою компанию

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

Agile — что это такое простыми словами

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

Новая система получила название «Agile software development», что переводится как «гибкая методология разработки». Ключевое слово здесь — гибкость. Вот какие идеи легли в основу Agile:

1. Коммуникация в команде важнее инструментария и методов.
2. Отлаженный продукт важнее бумаг и документов.
3. Позитивная связь с заказчиком важнее обсуждения пунктов договора.
4. Гибкость в решении задач важнее выполнения исходного плана.

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

Рекомендуем

«Генерация идей: много креативных способов и методик»
Подробнее

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

Чтобы следовать в работе философии Agile, зачастую используют сочетания методов, например Scrum или экстремальное программирование. Они помогают выстроить процессы исходя из принципов Agile. Конечно, эти методы подстраивают и адаптируют под каждую команду, но главные идеи из Agile-манифеста остаются неизменными.

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

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

Что такое Agile-маркетинг: его манифест и нюансы

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

1. Как зародился Agile-маркетинг

Основой Agile-маркетинга послужили принципы гибкого планирования, применяемые разработчиками ПО. Поскольку долгосрочная стратегия практически сразу становилась неактуальной при создании программ, то разработчикам оставалось лишь отказаться от жесткого планирования в пользу гибких методов. Их идеи были сформулированы в манифесте, увидевшем свет в 2001 году. Заказчики зачастую меняли требования по ходу работы над проектом, поэтому бездумное следование намеченному плану становилось неэффективным. Благодаря Agile-методам разработчики стали работать быстрее и с меньшим стрессом для себя.

Рекомендуемые статьи по данной теме:

С момента появления digital-инструментов маркетологи также увидели подводные камни долгосрочного планирования. Чем жестче был изначальный план, тем сложнее было своевременно реагировать на меняющиеся интересы рынка. Да и воспользоваться инфоповодами для хайпа своего продукта при классическом планировании практически невозможно.

Первым, кто задумался о применении Agile-технологий в сфере маркетинга, был некий Скотт Бринкер. Именно он сформулировал принципы манифеста по Agile-маркетингу.

2. Манифест Agile-маркетинга

Впервые манифест по Agile-маркетингу был представлен в июне 2012 года в рамках конференции Sprint Zero: The Physics of Agile Marketing.

Расширенное описание можно найти в «Википедии», мы же перечислим базовые идеи:

• Анализ ситуации вместо допущений и субъективизма.
• Равное сотрудничество с клиентом вместо иерархической структуры.
• Гибкие проекты и циклы задач вместо сложносоставных кампаний.
• Анализ конкретного клиента вместо прогнозирования на основе статистики.
• Гибкость при планировании вместо жесткого подхода.
• Изменение курса в ответ на изменения среды вместо слепого выполнения плана.
• Множество небольших экспериментов вместо одного крупного.

Ключевые достоинства Agile

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

Рекомендуем

«Конкурентные преимущества компании: как сформировать и развить»
Подробнее

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

Принципы и методы Agile

1. Внимание к потребностям и целям компаний-клиентов

Удовлетворение нужд клиента и забота о нем — это то, что отличает успешный бизнес от неудачливых конкурентов. Какие же конкретные инструменты Agile помогают достижению результата?

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

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

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

Вот некоторые из инструментов Agile, используемых для проведения подобных сессий: Lean Canvas, Impact Mapping, User Story Mapping, а также другие методы работы с гипотезами и процессами.

2. Оптимизация (в сторону упрощения) оргструктуры и рабочих процессов

Максимальная простота — фундамент всей системы Agile. Этот принцип касается организационной структуры, процессов и инструкций, которыми руководствуются сотрудники. Такой подход позволяет людям концентрироваться не на документообороте, а на конкретных задачах, на разрабатываемом продукте. Отличные результаты подобной методики можно увидеть в командах, внедривших Agile Scrum — один из самых востребованных методов в рамках системы Agile.

При работе по Scrum все планы и задачи команды из 9–11 человек на текущую итерацию фактически помещаются на 2-3 листах формата А0. Записи ведутся во время общих встреч, при планировании ближайшего цикла («спринта»). Если разместить протокол такого обсуждения в помещении, где работает команда, то в любой момент каждый участник сможет свериться с общими договоренностями и целями. Список всех задач на ближайшую итерацию обычно называют «бэклогом спринта». Кроме того, при работе по Scrum жестко фиксируется временной интервал всех встреч команды. Например, каждый из сотрудников знает, что в 11-00 во вторник будет планерка по следующей итерации, а в пятницу в 16-00 команда встретится для обсуждения процесса работы.

Топ-5 статей, которые будут полезны каждому руководителю:

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

Инструментами упрощения в Agile являются Scrum, Nexus, LeSS. И, конечно, сам Agile-манифест несёт в себе необходимые идеи для введения простых и прозрачных циклов работы.

3. Работа в рамках коротких итераций

Команда, работающая по Agile, не будет дистанцироваться от внешнего мира и доделывать проект несколько лет. При таком сценарии слишком велика вероятность получить абсолютно неактуальный и устаревший продукт.

Избежать подобного помогает итеративно-инкрементальный подход, при котором:

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

Рассмотрим эту схему работы на примере простого приложения «калькулятор». Представим, что на начальном этапе эта программа умеет лишь складывать два числа, при следующем рабочем цикле разработчики добавляют функции вычитания и умножения. Дальнейшие итерации позволяют делить и применять тригонометрические функции и т. д. И хоть первоначальный функционал нашего калькулятора был совсем небольшим, это было вполне работоспособное приложение. Можно было увидеть его интерфейс, воспользоваться имеющимися возможностями и продумать, как именно доработать программу. Кроме того, даже урезанной версией могли бы воспользоваться, к примеру, ученики начальной школы.

Благодаря применению подобного подхода команда способна дорабатывать приложение, начиная с ранних этапов, за счёт чего быстрее происходит вывод продукта на рынок. Кроме того, такой метод даёт возможность точного измерения прогресса: вместо абстрактного «мы сделали 20 % работы» звучит «мы доделали 20 % функционала».

Методы организации процессов в рамках методологии Agile имеют короткие итерации. Это Scrum, Nexus, LeSS, SAFe или XP. Оригинальный Agile-манифест также содержит идею о коротких циклах работы.

4. Активная коммуникация и регулярная обратная связь

Это один из самых важных пунктов для любого рабочего цикла. Именно за счёт коммуникации происходит корректировка планов и доработка разрабатываемого продукта.

Можно сказать, что каждый этап работы — это эксперимент, после которого как раз анализ обратной связи позволяет продвигаться вперёд. Похожий метод применяется во многих областях: ракетостроении, машиностроении, медицине (в т. ч. фармацевтике), психологии и экономике. В любом из этих направлений момент эксперимента и анализа обратной связи является ключевым для прогресса.

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

Примеры есть во многих инструментах Agile: ретроспективные встречи в рамках Scrum, Kanban, Nexus и LeSS, метод создания продуктов DesignThinking, итерации для обратной связи в DevOps.

5. Свобода участников команды при принятии решений

Чем четкая инструкция хуже передачи части полномочий каждому сотруднику? Есть несколько причин пойти по второму пути.

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

Во-вторых, вместе с полномочиями вы возлагаете на членов команды ещё и ответственность за конечный результат. Благодаря этому сотрудники начинают учиться самостоятельно принимать решения, осознавая их последствия. Построение такой команды — долгий процесс. Однако усилия себя оправдывают. Взрослые и ответственные сотрудники смогут справиться с ранее неизвестной сложностью в работе. Коллектив же не умеющих принимать решения взрослых детей — нет.

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

Многие методы организации работы по Agile, в особенности те, что базируются на фреймворках Scrum, поощряют лидерство и самоорганизацию сотрудников.

6. Гуманизм как основа работы

Так ли важно для успешного ведения бизнеса относиться к людям по-человечески?

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

Рекомендуем

«Эффективное управление: что это такое и как его реализовать»
Подробнее

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

Счастливые сотрудники лучше выполняют поставленные задачи. Agile-подход как раз и позволяет реализовать данную модель через качественно настроенную коммуникацию между членами команды.

7. Agile — это не результат, а образ мышления членов коллектива

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

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

А чем выше удовлетворение от процесса работы, тем существеннее результаты. И для менеджеров это более значимая мотивация, чем для специалистов.

Примеры Agile

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

№ 1. Стандартная модель управления кондитерской

Технологу необходимо разработать новый вид торта. Даже если будет проведен опрос о вкусах покупателей, технолог, скорее всего, будет ориентироваться на желания своего руководителя. В такой компании именно менеджер решает, поступит ли новый рецепт в производство. При такой схеме технолог делает лишь один вариант, который одобряется или выбраковывается. Чтобы торт попал на прилавки, рецепт должен понравиться генеральному директору.

Описанная ситуация — классика для российского бизнеса. Сотрудники в этом случае умеют лишь выполнять четкие указания, а решения принимает один, максимум три человека.

№ 2. Кондитерская с внедренным Agile-подходом

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

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

Гибкие технологии управления чаще всего используются в деловой сфере и IT. Также подобная модель применяется в маркетинге и сфере обучения. Agile практикуют многие государственные и коммерческие структурах, например ReturnPath (компания-разработчик ПО), Oreo (знаменитый производитель печенья), пенсионный фонд Норвегии, а также крупный агрегатор авиабилетов Aviasales.

В России Agile успешно апробирован в банковской сфере в рамках отдельных команд, например в «Сбербанке» и «Альфа-банке». Также гибкий подход применяют в команде бухгалтерского сервиса «Кнопка» и сети пиццерий «Додо Пицца».

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

Как внедрить Agile в свою компанию: пошаговая инструкция

1. Необходимые действия перед внедрением Agile

При переходе следует соблюдать баланс между классическими и гибкими приемами управления, чтобы адаптировать коллектив.

Среди базовых методик гибкого подхода обычно выделяют:

• Решение задач сообща. Заказчик, менеджер и члены команды работают вместе, чтобы обеспечить единое понимание цели и обмен информацией.
• Визуальный контроль. Занятые в проекте сотрудники используют цветные карточки или другие индикаторы для обозначения степени готовности того или иного участка проекта (например: «спланировано», «разработано», «завершено»).
• Адаптированное управление. Задача менеджера не в раздаче задач, а в контроле исполнения правил сотрудничества.
• Дробление проекта на циклы. Благодаря этому команда фокусируется на задачах конкретного этапа.
• Корректировка продукта. В каждом цикле команда анализирует возникающие ошибки и накапливает опыт, чтобы при следующей итерации избежать недочетов.

Agile рекомендуется внедрять, если команда к этому подготовлена, а именно:

• есть четкая цель проекта и конкретный срок для её достижения;
• объемную работу возможно поделить на несколько этапов;
• проведен анализ потребностей целевой аудитории;
• налажен сбор данных, обозначены показатели для оценки результатов;
• заказчик готов стать активным участником процесса;
• в команду входит до 10 человек.

2. Этап внедрения Agile

Вот с чего следует начать:

• Анализ потребностей аудитории. Команде важно знать, кто и зачем будет использовать ее продукт. Критерии должны быть актуальны и измеримы. Важна обратная связь с целевой аудиторией.
• План. В рамках организационного собрания сформулируйте идею проекта, распределите ресурсы и расставьте дедлайны, разделив проект на небольшие этапы.
• Сбор команды. Подберите сотрудников на проект, распределите задачи и утвердите график встреч.
• Выбор методик для распределения задач, создания отчетов и анализа результатов.
• Обучение сотрудников принципам Agile. Для эффективной работы каждый участник команды должен понимать и разделять основные идеи гибкого подхода.
• Тест-драйв. Этот этап лучше провести под наблюдением специалиста, чтобы получить разъяснение ролей и наглядную демонстрацию работы по циклам.
• Запуск спринтов. После каждого этапа проводится оценка результата и корректировка дальнейшего плана.
• Создание конечного продукта.

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

Ниже мы рассмотрим некоторые нюансы применения Agile-технологий в сфере маркетинга.

Не нужно полностью отказываться от планов и стратегий. Agile лишь позволяет придать традиционным маркетинговым приемам больше гибкости. Основная цель при этом всегда остается неизменной — максимальная доля рынка, занимаемая компанией.

1. На этапе планирования

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

2. Организация процесса работы

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

   
   — с менеджером из агентства по вопросам рекламных активностей;

   
   — с аналитиком и/или разработчиком, контакты которых дал менеджер проекта.

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

3. Коммуникация с агентствами

   
   Будьте максимально откровенны и открыты при общении с менеджером агентства. Пришла в голову отличная идея по уже запущенной рекламной кампании — позвоните и обсудите. Есть вопросы по отчету — не откладывайте разговор. Не нравится присланный креатив — организуйте звонок по скайпу с дизайнером, чтобы достичь единого видения.

4. Коммуникация с разработчиками

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

Рекомендуем

«Как составить бизнес-план и на что обратить внимание при разработке»
Подробнее

Наличие отлаженных горизонтальных связей существенно облегчает работу. Легче сразу проговорить с разработчиком свои идеи и получить годный продукт с первой, а не с десятой попытки. Старайтесь также участвовать в планировании циклов и ретроспективах. Что делать, если горизонтальные связи не развиты? Проявлять инициативу и пробиваться в обсуждения самим.

Помните, что хорошее маркетинговое подразделение всегда знает, что именно происходит с продуктом.

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

Agile команда — роли и организация работы в команде

Когда нужна Agile–команда?

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

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

Работа в Agile–команде

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

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

Также работа в Agile–команде характеризуется тем, что здесь нередкой ситуацией является то, что возникают новые актуальные задачи, которые требуют внимания больше, чем предыдущие. В такой ситуации команда подстраивается под новые реалии, реализуя базовый принцип: “Готовность к изменениям важнее следования первоначальному плану”.

Конечно, команды стремятся такого избегать.

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

Роли в Agile–команде

Особенностью ролевого распределения в гибкой команде разработки является то, что команда здесь является кроссфункциональной. Каждый может принимать на себя различные задачи, и готов учиться новому.

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

Тем не менее, как правило, роли все–таки выделяются.

В самом распространенном фреймворке — Scrum — таких роли три: 1) Владелец Продукта, 2) Скрам–мастер, 3) Разработчик. Это классические роли Agile–команды.

Такое распределение является важным и его имеет смысл придерживаться. Каждая роль отвечает за свой функционал: Владелец Продукта за ценность продукта, Скрам–мастер за процессы в команде, разработчик — за создание продукта.

Такое распределение позволяет членам команды сфокусироваться на своем функционале и выполнять его максимально качественно.

Нужен ли коучинг Agile–команд?

Нужен ли Agile–команде коучинг зависит от того, насколько эффективно налажены внутренние процессы в команде. Возникают ли разногласия? Как именно они решаются? Как много времени уходит на решение вопросов в команде? Связано ли это со сложностью продукта, или с качеством процессов в команде?

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

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

Что такое Agile (Аджайл) методология управления проектами

Что такое Agile

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

Agile-философия фундаментально отличается тем, что все процессы работы стараются быть максимально прозрачными, чтобы все заинтересованные стороны могли за ними наблюдать, а также внедрять ценные новые идеи как можно быстрее, а не “в новом квартале после обсуждения на квартальном совещании”.

Методология Agile строится на 12 принципах далее мы их рассмотрим.

Именно на этих agile принципах строятся agile-методы Scrum, Kanban и Scrumban рассмотренные в следующих статьях.

Основные принципы Agile-философии

Скачать для печати в .PDF

1. Давайте результат чаще (Deliver value faster)

Большой продукт/проект разбивается на небольшие кусочки, которые финалятся часто.

Пример применения этого принципа в создании корпоративного сайта:

Вместо сдачи через месяц корпоративного сайта через месяц, а потом переделывания его еще под пожелания пару месяцев, можно использовать принцип Agile так:

• Сперва делается карта сайта с основными разделами – она согласовывается с заказчиком
• Когда структура согласована – прописываются ключевые слова для разделов и пишутся идет основных статей / текстов => согласовывается с заказчиком
• Параллельно выбирается фирменный цвет (если его еще нет) и рисуется макет дизайна сайта => согласовывается с заказчиком
• Идет верстка сайта и наполнение контентом.

Таким образом вместо подхода:

1.Продали услугу по созданию сайта -> 2.Получили тех. Задание -> 3. Сдали в конце готовую работу через N недель -> 4. Переделываем М раз под хотелки заказчика

Используется подход:

1.Сделали кусочек – показали – согласовали

2.Сделали следующий кусочек работы – показали – согласовали

…

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

2.Изменения приветствуются (Welcome changes)

В отличие от классического подхода, когда в план проекта очень сложно, а иногда невозможно внести изменения, т.к. он цельный и логически законченный, в Agile можно добавлять новые «кубики» и менять приоритеты в их выполнении.

3.Выпускайте обновления продукта регулярно (Deliver working software frequently)

Главный критерий хорошего продукта – чтобы клиенты были довольны. Поэтому есть смысл регулярно собирать «хотелки» клиентов, и дорабатывать свой продукт в соответствии с ними.

Хорошим примером может служить сервис для создания сайтов – Тильда, где существует доска Trello с хотелками клиентов, и эти пожелания регулярно реализуются в виде обновлений/дополнений платформы.

Также в качестве примера можно привести сервис amoCRM, который не реже чем раз в полгода организует масштабные конференции, на которых презентует новые фишки в своем продукте.

4.Работайте сообща день за днем (Work together daily)

Часто видим в крупных компаниях, что сотрудники из разных отделом между собой не общаются и даже не знают друг друга и все взаимодействие происходит через руководителей отделов, которые часто выступают «бутылочным горлышком» в проектах.

Особенно остро эта проблема проявляется в случае болезни или отпуска, когда многие вопросы просто «подвисают в воздухе» до момента пока сотрудник не выйдет на рабочее место.

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

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

Когда мы начали внедрять agile философию, в компании появилась культура общения – в виде регулярных совещаний после каждой значительной поездки, а также еженедельные встречи, на которых обсуждались последние новости и итоги важных встреч.

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

Что делать если команда разбросана в разных странах?

И даже если они находятся на расстоянии – можно удобно организовывать онлайн-встречи с помощью таких инструментов как: групповые видео-звонки в Whatsapp/Facebook/Skype/Google Hangouts/Zoom (последние два позволяют делать еще записи онлайн-встреч).

Например некоторые компании даже доплачивают сотрудникам, чтобы они начали работать в удаленном формате.

В Agile-философии люди и их взаимодействие важнее процессов и инструкций.

5. Создавайте проекты вокруг замотивированных индивидов (Build projects around motivated individuals)

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

Если в вашем проекте по-другому – задумайтесь, а те ли люди рядом с вами?

Чтобы члены команды были действительно замотивированы на конечном резульатате, то в  они должны иметь доли акционерном капитале проекта. Но так можно сделать не всегда, поэтому зарплату делят на две части: фиксированную ставку и процент от общей прибыли проекта после запуска.

В одном из проектов с которыми мы работали, был руководитель разработки «на аутсорсе», которого пригласили акционеры в виду его былых заслуг и большого опыта.

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

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

6.Общение «лицом к лицу» (Face to face conversations)

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

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

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

7.Результаты важнее документов (Working software is a primary measure of progress)

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

В Agile проектах также есть регламенты и инструкции, но их можно и даже нужно редактировать прямо в процессе реализации проекта.

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

8. Разработка без перерывов (Sustainable development)

Так как большой проект разбивается на логически законченные «кубики»  (см. пункт 1), то разработка этих «кубиков» происходит регулярно, а если наступает момент, когда

например команда разработки завершила все задачи и ждет обратной связи от руководителя, то команда не простаивает, а переходит к разработке следующего «кубика».

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

9. Качество кода и дизайн решают (Attention to technical excellence and good design)

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

Также важное место занимают дизайн и usability продукта (удобство интерфейса для клиента)

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

10. Простота (Simplicity)

В классическом же подходе продукт часто перегружается функционалом, который придумали основатели проекта.

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

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

Есть такое выражение «The art of maximizing the work not done» дословно это можно перевести как «Искусство максимизации работы которую делать не нужно». Agile-подход создает эффективные продукты/проекты «отсекая все лишние элементы». Главные критерии отсечения – это удобство для пользователя и скорость работы.

11.Команды, которые умеют самоорганизовываться (self-organising teams)

Чтобы проект стал успешным недостаточно просто наличия мотивированных индивидов. Гораздо важнее, чтоб эти мотивированные индивиды умели объединяться в команды и уметь работать в коллективе.

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

В одном из проектов, с которыми мне довелось поработать, был очень талантливый руководитель с хорошо развитыми навыками оратора. Его талант проявлялся в способности донести свою идею и «здравость мысли» до акционеров и инвесторов. И во время таких презентаций слушатели охотно кивали головами и принимали выгодные для проекта решения.

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

Он также считал, что последнее слово даже в самых обычных операционных задачах должно оставаться за ним, и поэтому пытался удержать все процессы в своих руках, не давая свободы действий членам команды.

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

Поэтому, дружеский совет для собственников проекта и HR’ов – когда нанимаете руководителя проекта или CEO стартапа не поленитесь потратить время чтобы понять насколько он командный игрок (это лучше всего сделать с помощью испытательного срока и тестовых заданий, ориентированных на командную работу, а после тестового срока сделать личный опрос среди членов команды, насколько им было комфортно работать с этим человеком). Как вариант еще можно попросить будущего кандидата сыграть вместе с командой в деловую игру по управлению проектами (например Ферма.Project). Задача акционеров – понаблюдать за тем как человек ведет себя в команде со стороны: прислушивается ли к членам команды, дает ли положительное подкрепление сотрудникам за результаты, делегирует ли процессы и т.д.

В agile-проектах индивидуальные KPI бесполезны, вклад человека в проект оценивает команда.

12.Регулярно думайте о том, что можно улучшить в работе.

Обычно в классическом подходе управления проектами, во время релиза новой версии продукта все время и силы уходят на PR и фиксацию возникающих багов.

И совсем нет времени, чтобы собраться всей командой и задать себе вопрос «как в следующий раз сделать проект лучше?» – такие встречи называются ретроспективой (или ретро).

А те кто все же проводят ретроспективы, часто об этом сожалеют, т.к. участники превращают такие встречи в перепалки и личную брань!!!

Важные правила ретро:

– Высказываться коротко и по существу;

– Неприкосновенность личности – говорим о фактах, а не о людях;

– Уважаем себя и собеседника – не перебиваем!

– Когда озвучиваем проблему, предлагаем еще свой вариант решения.

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

Для этого как правило ищутся ответы на 3 вопроса:

1. Какие действия за период разработки «кубика» были особенно успешными.

2. Какие действия были провальными и почему.

3. Что можно улучшить в подходе к работе.

Искренность и самокритика на таких совещаниях очень поощряется.

Важное правило также: не критиковать людей, а критиковать результаты и стараться предлагать альтернативные идеи / решения.

Важные отличия Agile-подхода к управлению проектами от методологии «водопад» (waterfall)

В проектах, организуемых по методу «водопада», проект не будет сдан до тех пор, пока все требования, перечисленные в проектной документации не будут выполнены.

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

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

А когда продукт был выпущен с опозданием в 1 год, то оказалось, что он уже не такой уж и уникальный, и на рынке появилось уже более 15 конкурентов с похожими продуктами.

В Agile подходе есть очень важный принцип «деление большого на малое» и дальнейшее последовательное «зафиналивание» малых частей.

Если бы я был на месте руководителя того проекта, то

А) для начала я бы запустил рекламу веб-сайта на котором бы анонсировал альфа-версию продукта разработка которого еще не началась, там бы были собраны первые 100-500 отзывов клиентов о том, что они хотели бы видеть в альфе продукта.

Б) после этого была бы запущена разработка альфа-версии продукта с упрощенным функционалом и коротким сроком (например, 2 спринта по 2 недели на разработку и 1 неделю на тестирование)

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

Г) была бы проанализирована обратная связь от пользователей альфа-версии, в том числе сколько они готовы были бы заплатить за бету продукта с более продвинутым функционалом

Д) на основании этих данных была бы внесена корректировка в фин. модель

И только потом уже приступал бы к исследованию юридических вопросов по получению лицензий и поиска нестандтарных лазеек.

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

Выводы об Agile методологии

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

Ведь в Agile-проектах сразу становится понятно:

– кто работает неэффективно и без энтузиазма;

– кто «индивидуальный игрок» а кто командный;

– кто умеет слышать других людей и клиентов, а для кого его мнение самое важное;

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

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

В следующих статьях мы рассмотрим такие agile-методы управления проектами как Scrum, Kanban и Scrumban, которые подойдут как для управления проектами в сфере IT, так и в любых других сферах.

С уважением Александр Цыглин,
основатель Мастер Продуктивности и проекта SkillsMarketplace.ru
(Facebook / Linkedin / Instagram / Youtube)

P.S. Если вам нужна дополнительная консультация по внедрению Scrum в вашей организации – напишите мне в Facebook, обсудим чем можем быть друг другу полезны.

Что еще почитать об управлении проектами:

Обратная сторона Agile / Habr

Хочу поделиться историей, ну и заодно услышать мнения других участников хабрасообщества. Это небольшая история о том, как агрессивное внедрение методологии разработки Agile (Scrum) в отдельно взятой российской IT компании послужило началом исхода из компании лучших разработчиков. Обычно в статьях про Agile рассказывают, какая это классная и полезная методология, и вообще — это лучшее, что было придумано в этом направлении. Возможно, эта статья поможет взглянуть на Agile с другой стороны, ведь у любой монеты, как оказалось, есть две стороны.

В общем, в 2010-м году была основана одна российская компания (что-за компания конкретизировать смысла нет), работала она в сфере IT-разработки (ПО для банковских продуктов).

Как водится, поначалу всё работало практически в режиме стартапа, но, тем не менее, компания уверенно стояла на ногах и быстро себя окупила. Постепенно число сотрудников компании росло, менеджеры, фронт и веб-разработчики, вот их уже перевалило за 50 человек и открылись первые представительства за рубежом.

По мере того, как росло число непосредственно разработчиков, проект привлекал инвестиции и нанимал новый управленческий персонал; появлялись технические директора, HR-отделы, куча административного персонала и бесчисленная армия менеджеров всех мастей.

Разработчики делали своё дело, проект был отлажен до мелочей; вроде бы всё было хорошо и ничего не предвещало резких изменений. Задачи ставились и выполнялись, за пять лет состав разработчиков сильно не изменился, через 5 лет после основания компании из неё не ушел почти ни один разработчик, стоявший у истоков. А это как по мне показатель того, что людям было комфортно работать в компании.

В один прекрасный момент руководство компании решило попробовать новомодную для России методологию разработки. Был выбран Agile (Scrum), в компанию нанят скрам-мастер, все разработки были переведены в TargetProcess. С точки зрения менеджмента это было сделано для того, чтобы улучшить скорость и качество разработки, а так-же получить понимание, на что тратят время разработчики. К слову, о разработчиках. Это действительно гениальные люди, владеющие поистине не малым стеком технологий и действительно переживающие за свой проект, знающие о сути самого проекта гораздо больше, чем менеджмент.

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

Поначалу, после внедрения новомодного Скрама, все радовались его логичности и внешней простоте. Всё понятно, делим процесс разработки на спринты, получаем от менеджеров user-story (задачи что делать), включаем их в те или иные спринты, в конце спринта делаем ретроспективу (смотрим что сделали, и что пошло не так) и зацикливаем этот процесс.

Но потом всё переросло в то, что отдел разработки превратился из ядра компании, приносящего деньги, просто в инструмент, наподобие отвертки или молотка. Менеджеры придумывали задачу, скидывали в IT-отдел и ждали реализации, попутно считая время, затраченное на разработку и тестирование. Разработчикам и тестировщикам было велено списывать время на выполнение задачи в TargetProcess. Менеджмент начал конвертировать задачи во время их выполнения и естественно в стоимость. Тут, как водится, сразу возникло недопонимание между менеджментом и разработчиками. Как перенос проекта с Symfony 2.6 на Symfony 3.0 может занять почти неделю времени разработчика, ведь это просто обновление с одной версии на другую? Возможно, отдел разработки с точки зрения бизнеса всегда выглядит как ленивые сотрудники, которые хорошо, если бы смогли работать втрое, а лучше в пять раз быстрее, чтобы снизить расходы на разработку и увеличить её скорость.

С их точки зрения всё, конечно, логично: быстрее сделали – а значит, понесли меньше расходов, быстрее выполнили контракт, получили деньги и премии. Но, с точки зрения разработчиков, появилась несколько иная картина, разработчики и так были не обделены работой, работая параллельно над тремя-пятью проектами каждый, как тут появилось давление со стороны менеджмента и отчет за каждый час рабочего времени. Стали возникать вопросы в духе «почему вы потратили целый день на разработку или тестирование того-то»?

После месячного негодования страсти немного поутихли, и отдел разработки понемногу свыкся с участью «отвертки».

Разработка ПО – это такое ремесло, которое тесно связано с творчеством, одну и ту-же задачу можно сделать либо хорошо, либо подойти творчески и сделать очень-хорошо.

Тут вспоминается выступление bobuk о том, как нужно обращаться с разработчиками. Ответ: как с детьми. Я, конечно, не считаю, что так нужно обращаться со всеми подряд, но нужно учитывать, что резкое изменение правил игры в компании может понравиться не всем.

Результатом внедрения такой методологии послужило то, что энтузиазм разработчиков поутих. Стали выполняться только задачи (User Story), приходящие от менеджеров, ни на какую незаметную, но полезную деятельности времени у разработчиков оставаться не стало. Доходило до того, что при нахождении бага где-то на продакшне разработчики не могли его чинить, т.к. на это требуется задача, чтобы списывать туда время. Да и сами разработчики были завалены своими задачами. Задачам стали присваивать приоритеты. Менеджеры начали конфликтовать между собой, пытаясь присвоить своей userStory высший приоритет, т.к. у них обязательства перед заказчиками и никого не волнует занятость разработчиков.

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

Естественно, с точки зрения Менеджмента ситуация была более радужной, они получили полный отчет по времени, затраченном на разработку любого проекта, и понимание того, кто чем занимается почти в реал-тайм.

Но разработчики — тоже люди, и начали не выдерживать. Буквально за месяц компанию покинули 3 ключевых разработчика ядра. Замену которым в настоящий момент взять просто негде. Они работали в компании с самого момента основания и фактически сделали компанию тем, чем она является сейчас. Нагрузка на остальных разработчиков стала возрастать в геометрической прогрессии; отдел разработки зашатался как карточный домик, разработчики, которые работали в компании по 5 лет, стали уходить, т.к. перестали чувствовать себя частью компании, превратившись в «отвертку».

Резюме

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

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

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