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

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

Scrum

1. Итерационный подход: Scrum использует фиксированные временные итерации, известные как спринты, которые обычно длительностью 1-4 недели.

2. Роли: В Scrum определены четкие роли: Scrum Master, Product Owner и Development Team.

3. События и артефакты: Включает в себя специализированные события (Daily Standups, Sprint Review, Sprint Retrospective) и артефакты (Product Backlog, Sprint Backlog).

4. Готовый продукт: Целью каждого спринта является создание "Done" продукта или инкремента.

5. Ограниченный WIP (Work In Progress): Часто количество работы, взятое на спринт, ограничено объемом, который команда может выполнить.

6. Планирование: Значительное время тратится на планирование и оценку задач перед началом каждого спринта.
Больше информации по работе менеджером продукта я пишу в своём телеграмм канале

Kanban

1. Непрерывный поток: Kanban фокусируется на непрерывном потоке работы и не имеет фиксированных итераций.

2. Роли не обязательны: В Kanban роли не строго определены или вообще отсутствуют.

3. Визуализация: Используется Kanban-доска для визуализации потока работы.

4. Ограничение WIP: Ключевой аспект Kanban — это ограничение количества работ в процессе на каждом этапе.

5. Нет фиксированного времени: Нет фиксированного времени для завершения задачи; фокус на постоянном улучшении и оптимизации.

6. Меньше формального планирования: В Kanban меньше фокуса на формальном планировании и оценке задач.

Lean

1. Эффективность и оптимизация: Lean фокусируется на устранении потерь и создании наиболее эффективных потоков работы.

2. Ценностный поток: Основной фокус на анализе ценностного потока и оптимизации процессов.

3. Принципы «pull» и «Just-In-Time»: Работа начинается только по мере необходимости и спроса.

4. Континуальное улучшение: Постоянный процесс анализа и улучшения, известный как Kaizen, является ключевым.

5. Всеобъемлющий подход: Lean можно применять не только к разработке ПО, но и к бизнес-процессам в целом.

6. Меньше уровней иерархии: Lean часто сосредоточен на децентрализации и упрощении управления.

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

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

1. Структурированность: Определенные роли, артефакты и события добавляют структуру в разработку.

2. Сосредоточенность на клиенте: Продуктовый владелец (Product Owner) уделяет особое внимание потребностям клиента.

3. Итеративность: Фиксированные спринты позволяют быстро выпускать новые версии продукта.

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

5. Постоянная интроспекция: Через Ретроспективу спринта команда анализирует, что пошло хорошо и что нужно улучшить.

1. Сложность: Много ролей, событий и артефактов могут сделать методологию сложной для новичков.

2. Негибкость: Изменения в задачах или приоритетах в середине спринта могут быть сложными.

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

1. Гибкость: Можно легко вносить изменения в рабочий процесс.

2. Простота: Новичкам обычно легче освоить Kanban по сравнению со Scrum.

3. Визуализация: Доска Kanban явно показывает, на каком этапе находится каждая задача.

4. Фокус на потоке: Ограничение WIP помогает улучшить поток работы и уменьшить время цикла.

1. Недостаток структуры: Отсутствие определенных ролей и событий может привести к хаосу.

2. Проекты с большим сроком: Kanban менее подходит для проектов с жесткими сроками или бюджетом.

3. Может игнорировать стратегические цели: Внимание к операционной эффективности может отвлекать от долгосрочных целей.

1. Эффективность: Фокус на устранении потерь и оптимизации процессов.

2. Широкий спектр применения: Может использоваться в различных отраслях и процессах, не только в разработке ПО.

3. Континуальное улучшение: Постоянный фокус на улучшении процессов.

1. Сложно внедрить: Требует глубокого понимания процессов и культуры непрерывного улучшения.

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

3. Может требовать значительных изменений: Оптимизация процессов может потребовать существенных изменений в организационной структуре.

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

Давайте разберём на конкретном примере применения в одном из продуктов, что мы имеем:

Продукт коллтрекинг с количеством клиентов ~3000, с отстающим от основных конкурентов UX/UI интерфейсе с проблемами в подсчете расходов на некоторые рекламные кампании, но с четкой целью роста выручки и генерацией новых продуктовых свойств для того, чтобы организовать экосистему Martech и росту среднего чека клиента.

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

У нас есть 100% ресурса команды, из них мы берём 60 на разработку нового функционала, который у нас отсутствует в отличии от наших конкурентов или тех продуктовых свойств, которые будут нас выгодно отличать на их фоне (главное, чтобы в них была потребность со стороны клиентов. В этом случае, весь беклог команды будет идти по методологии Scrum и визуализации Kanban, это поможет нам четко определить дедлайны и спрогнозировать результат, в команде не будет путаницы, каждый знает, что он делает в этом квартале и когда фича должна выйти на прод. Таким образом мы сможем заранее спрогнозировать когда будет реализован годовой RoadMap и когда мы сможем назвать себя Martech экосистемой или так и останемся коллтрекингом в этом году J

Далее мы берём 25% ресурса у команды на проработку отстающего UX/UI о котором говорили наши клиент и из-за чего был связан их отток. Тут также у нас есть Scrum, все фичи/доработки мы заранее оцениваем и планируем, но добавляем элементы Lean, ведь что-то может «всплыть» по ходу реализации, и это заметить не PM, а, например, fronted-разработчик и сможет оперативно внедрить.

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

По итогу мы имеем четко прогнозируемые RoadMap, знаем, когда будет релиз той или иной фичи, можем инвесторам или нашим Бизнес-Оунерам сразу сообщить о сроках и да, если их не устроит, то появляется доп., аргумент на то, что требуется больше ресурсов, и будьте добры нам их предоставить, а не «терроризируйте» и без того загруженную команду и менеджера продукта. Мы не забываем о том, что надо проработать UX/UI у нас всё под контролем. Так как у нас уже есть база клиентов, которая нас кормит, мы не допускаем увеличения churn rate и берём в проработку все баги и тех. Долг.

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

У каждого может быть свой пример, кто-то точно не согласится с моими доводами и наверное по своему будет прав, буду рад обсудить всё в телеграмм канале, там я часто публикую "выжимку" по работе менеджером продукт. До встречи в ТГ