Agile — гибкий подход к разработке программного обеспечения, когда нужно быстро реагировать на изменения, больше общаться с заказчиком и шаг за шагом улучшать продукт. Scrum — это конкретная методика, подробно описывающая, как внедрять эти принципы на практике.
Проще говоря, Agile (аджайл) — это философия и принципы гибкой работы, Scrum (скрам) — самый популярный способ их воплощения. Все команды, использующие Scrum, следуют принципам Agile, но не все, кто использует Agile, работают по Scrum — есть и другие методы, например Kanban, Lean).
Представьте себе команду, которая строит дом. Agile — это подход к строительству: когда не делают всё строго по старому плану, а часто обсуждают и улучшают, что и как будут делать дальше, чтобы в итоге построить дом именно такой, какой нужен хозяину, а не какой давным-давно начертили проектировщики.
Scrum — это один из инструментов внутри этого подхода, конкретная инструкция: как собираться, обсуждать, делить работу и следить за прогрессом.
Ключевые принципы Agile Agile строится на тесном взаимодействии между командой и заказчиком. Здесь отходят от долгосрочного, детального и негибкого планирования всего проекта на старте.
Вместо этого планирование происходит короткими циклами, а планы могут адаптироваться к изменениям. Процесс работы «по эджайлу» делится на итерации — короткие циклы по две-три недели. Каждый цикл решает серию задач. По итогам каждой итерации команда анализирует результаты и меняет приоритеты для следующего цикла.
Как правило, в agile-командах менеджеры, разработчики, дизайнеры, тестировщики и другие участники равноценны в иерархии и работают в одном пространстве.
Манифест Agile основывается на таких принципах. 📌 Люди и взаимодействие важнее процессов и инструментов. Успех проекта больше зависит от слаженной работы команды и общения, чем от строгого следования процедурам или использования самых модных программ.
📌 Работающий продукт важнее исчерпывающей документации. Лучше потратить время на создание реально работающей части продукта, которую можно показать и получить обратную связь, чем на написание объемных инструкций и отчетов.
Документация нужна, но в разумных пределах. 📌 Сотрудничество с заказчиком важнее согласования условий контракта. Важно постоянно общаться с заказчиком, понимать его ожидания и вместе искать лучшие решения, а не просто формально выполнять пункты договора.
📌 Готовность к изменениям важнее следования первоначальному плану. Мир меняется, требования клиента могут уточниться, появляются новые идеи. Agile-команды готовы к этому и умеют быстро адаптировать свои планы.
Команды, работающие по Agile, способны быстро реагировать на внешние изменения — будь то новые требования клиента уже на этапе разработки, перемены на рынке или изменения запросов аудитории. Как это выражается в Scrum Работа по Scrum устроена следующим образом.
Проект делится на короткие отрезки времени — спринты, обычно по две-три недели. За этот период команда создаёт и дорабатывает продукт, регулярно представляя клиенту рабочие версии. Например, после первого спринта появляется главная страница сайта, за второй спринт добавляются страницы услуг, затем, допустим, интегрируется онлайн-чат.
При этом уже после первого спринта «сырая» версия сайта работает. Команда Scrum состоит из трёх ролей: В Аgile-командах менеджеры, разработчики, дизайнеры, тестировщики и другие специалисты работают на равных и взаимодействуют в едином пространстве.
Все члены команды регулярно получают обратную связь от заинтересованных сторон: пользователей, заказчиков, спонсоров и других.
По завершении каждой итерации команда совместно с заказчиком оценивает полученный результат — если всё устраивает, переходят к новому этапу. На старте проекта обычно нет точного понимания итогового вида продукта: требования и задачи могут меняться по ходу работы.
Инструменты — для ведения Scrum-процессов можно использовать доски задач (Trello, Jira, Scrumban), простые таблицы или бумагу. Главное — прозрачность и простота управления задачами.
Принципы Scrum: - кросс-функциональность — команда включает специалистов всех необходимых профилей; - прозрачность — все участники видят статус задач и знают, над чем идёт работа; - постоянное улучшение — команда регулярно оценивает свою работу и вносит улучшения; - фокус на ценности — выполняются задачи, максимально полезные для заказчика и конечных пользователей.
Основные понятия в Scrum 📌 Бэклог продукта — приоритизированный список всех требований и задач к продукту.
Бэклог регулярно обновляется: новый функционал, пожелания заказчика, найденные баги. До начала спринта задачи можно изменять сколько угодно раз. В работу берётся согласованный набор задач. 📌 Диаграмма сгорания (Burndown chart) — визуальный инструмент мониторинга задач.
Она отражает объём оставшейся работы по спринту или проекту, информируя о прогрессе и отклонениях от плана. 📌 Дейли Scrum (ежедневный стендап) — короткая (до 15 минут) встреча, где участники отвечают на три вопроса: что делал вчера, что планирую сегодня, что мешает работе.
Позволяет поддерживать прозрачность, быстро выявлять проблемы и синхронизировать действия. 📌 Ретроспектива — мероприятие по итогам спринта.
Команда обсуждает, что прошло хорошо, что не получилось, какие улучшения можно внедрить для повышения эффективности в следующем цикле. Решения должны быть конкретными и выполнимыми за один спринт. 📌 Инкремент продукта — итог каждого спринта.
Это работоспособная версия продукта, готовая к показу и тестированию пользователями или заказчиком. Важно регулярно получать обратную связь и оперативно вносить изменения, чтобы не делать лишних или неактуальных доработок.
Почему Agile и Scrum популярны в ИТ Внедрение Agile-методологий за более чем двадцать лет стало массовым: если в 2002 году только 10% компаний в США использовали этот подход, то сейчас Agile там практикует уже более 70% организаций.
61% организаций — участников опроса из 76 стран отметили, что постоянно применяют Scrum. Agile со Scrum вовсю практикуют и в России. Но уровень экспертизы российских организаций по Agile уступает мировым показателям. Agile и Scrum популярны в ИТ, потому что решают проблемы, характерные для этой отрасли.
В ИТ-проектах часто меняются требования, заказчики сами не до конца понимают, каким должен быть конечный продукт, или видят новые возможности только по ходу работы.
Классические «жёсткие» методы управления (например, Waterfall, где всё продумывается заранее) не справляются с этим — они слишком негибкие и реагируют на изменения медленно. Команда и заказчик постоянно общаются, демонстрируют промежуточные результаты, что уменьшает риск создать ненужный или устаревший продукт.
Кроме того, Agile и Scrum делают процесс разработки более прозрачным — все видят, кто чем занимается, где возникли проблемы и как их устранять. Это способствует быстрой адаптации, более предсказуемому выполнению задач и дружной командной работе.
В динамичной и непредсказуемой сфере ИТ всё это стало критически важным, поэтому Agile и Scrum здесь получили широкое распространение.
Agile-подходы успешно применяют Google, Netflix, Spotify. Среди российских компаний можно выделить «Яндекс», «Сбер» и другие. Agile востребован и в других сферах, таких как научные исследования, клиентское обслуживание, маркетинг и коммуникации, управление продажами, HR, финансы и администрирование.
Agile особенно эффективен в стартапах и в условиях быстро меняющихся рынков, поскольку гибкий и итеративный подход позволяет быстро реагировать на изменения и требования клиентов.
Регулярные проверки и обратная связь помогают минимизировать риски и избегать долгих циклов доработок, характерных для традиционных моделей разработки. За что критикуют Agile и Scrum Несмотря на то что бизнес-аналитики и консультанты зачастую отождествляют идеальный Agile с гарантией стопроцентного успеха , достаточно много практикующих разработчиков высказывают критику по отношению к Scrum.
Разберёмся, что именно не устраивает тех, кто непосредственно участвует в спринтах.
🚩 Гонка за числами. На деле задачи в спринтах часто закрывают неравномерно : к дедлайну начинается спешка, и ради выполнения плана задачи помечают как завершённые, даже если осталась мелкая доработка. Или хуже — к не лучшим решениям, из-за которых страдает качество.
🚩Избыточная бюрократия. Всё чаще можно услышать, что гибкие методологии провоцируют микроменеджмент . Планирования, ретроспективы и стендапы нужны для координации, но при чрезмерном рвении менеджеров они обрастают формальностями — в итоге вместо продуктивной работы разработчики расходуют ресурсы на отчёты и обсуждения.
🚩 Субъективность оценки производительности. Одна из главных точек критики — трудности с определением реального объёма задач на спринт.
Оценки в человеко-часах или стори-пойнтах условны. Перегружать команду нельзя, но стопроцентно угадать подходящий объём заранее редко выходит. Эксперты сходятся на том, что скорость работы команды определяется только по фактическим результатам — после нескольких спринтов, и то с погрешностью: ведь никто не застрахован от отпусков, болезней, текучки, выгорания.
Излишний оптимизм при планировании создаёт стресс и снова подталкивает к авралам и фиксации на выполненных спринтах.
Многие организации, взявшие на вооружение Scrum, пришли к выводу, что его правила полезнее адаптировать под реальные потребности бизнеса. Типичный пример — компания Basecamp , где, несмотря на долгую историю внедрения Agile-практик, не стали следовать Scrum буквально, а заменили двухнедельные спринты на шестинедельные циклы (подход Shape Up).
Такой цикл лучше подошёл под их культуру — позволил снизить давление сроков и нагрузку.
В «Сбере» тоже подстроили методологию под свою особенности — так получился «Сберджайл». Кто придумал Agile и Scrum Agile возник как альтернатива традиционной каскадной модели управления (Waterfall, или «Водопад»).
В Waterfall сначала вместе с заказчиком утверждается детальное техническое задание (ТЗ), после чего разработка ведётся строго по этому плану и итоговый продукт передаётся заказчику. Любые изменения требуют возвращения к этапу согласования ТЗ, что увеличивает сроки разработки.
Со временем стало ясно, что такой подход плохо подходит к ИТ-проектам, где требования меняются очень быстро — вместе с развитием самой индустрии. Возникла потребность в подходе, который бы позволял командам эффективно реагировать на изменения.
Так родилась философия гибкого управления проектами, основные принципы которой сформулированы в Agile-манифесте в 2001 году. Именно с публикации этого документа начинается история активного распространения Agile.
Scrum как самостоятельная идея появился ещё в 1986 году в Японии — Хиротака Такэути и Икудзиро Нонака заметили эффективность работы небольших разнопрофильных команд и описали этот метод как «регби» в статье The New New Product Development Game.
Позже Кен Швабер и Джефф Сазерленд оформили Scrum в виде фреймворка , реализовав его сначала в собственных ИТ-проектах, а затем систематизировав полученный опыт. После выхода Agile-манифеста Scrum стал одной из широко признанных гибких методологий.
Почитать про Agile можно в книге «Постигая Agile» Эндрю Стеллмана и Дженнифер Грин , а также «Driving Value with Sprint Goals» . Массовое распространение удалённой работы повлияло на характер коммуникаций: Agile традиционно ценит личное взаимодействие, но в новых условиях команды вынужденно перешли к онлайн-синхронизациям.
C ростом числа встреч производительность падает, поэтому многие переходят к асинхронной коммуникации: обсуждения переносятся в письма, чаты и короткие статусы, что позволяет каждому выбрать удобное время для участия в работе, а не прерываться постоянно на совещания.
Искусственный интеллект уже сейчас помогает оптимизировать коммуникации и работу команд.
Например, ИИ анализирует записи встреч и готовит для каждого сотрудника только релевантную информацию, сокращая количество совещаний и ускоряя процессы. Также ИИ позволяет поддерживать актуальность внутренних документов, автоматически обновляя регламенты на основе протоколов и переписки.
Таким образом, гибкие методологии продолжают развиваться, подстраиваясь под современные вызовы. Эта статья — одна из тысяч в «Энциклопедии "Секрета фирмы"».
В этом проекте мы простыми словами рассказываем о сложных терминах и явлениях. Посмотрите другие статьи «Энциклопедии» , чтобы лучше понимать мир, в котором мы живём.
Рубрика: Энергетика и Бизнес. Читать весь текст на secretmag.ru.