Заветная мечта из разряда «хочу летать и параллельно играть на банджо» или реальная цель постоянного достижения целей без синдрома отложенного действия. Поэтапно разберемся, как стабильно приходить из точки А в точку Б с помощью Agile-системы, наладить процесс продуктовой команды и не бояться дедлайнов.
Для начала обозначим, что же такое продуктовая команда, что ей больше нравится: хлеб, молоко или еженедельный scrum-отчет. Но сейчас без шуток. Продуктовая команда по-классике состоит из: методологии Agile, владельца продукта, продуктового scrum-мастера и разработчиков. Причём разработчиков разных спектров от программистов, дизайнеров до тестировщиков. Базовая схема продуктовой работы выглядит, как типичный велосипед: продукт-owner задаёт вектор развития, scrum-мастер фасилитирует, то есть устраняет препятствия, учит команду работать и передает задачи разработчикам на реализацию. Первоначальная цель — задать правила игры и добиться того, чтобы на первой неделе перед запуском владелец определил фокус. Особое место в этой схеме занимает методология, которая связывает всех участников команды и не даёт им рассинхронизироваться. Заветный путь из точки А в пункт Б строится на Agile-системе и её артефактах:
1. Планирование — команда собирается в кружок и планирует задачи на спринт. Зачастую Agile-методология подразумевает разбивку больших этапов на промежуточные, они как раз и формируются в недельные спринты.
2. Daily — это 15-минутные ежедневные летучки. С помощью них можно быстро закрыть текущие вопросы, проверить на каком этапе находится сотрудник и сверить общий вектор движения. Каждый участник команды в идеале должен ответить на три простых вопроса: что он сделал вчера, что он будет делать сегодня и есть ли какие-то сложности, стопорящие работу.
3. Demo — продуктовая команда подводит итог работы спринта и показывает это достояние всему миру. Решает, что нужно добавить, доработать и внести в список задач на следующий спринт.
4. Ретроспективный анализ — продуктовая команда обсуждает, что же было на спринте, как была организована внутренняя работа, насколько правильно была выбрана тема спринта, хватило ли заложенного времени и velocity (название метрики, которая обозначает скорость команды для выполнения задач в неделю — прим. автора), чтобы закрывать поставленные задачи. В этом пункте важно открыто обсуждать сложности и добиваться максимальной оптимизации деятельности и комфорта команды.
Именно это и гарантирует бесперебойность процесса или по-другому методологию Kanban — разновидность Agile, обозначающую беспрерывный процесс разработки проекта. Возьмем в качестве примера производственные принципы Toyota. Конвейер на заводах Toyota не продолжает бессмысленно нестись, зная, что в системе произошел баг. Процесс устроен таким образом, что специальная программа может его остановить, если вдруг обнаружит недочеты. Проводится анализ, который способствует лучшему пониманию проблемы и возможности ее устранения, после чего следует перезапуск линии. Toyota описывает эту последовательность следующим образом:
- Система обнаруживает проблему и сообщает о ней
- Возникает отклонение
- Конвейер останавливается
- Менеджер или инженер устраняет причину проблемы
- Анализ и доработка встраиваются в процесс
- Производится хороший продукт
Всё потому что компания не может себе позволить выпустить дефектную партию, в любом виде разработки происходит то же самое. Главное избежать простоя, когда дизайнер делает макеты и вся команда бесцельно ждёт пока он пришлет файл. Считайте спринт проигран и сразу придется откатываться на шаг назад. Бесперебойный процесс — это когда дизайнер формирует макет, передает его разработчикам, они проделывают свою часть работы и направляют результат на тестирование. Если, например, у вас недельный спринт, то в понедельник сдаётся фокус, во вторник появляется дизайн, в среду начинается программирование, в четверг начинается тестирование, в пятницу — релиз.
Все это будет ехать по рельсам при условии, что каждый член команды принимает на себя ответственность и не бьет баклуши пока в него не ткнули палкой. К счастью, Agile-методология отличный антидот от безделья. Чтобы разработчик не ждал пока продукт-owner и дизайнер нарезают задачи, существует бэклог со списком текущих дел. Вы заранее знаете, какой будет фокус на следующей неделе, чтобы в понедельник разработчики уже имели дизайн, либо знали в какую сторону копать и ресерчить.
Всё логично и не страшно? Просто мы еще не обсудили дедлайны.
Представим, что вам приходит письмо сверху: «Вы должны сделать к концу следующей недели туториалы, авторизацию, плюс ко всему интеграцию с другими сервисами и всё на серебряном блюде, пожалуйста». Система ломается именно в такие моменты паники, когда обрывается цепочка приоритетности и команда судорожно хватается за все и сразу. Самое сложное во всём этом, вытащить голову из песка, посмотреть по сторонам и переопределить приоритеты. В стрессовой ситуации очень просто загрузить команду сложными задачами и раз за разом не успевает их делать. Ощущение неизбежного судного дня может легко сбить фокус основного направления. Собственно для этого необходимо придерживаться намеченного плана, не брать больше пяти задач сразу и следовать вышеупомянутому Agile-манифесту. И да — вы можете не уложиться в дедлайн, ведь дедлайны нужны не для того, чтобы в них влезать, представляете? Они нужны для того, чтобы расставить ориентиры для команды и обозначить вектор движения проекта. Их можно расценивать не как что-то страшное и плохое, а как помощников для понимания сроков и блоков задач.
Все очевидное просто, все, что кажется простым вам аукнется, поэтому для налаживания бесперебойного процесса важно запомнить несколько аспектов:
Первый — команда не простаивает и бережно относится к ресурсам. Второй — необходима постоянная поставка релизов. Как в любом деле, важно начать и закрепиться на этапе периодичности. Тогда ситуация, что вы первый спринт поставили в пятницу, а второй поставили через месяц будет сводиться к минимуму. Третий — дедлайны должны выполнять свою ограничительную функцию, но ни в коем случае не должны мешать работе команды. Так строится принцип организации бесперебойного процесса, который способен поставить конвейер на стоп и вдумчиво разобраться с проблемой и ее следствиями. Производство ради производства — не самый лучший спутник продуктовой разработки.
Для начала обозначим, что же такое продуктовая команда, что ей больше нравится: хлеб, молоко или еженедельный scrum-отчет. Но сейчас без шуток. Продуктовая команда по-классике состоит из: методологии Agile, владельца продукта, продуктового scrum-мастера и разработчиков. Причём разработчиков разных спектров от программистов, дизайнеров до тестировщиков. Базовая схема продуктовой работы выглядит, как типичный велосипед: продукт-owner задаёт вектор развития, scrum-мастер фасилитирует, то есть устраняет препятствия, учит команду работать и передает задачи разработчикам на реализацию. Первоначальная цель — задать правила игры и добиться того, чтобы на первой неделе перед запуском владелец определил фокус. Особое место в этой схеме занимает методология, которая связывает всех участников команды и не даёт им рассинхронизироваться. Заветный путь из точки А в пункт Б строится на Agile-системе и её артефактах:
1. Планирование — команда собирается в кружок и планирует задачи на спринт. Зачастую Agile-методология подразумевает разбивку больших этапов на промежуточные, они как раз и формируются в недельные спринты.
2. Daily — это 15-минутные ежедневные летучки. С помощью них можно быстро закрыть текущие вопросы, проверить на каком этапе находится сотрудник и сверить общий вектор движения. Каждый участник команды в идеале должен ответить на три простых вопроса: что он сделал вчера, что он будет делать сегодня и есть ли какие-то сложности, стопорящие работу.
3. Demo — продуктовая команда подводит итог работы спринта и показывает это достояние всему миру. Решает, что нужно добавить, доработать и внести в список задач на следующий спринт.
4. Ретроспективный анализ — продуктовая команда обсуждает, что же было на спринте, как была организована внутренняя работа, насколько правильно была выбрана тема спринта, хватило ли заложенного времени и velocity (название метрики, которая обозначает скорость команды для выполнения задач в неделю — прим. автора), чтобы закрывать поставленные задачи. В этом пункте важно открыто обсуждать сложности и добиваться максимальной оптимизации деятельности и комфорта команды.
Именно это и гарантирует бесперебойность процесса или по-другому методологию Kanban — разновидность Agile, обозначающую беспрерывный процесс разработки проекта. Возьмем в качестве примера производственные принципы Toyota. Конвейер на заводах Toyota не продолжает бессмысленно нестись, зная, что в системе произошел баг. Процесс устроен таким образом, что специальная программа может его остановить, если вдруг обнаружит недочеты. Проводится анализ, который способствует лучшему пониманию проблемы и возможности ее устранения, после чего следует перезапуск линии. Toyota описывает эту последовательность следующим образом:
- Система обнаруживает проблему и сообщает о ней
- Возникает отклонение
- Конвейер останавливается
- Менеджер или инженер устраняет причину проблемы
- Анализ и доработка встраиваются в процесс
- Производится хороший продукт
Всё потому что компания не может себе позволить выпустить дефектную партию, в любом виде разработки происходит то же самое. Главное избежать простоя, когда дизайнер делает макеты и вся команда бесцельно ждёт пока он пришлет файл. Считайте спринт проигран и сразу придется откатываться на шаг назад. Бесперебойный процесс — это когда дизайнер формирует макет, передает его разработчикам, они проделывают свою часть работы и направляют результат на тестирование. Если, например, у вас недельный спринт, то в понедельник сдаётся фокус, во вторник появляется дизайн, в среду начинается программирование, в четверг начинается тестирование, в пятницу — релиз.
Все это будет ехать по рельсам при условии, что каждый член команды принимает на себя ответственность и не бьет баклуши пока в него не ткнули палкой. К счастью, Agile-методология отличный антидот от безделья. Чтобы разработчик не ждал пока продукт-owner и дизайнер нарезают задачи, существует бэклог со списком текущих дел. Вы заранее знаете, какой будет фокус на следующей неделе, чтобы в понедельник разработчики уже имели дизайн, либо знали в какую сторону копать и ресерчить.
Всё логично и не страшно? Просто мы еще не обсудили дедлайны.
Представим, что вам приходит письмо сверху: «Вы должны сделать к концу следующей недели туториалы, авторизацию, плюс ко всему интеграцию с другими сервисами и всё на серебряном блюде, пожалуйста». Система ломается именно в такие моменты паники, когда обрывается цепочка приоритетности и команда судорожно хватается за все и сразу. Самое сложное во всём этом, вытащить голову из песка, посмотреть по сторонам и переопределить приоритеты. В стрессовой ситуации очень просто загрузить команду сложными задачами и раз за разом не успевает их делать. Ощущение неизбежного судного дня может легко сбить фокус основного направления. Собственно для этого необходимо придерживаться намеченного плана, не брать больше пяти задач сразу и следовать вышеупомянутому Agile-манифесту. И да — вы можете не уложиться в дедлайн, ведь дедлайны нужны не для того, чтобы в них влезать, представляете? Они нужны для того, чтобы расставить ориентиры для команды и обозначить вектор движения проекта. Их можно расценивать не как что-то страшное и плохое, а как помощников для понимания сроков и блоков задач.
Все очевидное просто, все, что кажется простым вам аукнется, поэтому для налаживания бесперебойного процесса важно запомнить несколько аспектов:
Первый — команда не простаивает и бережно относится к ресурсам. Второй — необходима постоянная поставка релизов. Как в любом деле, важно начать и закрепиться на этапе периодичности. Тогда ситуация, что вы первый спринт поставили в пятницу, а второй поставили через месяц будет сводиться к минимуму. Третий — дедлайны должны выполнять свою ограничительную функцию, но ни в коем случае не должны мешать работе команды. Так строится принцип организации бесперебойного процесса, который способен поставить конвейер на стоп и вдумчиво разобраться с проблемой и ее следствиями. Производство ради производства — не самый лучший спутник продуктовой разработки.
