Что такое Agile: 12 принципов agile-компании

Особенность agile-команды: в ней все равны. Нет строгого начальства, которое раздает поручения, передает ТЗ от заказчика и наказывает за ошибки. Каждый сотрудник участвует в разработке и разделяет общую ответственность за результат. Даже заказчик или его представители не выше остальных.

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

А вот какие роли есть в agile-командах, которые работают по фреймворку Scrum:

• Product Owner, или владелец продукта. Это заказчик либо его представитель. Он не принимает участие в рабочем процессе. Но так как он досконально знает продукт, то делится с командами знаниями о нем и помогает исполнителям принимать решения.
• Проект-менеджер, или тимлид. Это неформальный лидер. Связывает исполнителей и владельца продукта, передает инструкции, контролирует работу, помогает двигать проект к финалу.
• Команда разработки. Все те, кто реализует проект: маркетологи, дизайнеры, разработчики, инженеры, тестировщики. Отвечают за создание продукта, который будет соответствовать ожиданиям и требованиям заказчика.

Что такое agile-манифест?

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

Аджайл-манифест опубликован в интернете на разных языках. Любой может с ним ознакомиться

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

4 ценности манифеста — о чем речь

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

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

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

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

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

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

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

12 принципов манифеста — о чем речь

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

1. Наивысший приоритет — удовлетворение потребностей заказчика. Если заказчик доволен, команда справилась, а бизнес заработал денег.
2. Изменение приветствуется. Нельзя игнорировать полезные изменения, поскольку они могут повлиять на успех, конкуренцию и спрос продукта на рынке. Изменение надо вносить, даже если продукт почти завершен.
3. Работающий продукт следует выпускать как можно чаще. С периодичностью от пары недель до пары месяцев команда должна выпускать мини-версии продукта, а дополнительные функции, инструменты и возможности дорабатывать позже.
4. На протяжении всего проекта разработчики и представители бизнеса работают вместе. Иначе ожидания заказчика разойдутся с тем, что в итоге сделают исполнители.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, компания не должна мешать людям работать.
6. Непосредственное общение — практичный способ обмена информацией. Если можно переговорить с глазу на глаз, стоит избегать переписок, звонков и смс.
7. Работающий продукт — основной показатель прогресса. Все остальное, например отошла ли команда от первоначальной задумки или использовала нестандартные методы работы, — второстепенно.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Нельзя где-то ускоряться, где-то замедляться, иначе есть риск сорвать сроки проекта.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта. Если команда предлагает нестандартное, эффективное решение для проекта, его надо принять.
10. Простота — искусство минимизации лишней работы — крайне необходима. Бизнесу следует избегать процессов и задач, которые не несут ценности, но отнимают время и силы команды.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Над командами не должно быть строгого начальства, иначе это ограничит свободу и творчество исполнителей.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Без развития команды бизнес станет выпускать посредственные продукты и его обойдут конкуренты.

Scrum и Kanban — популярные методологии agile

Теперь о практике. Сам аджайл не подразумевает практик и инструментов. Это делают его методологии, или фреймворки. Среди популярных — Scrum и Kanban. Разберем подробно.

Scrum

Это подход к проект-менеджменту. Над проектом трудится команда спецов, среди которых:

• Product owner, или владелец продукта — представитель заказчика, сам заказчик или штатный сотрудник, который соединяет команду исполнителей с заказчиком и следит, чтобы продукт соответствовал требованиям заказчика.
• Scrum-master, или проект-менеджер — сотрудник компании, неформальный лидер команды. Планирует работу, помогает команде, обучает исполнителей, проводит встречи и принимает совместные решения.
• Все остальные. Разработчики, дизайнеры, тестировщики, которые работают над проектом.

Если команда работает по Scrum, то сначала делит проект на части, так называемые бэклоги. Затем заказчик изучает бэклоги и каждому назначает приоритет. Самые важные «кусочки» первыми отбираются для выполнения в спринте.

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

После поставки инкремента начинается новый спринт

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

В ходе каждого спринта команда встречается на летучке и рассказывает, как продвигается работа. На спринтах присутствует команда, владелец продукта и Scrum-master.

Kanban

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

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

Workflow в Kanban можно организовать в электронных веб-сервисах например Trello либо можно использовать обычную доску со стикерами

Если в одном столбике становится слишком много карточек — это проблемное место. Команда его быстро разрешает и едет дальше.

В менеджменте по Kanban есть ряд правил:

1. Все процессы выполнения проекта изображают в виде столбиков с карточками. Столбики — этапы проекта, карточки — решаемые задачи. Так нагляднее понять, где у команды затыки, на ком зависли задачи и двигается ли проект к завершению.
2. Над одной задачей одновременно трудятся все члены команды. Так все тратят одинаковые усилия, никто не страдает от повышенной нагрузки.
3. Время на выполнение задач не ограничено спринтами, но контролируется, чтобы задача не висела на исполнителях дольше чем нужно.
4. Встречи — по желанию и усмотрению команды. Можно проводить ежедневно, через день или не проводить вовсе.

Три главных закона agile-менеджмента

Американский бизнес-гуру Стивен Деннинг в своей книге «Эпоха Agile. Как умные компании меняются и достигают результатов» делает вывод, что организации, которые начали работать по agile, придерживаются трех законов:

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

А теперь рассмотрим их подробнее.

Закон микрокоманд

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

В agile-компаниях крупные задачи разбиваются на мелкие, команды автономны, но работают сообща. Изображение: Meghan Lamle для Unsplash

У микрокоманд следующие особенности:

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

Закон клиента

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

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

А вот несколько советов из книги «Эпоха Agile…» Стивена Деннинга, как соблюдать закон клиента:

1. Определите целевую аудиторию. Обозначьте основной рынок главных потребителей разрабатываемого продукта. Важно радовать людей этого рынка, а вот пытаться удовлетворить потребности всех — ошибка. Продукт получится посредственным.
2. Отдавайте часть работы на аутсорс. Не пытайтесь делать все самостоятельно. Если что-то не получается, продукт выйдет так себе, поэтому стоит доверить работу специалистам.
3. Повысьте гибкость продукта. Используйте современные программы, приложения и технологии. Их удобно перенастраивать под меняющиеся условия к разрабатываемому продукту.
4. Сконцентрируйтесь. Сосредоточьтесь на тех функциях и качествах продукта, которые важны потребителям. Не нагружайте продукт сложными функциями, которые никто не будет использовать.
5. Работайте циклами. Запустите продукт или услугу с основными функциями, которых ожидают клиенты, а дополнительные добавьте позже через ряд обновлений.
6. Оценивайте проделанную работу. Нельзя просто добавлять функции, надо проверять, несут ли они пользу клиенту, стоят ли потраченных сил.
7. Индивидуализируйте.Персонализированные продукты и услуги продаются, поскольку заточены под конкретную группу клиентов.

Закон сети

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

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

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

Как стать agile-компанией?

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

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

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

А вот если исполнители и менеджеры поддерживают и готовы работать по аджайл, бизнесу следует выбрать конкретный фреймворк, например Scrum или Kanban. Про них мы уже рассказывали.

Далее начать реорганизацию бизнес-процессов. Например, так:

• Отказаться либо уменьшить внутреннюю бюрократию. Количество отчётов, презентаций и согласований необходимо снизить, поскольку на бумажную волокиту уходит много времени и ресурсов.
• Дать коллегам больше свободы. Это касается и общения внутри коллектива — сотрудники должны иметь возможность обратиться к любому коллеге напрямую, а не через секретаря или промежуточного менеджера. Стоит также расширить полномочия и позволить исполнителям принимать решения в рамках их компетенции.
• Поменять график планерок. Устраивать их ежедневно, а не когда в рабочих процессах накопились проблемы. Сотрудники будут рассказывать про трудности и совместно их решать.
• Пересмотреть политику клиентского сервиса. Потребности заказчика должны стать главной ценностью компании, а еще необходимо допустить заказчика к работе с командой.
• Разбить коллектив на команды до 15 сотрудников. Каждая команда будет отвечать за свою часть проекта. Это ускорит общую работу.
• Не препятствовать изменениям. Не стоит придерживаться подписанного контракта, если клиент захотел чего-то нового – просто подпишите дополнительное соглашение и договоритесь по цене. Команда должна понять, что важно не следовать ТЗ, а получить хороший результат.

Подытожим

1. Agile, или аджайл — это комплекс гибких подходов и принципов по управлению проектами. Под аджайл подразумевают и философию со своей системой ценностей, и семейство гибких подходов к управлению проектами.
2. Гибкие подходы — это фреймворки, то есть практики с инструментами и правилами, которые бизнес может применять. Самые популярные фреймворки — Scrum и Kanban.
3. В agile-компаниях над проектами трудится agile-команда — группа специалистов из 7–12 человек. По компетенциям команды бывают универсальные, специализированные и гибридные.
4. Ключевые идеи движения аджайл записаны в манифесте. Всего в манифесте 4 ценности и 12 принципов.
5. Компании, которые переходят на аджайл, придерживаются трех законов: закона микрокоманды, закона клиента, закона сети.
6. Чтобы перейти на аджайл, компании надо заручиться поддержкой всех сотрудников и топ-менеджеров. Потом вводить планомерные изменения: уменьшать бюрократию, чаще проводить планерки, не зажимать сотрудников строгими регламентами и субординацией.

Высоких вам конверсий!