Что такое Аджайл и Скрам — Справочная

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

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

Что такое Аджайл

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

Аджайл-коуч — специалист, который учит ценностям и помогает компаниям расти. Такого коуча можно найти в консалтинговом агентстве. Например — Unusual Concepts или Scrum Trek.

Аджайл-коуч расскажет о четырёх принципах:

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

Игорь Беляк, тимлид команды разработки интеллектуальных решений DIRECTUM:

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

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

Как применять Аджайл

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

Влада Беганова, скрам-мастер в команде разработки банка Точка:

«Мы в Точке давно уже поняли, что только счастливые сотрудники могут сделать предпринимателя счастливым. А значит — стараемся давать нашим сотрудникам всё для этого. Аджайл в этом помогает: люди самостоятельно принимают решения, понимают, к какой цели идём, сами отслеживают свой прогресс. Сама команда может встретиться с предпринимателем и получить обратную связь о своем сервисе — и это круто! Это мотивирует и вдохновляет команду. Уверены, что такой подход к работе сильно повышает личную эффективность каждого человека в компании».

Ценности и установки Аджайл выполняются, когда есть чёткие правила. Такие правила называются фреймворками. Фреймворк — каркас, на котором строится рабочий процесс. Фреймворков, позволяющих внедрить Аджайл, несколько: Скрам, Канбан, Нексус. Новичкам проще использовать Скрам: у него есть чёткий перечень правил. Рассказываем, как применять Скрам, чтобы получить результат.

Инструменты Скрама

Скрам (Scrum) — методика гибкого планирования, которая подходит для любых проектов. С её помощью можно увеличить производительность компании и достичь лучшего результата. Например, раньше на задачу команда тратила месяц, а на доработки — полмесяца. Теперь на эту же задачу уйдёт 2 недели, а доработок, скорее всего, не будет.

Распределение ролей

Скрам работает, когда есть распределение ролей. Всего их три.

Команда. Это самоорганизованная группа из 3−9 человек. Вклад отдельного сотрудника не оценивается. Важно только то, какого результата добилась команда совместными усилиями.

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

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

Бэклог продукта

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

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

Бэклог спринта

В Скраме есть понятие «спринт». Это точный отрезок времени (обычно две недели), за который команда должна у

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

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

• Что такое 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 также является типом современного SDLC. В этой статье вы познакомитесь с базовой концепцией методологии Agile, ее принципами и философией, различными приемами и способами их использования на работе. Сфера применения Agile не ограничена разработчиками программного обеспечения, но и распространяется на технических руководителей, инженеров, менеджеров по продуктам, тестировщиков и всех, кто связан с разработкой программного обеспечения. Agile процесс является гибким, быстрым и способствует непрерывной разработке и улучшению качества продукта.

Потребность в гибкой методологии

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

Что такое Agile методология?

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

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

Короткие итерации

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

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

Коммуникация, общение внутри команды

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

Обратная связь

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

Доверие

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

Согласование

Гибкая команда может быстро выровнять и настроить процесс в зависимости от необходимости. Принцип KIS или Keep It Simple — это то, чем они должны руководствоваться.

Сроки разработки гибкого программного обеспечения

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

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

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

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

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

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

Вы можете прочитать о ценностях и принципах Agile манифеста ниже:

Ценности Agile:

1. Доверяйте людям и предпочитайте взаимодействие, а не процессы и инструменты
2. Сосредоточьтесь на предоставлении рабочего программного обеспечения, а не написанию документации
3. Больше вовлечения клиентов, чем просто обсуждения условий
4. Готовность приспосабливаться к изменениям вместо того, чтобы быть жестко идти по плану

Принципы Agile:

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

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

Agile Управление проектами

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

• Сотрудничество,
• Гибкость,
• Постоянное улучшение и
  Качественные результаты.

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

Видение продукта

Резюме, которое определяет цели продукта.

Дорожная карта продукта

Общий обзор требований к реализации.

Backlog продукта

Полный список возможностей, которые будут добавлены в проект.

План выпуска

Графический документ, показывающий ход релиза.

Backlog cпринта

Список пользовательских историй, выбранных в последнем спринте.

Инкремент

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

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

Наиболее известные из них — Scrum и Kanban, поддерживающие жизненный цикл разработки Agile.

Подводя итоги

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

Где Agile ужасен, особенно Scrum / Habr

Гибкость — без сомнения хорошая вещь, и в манифесте Agile есть смысл. По сравнению с хрупкой практикой под названием «водопад», Agile заметно лучше. Тем не менее, на практике гибкие подходы часто наносят глубокий вред, и в действительности вряд ли здесь уместна дихотомия Agile/Waterfall.

Я видел, как множество вариантов Agile, называемых Scrum, реально убивают компанию. Под «убивают» я имею в виду не «ухудшение культуры», а скорее когда акции компании падают почти на 90% за два года.

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

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

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

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

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

Хорошо известно, что творческие люди теряют креативность, если их просят объясниться во время работы. То же и с программным обеспечением. Программистам часто приходится работать в условиях односторонней прозрачности. Эти системы Agile часто неправильно применяются и требуют унизительной прозрачности работы, несмотря на отсутствие взаимности. Вместо того, чтобы работать над фактическими долгосрочными проектами, которыми человек мог бы увлечься, они низведены до работы над атомизированными, функциональными «пользовательскими историями» и часто запрещают работать над улучшениями, которые не связаны с краткосрочными, непосредственными потребностями бизнеса (часто спускаемыми сверху). Этот неправильный, но распространённый вариант Agile исключает понятие собственности и расценивает программистов как взаимозаменяемые, одинаковые компоненты.

Scrum — худший вариант, с глупостью двухнедельных «итераций». Это вызывает ненужное беспокойство о микрофлуктуациях производительности человека. Нет абсолютно никаких доказательств, что такой подход действительно ускоряет или улучшает разработку в долгосрочной перспективе. Он просто заставляет людей нервничать. Многие в бизнесе думают, что это хороший подход, потому что работа «идёт быстрее». Я в IT-индустрии уже десять лет, как менеджер и как рабочая пчела. Это неправда.

1. Бизнес-ориентированная разработка.

Agile часто подают в сравнении с «водопадом». Что такое водопад?

Подход Waterfall действительно ужасен. В нём «работа катится вниз», где каждый уровень организационной иерархии выбирает то, что он считает «интересным материалом», и передаёт дальше. Проекты определяются руководителями, архитектура проектируется архитекторами, личные сроки устанавливаются менеджерами среднего звена, реализация выполняется рабочими лошадками верхнего уровня (программистами), а затем операции и тестирование передаются лошадкам нижнего уровня. Это крайне нефункциональная схема. Когда люди чувствуют, что все важные решения уже приняты, у них нет мотивации работать как можно лучше.

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

У меня смешанные мнения о названиях должностей вроде «старший» и «директор», и тому подобное. Они имеют значение, и я сам, вероятно, не приму должность ниже уровня директора, но я ненавижу их значение. Если вы посмотрите на Scrum, он специально лишает прав старших, самых способных инженеров, потому что здесь они обязаны придерживаться установленных процессов (работа только над созданными задачами, 5-10 часов в неделю на планёрках). Эти процессы спроектированы для людей, которые начали программировать месяц назад.

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

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

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

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

В конечном счёте, Agile (как практикуется) и Waterfall — формы бизнес-ориентированной разработки, и поэтому ни одна из них не подходит для разработки качественного ПО или мотивации сотрудников.

2. Подчинённое положение молодых.

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

Проблема с двухнедельными итерациями Agile (или «спринтами») и пользовательскими историями заключается в том, что нет стратегии выхода. Там нет варианта «Нам не придётся больше это делать, когда мы достигнем [X]». Предполагается, что эта система навсегда: ориентированные на бизнес митинги никогда не исчезнут. Архитектура, НИОКР и развитие продуктов уходят из работы программиста, потому что не вписываются в атомизированные «истории пользователей» и двухнедельные спринты.

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

Однажды я работал в компании, где менеджер по продуктам сказал, что разница между старшим инженером и младшим инженером — в способности давать более точные оценки по срокам. Ну, вообще-то нет. И это даже оскорбительно. Я ненавижу оценки, потому что они генерируют политики и на самом деле не делают работу быстрее или лучше (на самом деле, обычно наоборот).

Самое худшее в оценках — что они стимулируют выполнение работы, которую можно оценить. Это заставляет программистов отдавать предпочтение простым вещам низкого уровня, которые на самом деле не нужны бизнесу (даже если неуклюжие менеджеры среднего звена думают иначе), но это «безопасно». Всё, что на самом деле стóит делать, имеет ненулевой шанс неудачи и слишком много неизвестных параметров для разумной оценки сроков. Концентрация Agile на краткосрочной ценности для бизнеса в конечном итоге отталкивает людей от работы, которая действительно нужна компании, ради управления репутацией каждого программиста в режиме реального времени.

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

3. Слишком краткосрочный подход, что глупо и опасно.

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

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

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

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

4. Он не имеет никакого отношения к построению карьеры.

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

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

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

5. Цель определить низкие показатели, но при этом неприемлемо высок уровень ложноположительных результатов.

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

В дебатах о гражданских свободах часто упоминается распространённая ошибка: аргумент «нечего скрывать». Некоторые любят утверждать, что вторжение в частную жизнь, скажем, правоохранительными органами, не является проблемой, потому что они сами не преступники. Эти люди упускают несколько ключевых вещей. Например, что законы меняются. Спросите любого, кто был евреем в Центральной Европе в 1930-х годах. Даже для респектабельных людей состояние слежки — это состояние тревоги.

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

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

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

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

Часто от внедрения Agile/Scrum страдают лучшие сотрудники, потому что R&D эффективно устраняется. Одержимость краткосрочными «итерациями» или спринтами означает невозможность опробовать нечто новое, рискованное.

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

6. Пьяный эффект.

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

С точки зрения менеджера, который не знает, как работает программное обеспечение, это может показаться приемлемым компромиссом: несколько «примадонн» уровня 7+ покинут корабль под парусом Дивного Нового Scrum, зато 3-ки и 4-ки станут вполне приемлемыми 5-ками. Проблема в том, что разница между программистами 7 и 5 существенно больше, чем между 5 и 3. Если вы потеряете своих лучших людей и своих лидеров (которые необязательно находятся на руководящих ролях), то небольшое повышение уровня некомпетентных, для которых предназначен Scrum, не приносит пользы.

Scrum и Agile играют в то, что я называю предвзятостью к смене статуса. По сути, многие люди судят о своих успехах или неудачах не объективно, а исходя из субъективных изменений в статусе. Убедить программиста уровня 5 согласиться на зарплату программиста уровня 3 в стартапе (в обмен на долю в стартапе) психологически расценивается не как потеря денег, а как серьёзная прибавка в статусе.

Agile/Scrum и культура дискриминации по возрасту в целом касаются получения наиболее впечатляющей статусной прибыли, а не фактической экономической прибыли. Её можно достичь, как правило, путём найма людей, которые принесут наибольшую ценность (даже если вы предлагаете на 50% выше рыночной ставки, потому что лучшие программисты стоят в 10-30 раз больше их рыночной ставки).

Люди, которые меньше всего осведомлены о том, какой социальный статус они «должны» иметь — это молодёжь. Вы найдете 22-летнего программиста уровня 6, который думает, что у него уровень 3 и который согласится на Scrum, но 50-летний уровень 9, вероятно, знает, что у него 9 и может неохотно принять условия уровня 8,5, но точно не опустится до 3 или даже 6. Поиск статусной прибыли, конечно, бесполезен. Эти пункты ничего не значат. Вы выигрываете в бизнесе на разнице в доходах и расходах, а не на разнице в бессмысленных пунктах статуса. Может быть, существует целая индустрия в привлечении инженеров 5-го уровня, расценивая (и оплачивая) их как 4, но в нынешних рыночных условиях гораздо выгоднее нанять 8 и относиться к нему как к 8.

7. Нечестная реклама.

Здесь я сосредоточусь на Scrum. Некоторые утверждают, что Scrum является «экстремистским вариантом Agile», а другие — что это самый далёкий вариант от истинного Agile. (Возможно, здесь проявляется одна из проблем: мы не можем договориться о том, что является и не является Agile).

Решениям вроде Scrum есть своё место: очень ограниченное, временное. Нечестно говорить, что оно работает везде и на постоянной основе.

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

У этой команды не будет чёткого менеджера, поэтому вы выберете лидера (например, “Scrum Master”) и дадите ему полномочия. Вы не хотите, чтобы он был официальным «менеджером людей» (так как он должен быть максимально беспристрастным). Поскольку кризис носит краткосрочный характер, карьерные цели отдельных лиц могут быть приостановлены. Это считается «спринтом», потому что люди должны работать так быстро, как могут, чтобы решить проблему, и потому, что им будет разрешено вернуться к своей обычной работе, как только спринт закончится. Кроме того, в такой чрезвычайной ситуации вам нужно дать понять, что никто не оценивается индивидуально. Основное внимание уделяется миссии и только миссии.

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

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

Таким образом, Scrum признаёт идею, что иногда власть нужно делегировать «экстренным» руководителям: они будут делать всё, что считают необходимым, чтобы выполнить работу, оставив споры на потом. Всё нормально. Иногда всё должно быть именно так.

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

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

Agile и Scrum прославляют чрезвычайные ситуации. Это их главная проблема. Некая версия того, что индустрия видеоигр называет «шоу-тайм». Это не позволяет устойчиво работать. Агрессивный акцент на индивидуальной производительности, отсутствие заботы о карьерных целях людей при распределении работы и мандат, в соответствии с которым люди работают только на заявленный высший приоритет — всё это даёт большую пользу в краткосрочной чрезвычайной ситуации, но становится токсичным и деморализующим в долгосрочной перспективе. Люди стерпят краткосрочную потерю автономии, но только если впереди будет чёткая точка, когда они её вернут.

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

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

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

методология, команда, оценка эффективности — статьи на Skillbox

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

• Как сделать так, чтобы задержка в работе одного отдела не останавливала остальных?
• Как справиться с тем, чтобы разработка плана проекта не занимала до 30% времени от всего объема его реализации?
• Как, в конце концов, добиться того, чтобы эти планы соблюдались?

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

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

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

Главное мерило эффективности, принятое в гибкой методологии, — продукт. Пока другие только готовят документацию, agile-команды стремятся представить работоспособный прототип. Это — как в знаменитой мотивирующей формуле «сделано — это лучше, чем идеально». Реализуйте первую функцию и начните тестировать ее, создавая следующую, и так раз за разом — вот главное правило.

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

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

Agile-команда строится на принципах самоорганизации и относительного равенства всех участников. Даже человек, которого многие представляют главой проекта, product owner, на самом деле — лишь персонификация требований к продукту. Он выполняет роль носителя знаний о том, каким ожидается конечный результат, но отнюдь не является управляющим в стандартном понимании. Поскольку привычка к иерархичности трудноискоренима, во многих командах product owner’у, увы, приходится брать на себя и контролирующие функции. Но идеалом гибкой разработки является коллективная ответственность членов команды друг перед другом.

Принципы формирования agile-команд разнятся в зависимости от конкретного проекта. Например, в музыкальном сервисе Spotify они строятся вот так:

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

Важно!

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

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

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

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

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

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

Если вам удастся справиться, процессы станут заметно эффективнее, а качество работы — выше. Главное, никогда не забывайте четыре основных ценности Agile, с которых начинается «Манифест гибкой разработки»:

Следование им и поможет на этапе внедрения, и будет подспорьем в процессе работы.

Лучше познакомиться с Agile и другими современными методологиями, применяемыми от IT до медиа и маркетинга, а также погрузиться в построенные на их основе процессы, вы сможете, пройдя курс «Управление digital-проектами» от Skillbox.

Курс «Управление Digital-проектами»

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

• Живая обратная связь с преподавателями
• Неограниченный доступ к материалам курса
• Стажировка в компаниях-партнёрах
• Дипломный проект от реального заказчика
• Гарантия трудоустройства в компании-партнёры для выпускников, защитивших дипломные работы

Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой.  Часть 1

Алена Лепилина

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

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

Большой взрыв проектов

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

Обычно процессы работают в рамках каскадной модели (или waterfall model) — все происходит поэтапно и последовательно. Проще говоря, «вижу цель — иду к цели». И если в какой-то момент требования к продукту, конечной цели меняются, иногда приходится переделывать заново. Как только превосходно отточенный план сталкивается с реальностью, он сразу рассыпается в прах. Но вместо того чтобы выбросить в мусорную корзину и сам план, и свой подход к нему, руководители делают вид, будто план работает, и даже нанимают для этого специалистов. По сути, они платят людям за то, что те им лгут.

По мнению Джеффа Сазерленда, создателя Scrum, это напоминает модель поведения Политбюро ЦК КПСС в конце 1980-х годов, якобы верившему отчетам, которые оно получало накануне крушения Советского Союза.

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

Манифест Agile

Если упростить формулировки, чтобы «выкристаллизовать» соображения, которыми руководствуются все, кто работает по эджайлу, получится что-то вроде этого:

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

Как устроены процессы

Посмотрим, как можно работать по эджайлу. Для примера возьмем Scrum — сегодня это самая популярная гибкая методика. Джефф Сазерленд, автор книги «Scrum», изобрел эту методику, чтобы справиться с недостатками классического управления проектами.

1. Выберите владельца продукта — это человек, который видит, к какой цели вы идете и что хотите получить в итоге.

2. Определитесь с командой — от 3 до 10 человек, владеющих навыками, которые позволят получить результат (т.е. работоспособный продукт).

3. Выберите скрам-мастера — этот человек следит за ходом проекта и помогает команде бороться с трудностями.

4. Составьте бэклог продукта — соберите в одном месте (желательно на Agile-доске) все-все-все требования к продукту и расставьте приоритеты. Владелец продукта должен продумать и собрать все пожелания. Затем команда должна оценить бэклог, чтобы понять, возможно ли все это сделать и сколько времени потребуется.

Так выглядит agile-доска в Яндексе, — источник.

5. Запланируйте спринты — отрезки времени (неделя или две), за которые команда выполняет определенный набор задач. Спринты будут регулярными: например, 15 раз по две недели, пока получится готовый продукт.

6. Проводите ежедневные встречи на 15 минут (и ни минутой больше) — на повестке три вопроса, на которые коротко отвечает каждый: что делал вчера, что буду делать сегодня и какие преграды мешают «взять высоту».

7. Делайте обзоры — по итогам спринта команда рассказывает, что удалось сделать, и демонстрирует работоспособные части продукта. На обзоры может прийти кто угодно: владелец продукта, главный заказчик или даже потенциальные клиенты.

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

Более подробно о том, как внедрить скрам и повысить эффективность команды, читайте в этой статье.

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

Знать Agile в лицо

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

1. Минимизация рисков — это главная цель в рамках любого гибкого подхода.
2. Итеративная разработка — работа в коротких циклах.
3. Люди и коммуникация — самое важное.

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

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

• Команде на руку общение с заказчиком и коллегами (чтоб без этого: «Вы меня неправильно поняли — переделайте все быстренько. И да, это надо вчера!»), прозрачность процессов, что уменьшает шансы на неожиданности, быстрое решение проблем. Ну и многие понимают, куда девается время и где работа стопорится. Мелочь (на самом деле нет), а приятно.

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

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

Кому это может не понравиться?

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

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

Читайте продолжение:

Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 2
Что такое Agile. Гайд по гибким методологиям, или Как работать с пользой. Часть 3

P.S.  Хотите каждую неделю получать полезные советы из самых интересных книг по бизнесу и маркетингу, узнавать о новинках и получать скидки? Подписывайтесь на нашу рассылку.  В первом письме — подарок.

Ага ага, какая разница-то? / Habr

Является ли Agile аналогичным Lean? Когда люди говорят “Agile”, подразумевают ли они на самом деле Scrum? Или люди все еще используют разные типы Agile и почему?

Получая много вопросов в прошлом, я решил расставить все точки над “и”.

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

Мэри и Том Поппендик адаптировали принципы “Бережливого Производства” для разработки программного обеспечения, и я верю, что эти идеи являются основами и причинами того, как agile работает:

1. Устранение потерь.
2. Повышение качества.
3. Создание знаний.
4. Отсроченные обязательства.
5. Быстрая поставка.
6. Уважение людей.
7. Полная оптимизация.

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

Lean также делает очень сильный акцент на то, что называется “системой”, т.е. что команда работает как единое целое. Мы всегда должны смотреть на нашу работу “с высоты”, чтобы быть уверенным, что мы улучшаемся в целом. Например, много менеджеров хотят “занять” работой каждого разработчика на 100%, но в большинстве случаев это, на самом деле, контрпродуктивно. Давайте не будем заставлять людей кодировать то, что не нужно (или полностью не определено), только ради того, чтобы они кодировали, потому что в будущем для нас это создает еще больше работы.

Подводя черту, Lean говорит: уважайте людей. Это означает давать людям ту работу, которую они лучше всего знают как надо делать. Дайте им то, что им необходимо, чтобы быть эффективными и затем доверьте им сделать это. Суть программной разработки в постоянном обучении; поэтому строить работу нужно так, чтобы убеждаться, что мы постоянно учимся. И поэтому нужно откладывать принятие решения до последнего момента (ведь мы будем на тот момент знать больше). В итоге разработка идет путем создания качественного продукта, потому что нет другого способа, обеспечивающего постоянную быструю поставку, если нужно возвращаться и убирать наш беспорядок.

“Организации, которые по-настоящему следуют Lean, имеют сильное конкурентное преимущество, потому что они очень быстро и в высшей степени дисциплинированно реагируют на рыночный спрос, а не пытаются предсказывать будущее”, – Мэри Поппендик.

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

Ценности Agile – это:

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

Принципы Agile – это:

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

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

Наиболее общие это: Scrum или Kanban (или гибрид из обоих) для “Управленческих практик”. Экстремальное программирование (XP) для Технических практик (с новыми практиками становится популярным, во многом из-за Lean Statup, такие как непрерывное развертывание и тестирование на проде).

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

Благодарности: Спасибо Юрию Прокудину, Екатерине Кивелевой за помощь в подготовке текста.