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

Что такое Agile

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

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

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

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

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

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, обсудим чем можем быть друг другу полезны.

---

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

---