...немного магии и со всем разберемся. В этом материале преимущественно про SCRUM, про AGILE читать здесь, а про LEAN — в процессе написания
Сразу итог для тех, кому очень надо
SCRUM — это Agile на стероидах. Если Agile — это философия гибкости и адаптации, то Scrum — это конкретная схема действий, чтобы вся эта гибкость не превратилась в хаос. Он задаёт четкую структуру работы: короткие спринты, регулярные ретроспективы, минимальная бюрократия и максимальная эффективность. Scrum — про командную динамику, быстрые результаты и постоянное улучшение, где каждый понимает, что, зачем и почему делает. Особенно полезен там, где нужно быстро реагировать на изменения, не теряя фокус на цели.
Заклинания
Lean, Scrum и Agile — паззл из методологий и принципов управления разработкой продуктов; помогают работать более эффективно и гибко адаптироваться к изменениям, быстро выдавать годный результат пользователям не ломаясь на том самом управлении сложными многоуровневыми процессами и задачами разных команд.
Scrum — фреймворк с чётко определённой, но адаптивной структурой. Гибкий, но требует дисциплины, своего рода инструкция «Как применить красивую философию, чтобы все работало»
дает конкретные правила
способ реализовать принципы Agile и Lean через отточенные правила, практики и роли.
Agile — философия и принципы
предлагает очень софтовый подход к сложным процессам разработки
способ достичь гибкость и адаптивности к изменениям
Lean — методология,
предлагает принципы и инструменты, задает общий подход
способ минимизировать потери и повысить ценность
Scrum
Scrum возник в ответ на недостатки традиционных подходов к разработке, например к жесткому методу Waterfall. Оба развивались параллельно, но Scrum предлагает более гибкий и адаптивный подход к управлению проектами, особенно в условиях неопределенности и изменений.
Фреймворк разработан в 1990-х годах Кеном Швабером и Джеффом Сазерлендом на фоне изучения актуальных на тот момент успешных практик разработки ПО.
Очевидно, что сегодняшнее ПО и то, что было 30 лет назад — небо и земля. Тем ценнее оказывается Scrum и вся эта история. Они настолько универсальны, что и сегодня и еще через двадцать лет будут отличным инструментом, масштабируемым на любые разработки. Кен и Джефф черпали вдохновение для Scrum из Lean, Agile ну и других управленческих подходах, применяемых в производстве всего и вся. Фактически они обернули лирику в конкретику и четко ответили на вопрос: “Ну а делать-то что?”
А в чем самая основная идея разработки Scrum?
Основной идеей при разработке Scrum было создание фреймворка, который позволял бы командам адаптироваться к изменениям и быстрее реагировать на требования клиентов; помогал бы избегать всего того, чем болеют линейные методы вроде того же Waterfall, где изменения на поздних стадиях разработки обычно сложны и крайне дороги.
Ок, а чем Scrum лучше линейных методов типа Waterfall?
Основа Scrum — итеративный и инкрементальный подход. По-русски: проект разбивается на небольшие, управляемые части (спринты). Каждая итерация включает в себя разработку, тестирование и результат, успешно раскатанный на пользователя, что позволяет получать обратную связь и вносить изменения в ходе проекта. При этом Scrum держит фокус на команде, клиентах и живом контакте, линейный Waterfall основное внимание уделяет документации и процессам.
Scrum обеспечивает гибкость через циклы спринтов и возможность корректировки курса. Waterfall сосредоточен на завершении каждого этапа, стремясь завершить проект в одном цикле, что ограничивает гибкость в управлении изменениями, что удобно для менее сложных и предсказуемых проектов.
Рэгбисты и разработка
Слово Scrum изначально заимствовано из регби и обозначает тактику командного взаимодействия, когда игроки сближаются в плотную группу для борьбы за мяч. Идея заключается в том, что команда должна работать как единое целое, слаженно и в тесном сотрудничестве, чтобы достичь общей цели.
В 1986 году это понятие было введено в контексте разработки программного обеспечения Хироака Такеучи и Икуджиро Нонака в их статье «The New New Product Development Game» в журнале Harvard Business Review.
Ее даже удалось найти. Вам сюда за оригиналом
Авторы описали метод создания продуктов как процесс, похожий на регбийный scrum, где команда движется вперёд, организуясь и взаимодействуя в динамичной, самоорганизованной среде. А уже в 90-х подход был адаптирован в рамках Agile Швабером и Сазерлендом, которые разработали все еще остающиеся актуальными принципы и практики фреймворка Scrum. То есть мужики взяли годную идею да и раскатали ее так. что разработка стала основополагающей для работы бесконечно большого числа команд и проектов. Мощный вклад в человечество, надо отметить.
Артефакты и события Scrum
В Scrum Guide — официальном руководстве по Scrum указаны главные артефакты и события (artifacts и events)
События Scrum
Спринт: Рабочий период любой длительности, обычно не больше месяца. Команда работает над реализацией выбранных задач.
Планирование спринта: встреча в начале каждого спринта для выбора задач, которые команда сможет выполнить и принятия решения о том, что вообще надо делать, почему и с какой целью, да и можно ли уже вообще или что-то мешает.
Дэйлики или Daily Scrum : ежедневные мини встречи на 15 мин, где команда обсуждает прогресс, планы на день и возможные препятствия, просто трепется за жизнь. Agile же, все про коммуникацию.
Обзор спринтаи или Sprint Review: встреча в конце спринта, на которой команда демонстрирует выполненные задачи и получает обратную связь.
Ретроспектива или Sprint Retrospective — анализ прошедшего спринта для выявления улучшений в процессе работы.
Основные Артефакты
Обеспечивают прозрачность работы и являются источником информации для команды и заинтересованных сторон.
↘ Product Backlog (бэклог продукта):
Список всех функций, улучшений и исправлений, которые необходимо реализовать.
Постоянно обновляется, в идеале приоритизируется Product Owner'ом, на деле тем, кто максимально главный из тех, кто в доступе
Пример: Для интернет-магазина в бэклог могут входить такие элементы, как "Добавить фильтры для поиска товаров", "Оптимизировать корзину покупок" и "Реализовать программу лояльности".
↘ Sprint Backlog (бэклог спринта):
Часть задач из бэклога продукта, которые команда выбирает для выполнения в текущем спринте. Например, берем "Добавить фильтры для поиска товаров". Должен отвечать критериям (Definition of Ready)
↘ Инкремент продукта:
Это результат работы команды за спринт — завершённый и готовый к использованию, осязаемый, соответствующий критериям готовности функционал. Например, готовые фильтры, понятные всем тестирующим и отвечающие всем поставленным критериям и задачам.
Но всем этим как-то надо рулить, поэтому постепенно процессы SCRUM обросли новыми инструментами и артефактами из других методик и сфер. При этом так или иначе личный опыт и уровень софт-скиллов и знаний, привычек и взглядов власть имеющих в каждой команде обязательно накладывает отпечаток и видоизменяет систему под нужды команды в конкретный период времени. Тем Scrum и прекрасен - нереальная гибкость без потери функционала.
Многие дополнительные артефакты и практики, которые стали популярными в Scrum, не были изначально предложены его авторами, но оказались адаптированы сообществом, консультантами и прочей паствой.
↘ Definition of Ready (DOR)
Пример: Перед началом задачи у команды есть все нужные доступы и инструкции.
Цель: Убедиться, что задача полностью подготовлена для работы.
↘ Definition of Done (DOD)
Пример: Задача считается выполненной, если пройдены все тесты и написана документация.
Цель: Обеспечение четких критериев завершенности работы.
↘ User Stories / пользовательские истории
Пример: "Как пользователь, я хочу видеть кнопку «Поиск», чтобы быстро находить нужную информацию."
Цель: Формулировка требований с позиции пользователя.
↘ Burndown Chart / график выполнения
Пример: График, показывающий, сколько работы осталось выполнить до конца спринта.
Цель: Визуализация прогресса и оставшейся работы.
↘ Product Roadmap / план работ / дорожная карта 😏
Пример: Дорожная карта с основными фичами, которые планируется выпустить в течение года.
Цель: Долгосрочное планирование и направление развития продукта.
↘ Velocity Chart / график скорости команды
Пример: График, показывающий, сколько story points команда завершает за спринт.
Цель: Оценка производительности и прогнозирование работы.
↘ Release Backlog / задачи на релиз / бэклог релиза
Пример: Список задач, которые будут выполнены к следующему релизу.
Цель: Организация задач для конкретного релиза.
↘ Epic / Эпики
Пример: Крупная задача, вроде «Разработка системы регистрации пользователей», которая потом делится на мелкие истории.
Цель: Упрощение планирования больших функциональных блоков.
↘ Task Board / канбан / доска задач
Пример: Доска с колонками «To Do», «In Progress», «Done» для визуального контроля задач.
Цель: Отслеживание статуса задач в спринте.
↘ Product Backlog Refinement / приоритизация задач
Пример: Регулярные встречи команды для уточнения и приоритизации задач в Product Backlog.
Цель: Поддержание актуальности и готовности Product Backlog.
↘ Sprint Goal / цель спринта
Пример: Цель спринта — «завершить MVP для внутреннего тестирования».
Цель: Фокусировка команды на конкретном результате спринта.
↘ Incremental Delivery / поэтапный релиз
Пример: Каждую итерацию команда выпускает рабочую версию продукта с добавленными функциями.
Цель: Регулярные поставки ценных инкрементов продукта.
и ЕЩЕ столько же всякого добра трижды.
За что серьезные ребята любят SCRUM 😍
-
Гибкость и адаптивность:
Scrum даёт командам возможность быстро подстраиваться под изменения и оперативно менять приоритеты, если этого требуют обстоятельства. -
Прозрачность и вовлечённость:
Постоянное общение с пользователями и другими заинтересованными сторонами помогает лучше понимать их ожидания и корректировать требования по ходу работы. -
Регулярная обратная связь:
После каждого спринта команда получает обратную связь, что позволяет вносить улучшения сразу, не дожидаясь окончания проекта.
Надо ли это каждому спецу, не рвущемуся в управление?
Хотя бы базово понимать, что происходит — да. Ребята с сильными софтами, топовой самодисциплиной и навыками планирования и приоретизации, всякого рода эмпаты и люди с хорошей чуйкой могут взаимодействовать и без всех этих инструкций и разбора каждого телодвижения небольшой команды на атомы, но не все такие.
Чем больше команда, тем сложнее держать под контролем каждый этап работы со всей его детализацией, поэтому хорошо выстроенная система, обладающая максимальной гибкостью — бесценна, а уметь в ней существовать жизненно важно.
...продолжить читать про AGILE и софты здесь.
А интересные истории людей в свете их софт-скиллов в тг-канале @softskillsmonster, го читать и фоново качать свои собственные ❤
