Agile – эффективное управление проектами

Основные идеи и принципы

4 ключевые идеи Agile сфокусированы на гибкости и адаптивности этого подхода:

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

Эти идеи раскрываются в 12 принципах AgileManifesto[1]:

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

Extreme programming

Особенность Scrum заключается в том, что этот фреймворк уделяет мало внимания практикам разработки. Поэтому некоторые agile-компании (порядка 10%)

его с экстремальным программированием (XP).

Экстремальное программирование привлекло к себе внимание в конце 90-х. Концепция зародилась в сообществе Smalltalk, а её авторами считаются разработчики Кент Бек (Kent Beck) и Уорд Каннингем (Ward Cunningham), которые хотели сформировать новые практики в разработке ПО, сделанные для людей.

Первым проектом, созданным по методологии Extreme Programming, стала система контроля платежей Chrysler Comprehensive Compensation (C3) в середине девяностых. Сам термин «экстремальное программирование» появился в 1997 году.

Концепция строится на основании двенадцати приёмов:

1. Разработка через тестирование (Test-driven development)
2. Игра в планирование (Planning game)
3. Заказчик всегда рядом (Onsite customer)
4. Парное программирование (Pair programming)
5. Непрерывная интеграция (Continuous integration)
6. Рефакторинг (Design improvement)
7. Частые небольшие релизы (Small releases)
8. Простота проектирования (Simple design)
9. Метафора системы
10. Коллективное владение кодом (Collective code ownership)
11. Стандарт оформления кода (Coding standard)
12. 40-часовая рабочая неделя (Sustainable pace)

XP сильно напоминает Scrum и предполагает, что заказчик плотно

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

Однако Extreme Programming делает сильный упор на тестирование, что отличает её от Scrum. Методология гласит, что разработчик не может сказать, что код написан правильно до тех пор, пока не пройдут все модульные тесты. Поэтому часто XP идет рука об руку с техникой разработки Test Driven Development (TDD), когда сперва пишется тест, а затем логика для его прохождения.

Но такая «тестоориентированность» одновременно и недостаток подхода. Чтобы адаптировать XP, нужно инвестировать в создание инфраструктуры автоматизированных тестов и непрерывного развертывания ПО.

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

/ Flickr / U.S. Army / CC

Lean startup – бережливый стартап

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

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

Базовые этапы Lean Startup:

1. Построить минимально жизнеспособную версию продукта;

2. Выпустить ее и оценить метрики;

3. Сделать выводы и собрать идеи для улучшения продукта.

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

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

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

Бережливый стартап подойдет для:

• снижения рисков при запуске стартапа. Основатель Zappos не знал , готовы ли люди покупать обувь по интернету. Чтобы проверить гипотезу, он сфотографировал обувь в местных магазинах и загрузил фото на сайт. Если обувь заказывали, он покупал ее в магазине и отправлял. Теперь Zappos – большой онлайн-ретейлер обуви.

• оценки жизнеспособности нового продукта, модели, версии. Например, General Electric разработали новую модель холодильника при помощи бережливого стартапа. Они прошли 18 итераций разработки и обратной связи от пользователей перед выпуском финального продукта. 

Компании, которые используют Lean Startup: Dropbox, Zappos, General Electric, Slack, «Модульбанк».

Подробнее о применении бережливого стартапа читайте в статье «Бережливый стартап».

Scrum

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

синонимом Agile. По статистике за 2022 год,

VersionOne, Scrum используют 58% «гибких» компаний. При этом её поддерживают многие SaaS-платформы. Например, решение ServiceNow, частью которого

инструмент Agile Development.

Методология была разработана в конце 80-х — начале 90-х годов. Процесс управления состоит из фиксированных коротких итераций — спринтов (sprints).

Используя методологию Scrum, представитель заказчика плотно работает с командой разработки, расставляя приоритеты в списке требований к продукту (Product Backlog). Этот список состоит из баг-фиксов, функциональных и нефункциональных требований — из всего, что нужно сделать для реализации рабочего приложения.

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

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

За последние десять лет программисты Кен Швабер (Ken Schwaber), Майк Бидл (Mike Beedle) и Джефф Сазерленд (Jeff Sutherland) приложили множество усилий для развития Scrum. Кен Швабер — наиболее активный сторонник фреймворка, и его сайт — хорошее место, чтобы начать свое знакомство с методологией. Он также выпустил книгу.

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

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

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

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

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

Гибкость против жесткости: agilevswaterfall

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

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

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

Канбан

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

68%.

Однако сегодня многие команды рассматривают иные варианты и обращают внимание на другие методологии. Одной из них стал канбан. CTO ConvertKit Грант Аммонс (Grant Ammons) говорит, что компании сперва адаптируют Scrum, который учит их необходимым дисциплинам для разработки ПО, а затем ищут более удобную альтернативу и обращаются к канбану.

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

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

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

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

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

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

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

P.S. Еще несколько статей из нашего корпоративного блога:

Методы и средства реализации

Наиболее популярными Agile-подходами считаются Scrum (скрам) и Kanban (канбан).

В Scrum над проектом работает команда профильных технических специалистов (например, аналитик, программист, тестировщик, администратор) вместе с владельцем продукта (product owner) и модератором (scrum-мастер). Product owner аккумулирует бизнес-требования, соединяет команду исполнителей с заказчиком и следит за развитием проекта.

В Scrum рабочий процесс делится на равные периоды от 1 до 4-х недель (спринты), в зависимости от проекта и команды. Перед стартом каждого спринта на митинге формулируются его задачи, а в конце обсуждаются результаты. Краткосрочность и измеряемость спринтов позволяет эффективно управлять проектной деятельностью, не перегружая участников проекта авралами [4].

В отличие от Scrum, в команде канбан отсутствуют роли владельца продукта и модератора, а процесс разработки делится не на универсальные спринты, а на стадии выполнения задач («Планируется», «Разрабатывается», «Тестируется», «Завершено»).

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

Сегодня наблюдается некоторое слияние Scrum и Kanban, например, канбан-доски стали практически обязательным элементом популярных систем управления проектами (Jira, Trello, Битрикс.24, Basecamp, Мегаплан и т.д.), которые, в том числе, поддерживают методологию скрам [5].

Модель cynefin.

Согласно изречению Эдварда Деминга, потребитель – самый главный элемент производственного процесса.

И что? Потребитель есть разный, где-то он знает что хочет, где-то не знает. Есть производитель, который близок к своему потребителю или далек. Знает как удовлетворить потребность или не знает. Много всяких условий и контекста.

И у нас возникает определенный конфликт. Waterfalls — традиционный подход к проектам с длительным планированием или Agile — где все быстро и все меняется со скоростью света.

Товарищ Сноуден, не тот о котором можно подумать, а Дейв, в начале 2000х разработал удобную управленческую модель для работы с проектами. Эта модель успокоила фанатов традиционных способов управления проектами и сбила спеси с любителей agile. В эту модель укладывается всё, уживаются рядом и waterfalls и agile.

В модели описываются 4 вида систем с разной степенью неопределенности:

1. Упорядоченные простые

2. Упорядоченные сложные

3. Комплексные

4. Хаотичные

Упорядоченные простые.

Здесь понятны: цель, результат, ресурсы, есть опыт у команды, понятен контекст задачи.

Например: производство чего-то простого, например, мебели. Методы управления: каскадный, waterfalls.

Упорядоченные сложные.

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

Например: запуск ракеты, строительство многоквартирного дома.

Методы управления: PMBok, Prince2, PMI

Комплексные системы.

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

Пример: стартап

Методы: scrum, другие методы agile.

Хаотичные системы.

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

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

О принципах agile четко и ясно

Все основные принципы гибкой разработки изложены в одном документе – Манифесте (Agile Manifesto, 2001). Выше я уже несколько раз упоминал отдельные принципы, лежащие в методологиях объединяемых Agile.

Основные постулаты:

1. Люди и взаимодействие важнее процессов и инструментов – акцент на людях и отношениях между ними, как основном факторе успешности проекта. Люди руководят и применяют необходимые им процессы и инструменты, а не работают под управлением заранее принятого регламента. Именно поэтому agile-методики предполагают отбор в команду мотивированных профессионалов, с универсальными навыками. Тогда не потребуется внедрять изощренные методы поощрений и штрафов, люди смогут подменять другу друга, участвовать в дискуссии о продукте осознанно и эффективно. Взаимодействие между членами команды может строиться с помощью любых удобных инструментов, но не документов, регламентов и инструкций.
2. Работающий продукт важнее исчерпывающей документации – менять, адаптировать, корректировать легче то, что уже существует и работает, а не то, что подробно и исчерпывающе описано в бумагах. Сначала надо сделать что-то простое и работающее, чтобы затем, оценив и апробировав сделанное, внести коррективы или отказаться от реализованного в пользу иного варианта исполнения. Но в итоге либо продукт есть и работает (пусть и требует корректировок, дополнений и доработки), либо есть проверенная гипотеза, от которой надо отказаться. В противном случае в большинстве случаев будет реализован проект, точно соответствующий описанию на бумаге, но не соответствующий рынку, производству, и главное реальным нуждам клиента.
3. Сотрудничество с заказчиком важнее согласований условий контракта – в сложившейся реальности заказчик – а им может быть и соответствующее подразделение внутри компании – не всегда может четко сформулировать требования к продукту, зачастую у него есть только профиль клиента и проблема, с которой тот сталкивается. Заказчик может оценить реализованный продукт с точки зрения соответствия его ожиданиям, но не формализовать их. Ему легче потратить время и деньги на версии продукта, чем на всестороннее и исчерпывающее описание, причем такое описание может оказаться более дорогим, трудоемким и затратным по времени, чем гибкая разработка. Методом оптимизации в данном случае как раз и будет сотрудничество с заказчиком, вовлечение его в работу проектной команды.
4. Готовность к изменениям важнее следованию первоначальному плану – это, наверное, самый противоречивый постулат. С одной стороны легче и проще менять все по ходу реализации, с другой – процесс такой разработки может затянуться на неконтролируемое время и привести к неожидаемым результатам.

Ключевые принципы гибкой разработки, изложенные в Манифесте:

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

   На примере калькулятора для анализа проекта:

2. Изменения требований приветствуются. Разработка продукта ведется в быстроменяющейся конкурентной среде, когда по завершении цикла разработки уже может измениться рынок, например, вышел аналог. Тогда, чтобы не выкинуть в мусорную корзину реализованный проект, его дорабатывают, кстати, можно использовать опыт уже вышедшего на рынок конкурента. Поэтому в рамках гибкого подхода изменения требований продуктов даже в конце разработки – приемлемы и приветствуется.
3. Частая поставка рабочего программного продукта. Важность этого принципа все в том же – мир быстро меняется и чем короче цикл поставки, тем точнее финальный продукт будет соответствовать ожиданиям.
4. Погружение заказчика в работу над проектом на протяжении всего времени его реализации. Заказчик в этом случае является единственным участником команды, носителем знания, «как надо», соответственно его заключение о соответствии продукта ожиданиям и его удовлетворение от результата – ключевой критерий. Чем чаще ожидания заказчика сопоставляются с работой команды проекта, тем, естественно, выше соответствие ожиданий и результата.
5. Проектом занимаются мотивированные личности, которые обеспечены соответствующими условиями работы, поддержкой и доверием. Этим принципом проблемы мотивации выводятся за рамки работы над проектом. Предполагается, что на этапе формирования команды, необходимо отбирать только мотивированных профессионалов, самодостаточных личностей, которых не надо подгонять, уговаривать и т.п. Задача сведется только к созданию условий, не препятствующих реализации их потенциала в этом проекте: инструменты связи, возможности для взаимодействия, оборудование и материалы и др.
6. Рекомендуемый метод коммуникации – лицом к лицу. Это спорный принцип в цифровую эпоху, когда многие компании развивают сетевое взаимодействие и внедряют удаленную работу в свои процессы. При этом личное взаимодействие имеет ряд преимуществ, которых нет у других видов коммуникации: например, скорость решения вопросов, невербальные сигналы (эмоции, жесты), мотивация (можно похвалить, выделить, поставить «на место»). В любом случае манифест акцентирует на этом внимание и заявляет, как один из ключевых принципов.
7. Работающее программное обеспечение – лучший измеритель прогресса. Перенося этот принцип на более общую систему координат, работающая версия продукта – лучший критерий успешности и прогресса проекта. В большом числе случаев этот принцип реализуем и понятен, а там, где не применим Agile.
8. Разработчики, а также их куратор и заказчик должны быть готовы сохранять заданный темп в разработке в течение не определенного (читай – неограниченного) времени. Надо понимать, что в такой парадигме срок разработки финальной версии продукта не известен, более того, финальной версии может и не быть, что мы видим на примере постоянно шлифуемых и дорабатываемых версий десктопного программного обеспечения и мобильных приложений.
9. Краеугольным камнем Agile-разработки заявляется стремление к техническому совершенству и качеству планирования спринтов. Этот принцип призван сбалансировать возможный негативный эффект на качество разработки от других принципов, например, частой поставки рабочего продукта. Можно разными методами добиваться частой поставки в условиях отсутствия или недостатка спецификаций продукта, например, использовать готовый, но некачественный код разработанный «индийскими программистами» и пренебречь тестированием. Личные качества, профессионализм разработчиков и коллективная ответственность – заложенные в принципе «стремления к техническому совершенству» требуют более высокого уровня ответственности.
10. Простота и минимизация лишней работы. Этот принцип надо бы применять во всех проектах, но в качестве ключевого принципа он заложен только в Agile-методиках. Приоритет отдается тому, что делается быстро с минимальными затратами. Отказываемся от ненужных работ как в процессах, так и в отношении продукта, например, консалтинговая компания обычно готовит многостраничную презентацию по выполненным работам и предполагаемым шагам, но если клиент интегрирован в команду, то ему формальная бумага не нужна, ему важнее то, что уже идет в работу – те самые два-три слайда, которые уже готовы для финальной презентации. В отношении продукта – можно стремиться реализовать все задумки в отношении функционала сразу до первого релиза, однако так уже никто не делает, в каждой итерации продукт совершенствует в соответствии с требованиями рынка, что может подразумевать как добавление нового функционала, так и удаление каких-то фич, не «принятых» клиентами.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд. Речь идет не об анархии, а о высокой внутренней дисциплине в команде, четком распределении ролей и высоком уровне профессионализма каждого участника. Если вы не можете самоорганизовываться – не работайте в концепции Agile.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. Этот принцип подчеркивает, что вся полнота ответственности за проект и его продукт лежит на всех членах команды, никто со стороны не вносит корректив и не анализирует эффективность – все делают участники внутри своего коллектива в интересах проекта и результата.

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

Области применения agile

Agile в своем максимальном объеме применим и эффективен при создании продуктов, которых:

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

Таким образом, применение agile-методов оправданно в следующих сферах бизнеса:

1. Программное обеспечение для массового сегмента, в том числе мобильные приложения, игры и т.п.
2. Стартап-проекты – это идеальная почва для внедрения гибких методологий.
3. Интернет-порталы и СМИ.
4. Медицинские проекты – тело человека до сих пор в значительной мере «терра инкогнита», что создает высокую долю неопределенности в медицине.
5. Образовательные продукты и проекты. Если мы говорим о чем-то новом, а не о компиляции старых методов и практик, то образовательные проекты – стартапы на неизведанной территории, все ищут новые методы цифровой эпохи на замену старым технологиям индустриального мира.
6. Консалтинг – любой проект в этой сфере требует применения большинства принципов Agile Manifesto. McKinsey однозначно используют методику соответствующую указанным принципам.
7. Разработка финансовых и страховых продуктов (индустрия финтех), так как финансовые компании сегодня, это в большой степени ИТ-компании, а финансовый продукт уже стал в значительной степени ИТ-продуктом или применяет результаты работы ИТ-проектов/продуктов.

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

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

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

Ограничения agile

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

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

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

Легко сбиться с пути. Суть аджайла – в гибкости и возможности подстраиваться под постоянно меняющиеся условия. Иногда если обратная связь заказчика не ясна, разработчик может сфокусироваться на работе в неправильном направлении. Есть опасность впустую тратить деньги, постоянно меняя продукт.

Гибкий подход подойдет, если:

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

• вы делаете продукт, который можно выпускать частями: блог, программное обеспечение, стриминговый сервис;

• запросы пользователей и ситуация на рынке постоянно меняются.

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

Компании, которые работают по Agile: Spotify, Microsoft, Google, Netflix, Ericsson, Dell, Adobe, Accenture, WordPress, Riot Games, CH Robinson, Magna International, Scrum Alliance, Intronis, General Electric, John Deere.

Подробно о том, что такое аджайл и как он появился, читайте в нашей статье «Agile – новый Lean?».

Ограничения waterfall-модели

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

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

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

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

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

Вам подойдет каскадная модель, если:

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

• нужна детальная документация по всем процессам разработки;

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

Первый — управленец из финансового сектора.

“Мы традиционно работали по каскадной модели, начиная с 90х годов. Имеем огромную ветвистую структуру. Где по большей части общаются на уровнях, middle менеджмент с middle менеджментом, линейные сотрудники с линейными. Данная структура позволяет достичь предсказуемого результата.

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

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

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

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

Предисловие.

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

Я не журналист, который стремится показать разные точки зрения. А мудрый читатель с высокоразвитым критическим мышлением придет к своему «правильному» ответу. Поэтому, точка зрения авторская. Любые совпадения считать верными, додумки и стереотипы точными. Шутка.)

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

Преимущества и недостатки

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

Недостатки Agile являются прямым следствием его достоинств:

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

Финансовый сектор международный опыт.

“Работаю сейчас в международном проекте с полностью распределенной командой. Несколько человек в РФ, Украине, США, Доминикане. Мы работает по agile, некой адаптацией scrum. Dailly у нас превратился в weekly, длина спринта 1 месяц. Главная особенность, которую я заметил, очень большая и регулярная поставка бизнес-ценности.

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

Выводы. Все зависит от людей, а не методики. Scrum работает при условии, если вся компания этим живет. Если задача превышает 4 часа, значит, она не до конца декомпозирована”.

Добавлю свою историю. Во время работы на стыке ИТ и автобизнеса, собственник бизнеса называл меня бренд-директор, директор по развитию и т.д. А ИТ направление — product owner. Эта неопределенность позиции меня немного смущала. Все дело в том, что моя должность была точкой схождения двух методов управления.

Топ-менеджмент работал по каскадной системе, ИТ производство по agile. Скажу, что конфликтов на этой почве была масса. На 5часовых совещаниях ИТ директор под конец убегал с трясущимися руками и воплями «неучи тупые», «что я тут бисер мечу перед свиньями» или «прежде, чем сделать что-то автоматически, продумайте это логически», а управленцы других направлений сыпали “ИТшники криворукие, вся система работает через ж@ #у “. Тем не менее, компания была успешна и являлась лидером в своем сегменте. Вывод за меня озвучил мой собеседник выше.