Большинство владельцев бизнеса знакомы с менеджментом и управлением сотрудниками хотя бы частично, либо на подсознании.
Но что если я скажу Вам, что руководитель может всего лишь поставить перед своими сотрудниками большую задачу, а команда уже сама воплотит всё в жизнь без опозданий?
И даже самостоятельно устранит все “косяки”, выявленные в ходе действия. А что если такое будет постоянно? Классненько же? Тогда поговорим о Scrum.
Отвечая на Ваш немой вопрос о невозможности такого подхода, ведь мы же в России живем и люди тут так не работают, их только и нужно “пинать”. С уверенностью могу Вам сказать, что такое возможно (далее расскажу подробнее), но для этого в Вашей компании должно быть внедрено всего одно условие.
Та самая agile-методология (методология гибкого управления проектами), по которой должны работать сотрудники в Вашей организации.
Для примера, вспомните Сбербанк всего 5 лет назад. Хамство, ужас и постоянная ругань с бабушками. И всего 5 лет по прошествию и внедрению Германом Грефом идеологии аджайл. Сейчас Сбербанк не узнать. Конечно, осталось еще это “Где карту получали туда и идите”, но. все совершенно по-другому.
Однако вернемся к методологии скрам.
Важно. Вначале статьи мы разберём в целом, что такое методика Scrum, преимущества и недостатки, а уже потом поговорим о том, как его внедрить в обычный бизнес. Наш блог всё показывает с практической стороны.
Что это такое
Методика Scrum — это технология гибкого управления проектами. Поскольку само понятие довольно сложное, я нашел несколько расшифровывающих его определений.
И эти определения наиболее подходящие для нашего блога (объясняющие сложное простым, человеческим языком). Они же несут в себе основные принципы scrum. Итак:
- Scrum — процесс реализации проекта, используя который сотрудники могут решать проблемы, появляющиеся в ходе самой работы над проектом;
- Scrum — методология управления, которая позволяет правильно формировать имеющиеся в компании ресурсы и максимально использовать потенциал команды, для получения результата.
От себя хочу еще раз напомнить про аджайл. Если Вы помните, то agile — это не методология, это философия, придуманная 12-ю программистами. То есть общие правила, как должна работать команда и компания для получения результатов.
Scrum же это именно методология (тоже придуманная программистами, только 2-мя).
То есть набор конкретных инструкций (или если называть по-модному — мануал), действуя на основании которых Ваша компания и команда сможет развиться неимоверно.
Почему везде одни программисты? Потому что изначально agile и scrum были придуманы при создании IT-решений (разработка программ). Ведь там процессы сложные и очень долгосрочные, просто так, через “устные приказы” всё не реализовать, и система не будет работать, как часы.
Именно поэтому и сама философия, и прочие методологии (помимо Scrum, есть еще XP или каскадно-водопадные) были заложены именно ими.
Само слово “scrum” было взято из регби. Это когда спортсмены разыгрывают мяч, уперевшись головами друг в друга, направив взгляд вниз. Командная игра, где важен каждый.
Составляющие скрам
В методологии скрам разработка проекта разбивается на части, на каждый из которых выделяются определенные временные рамки.
Все это называется спринтом, по завершении которых, команда, ответственная за свою часть, должна завершить свой подпроект и отчитаться за него. Но не всё так просто, рассмотрим каждый этап.
1. Спринт
Спринт (у программистов это называется итерация) — это срок, в течении которого команда работает над проектом.
Перед началом работы над задачей, все сразу договариваются, какой продолжительности будут спринты. Обычно этот срок составляет от одной до 4-х недель. В дальнейшем срок спринта не меняется, пока не будет готов финальный продут.
К примеру, в компании Nokia срок спринтов ставился 6 месяцев. У Apple срок спринта редко превышает 3 недели. Может именно в этом успех этой компании.
Важно. Чем короче спринт, тем более гибкий процесс разработки проекта, тем быстрее получается обратная связь и тем быстрее можно найти недостатки и внести улучшения.
Перед началом каждого спринта ставится цель, которую должна достичь команда по окончании спринта. В идеале эта цель должна стать мотивирующим фактором для дальнейших спринтов и завершения всего проекта в целом.
В течении каждого “забега” проводятся ежедневные совещания (дневные спринты), на которых каждый член команды должен ответить на следующие вопросы:
- Что было сделано вчера?
- Что я должен сделать сегодня?
- Какие у меня были препятствия в работе надо проектом и как их устранить?
Главная задача дневного спринта — это понять, в какой ситуации находится команда сейчас и как она близка к завершению работы над проектом в рамках отпущенных им сроков. Длится он не более 15 минут и проводится ежедневно в одно и то же время.
После завершения спринта команда проводит спринт-митинг (совещание по итогам), это аналог большой планёрки в обычной жизни. В результате такой встречи должны появится ответы на два вопроса:
- Что мы можем сделать лучше в следующий раз/в следующем “забеге”?
- Какие были проблемы в этом спринте?
Именно ответы на эти вопросы сильно помогают улучшить эффективность работы над проектом в последующем.
Так как деятельность бизнеса не подразумевает выполнение одноразовых задач по Scrum. Обычно это повторяющиеся процессы, хотя бы близко. Но если Вы хотите делать всё по скраму, даже одноразовые задачи, то спринт-митинг Вам скорее всего уже не нужен.
2. Команда
Команда, работающая над частью проекта, состоит из семи участников (плюс-минус два человека) разноплановой направленности.
То есть в команде могут быть дизайнеры, программисты и даже продажники. Таким образом можно получить гораздо более широкий взгляд на проект и гораздо лучше применить знания каждого.
Количество связано прежде всего с тем, что для работы с большим числом участников требуются большие временные ресурсы. А меньшее количество несет опасность того, что команда (за счет меньшего количества умений) не сможет справится со своей частью проекта за спринт.
Кроме основного плюса, который можно назвать “коллективный разум”, подобная команда обладает дополнительными плюсами и их легко выделить:
- Функциональность. Как я уже писал, в команде собраны в основном люди различных специальностей.
Работа в команде даёт свои плоды. Но как Вы уже заметили, не у многих представителей малого бизнеса есть такое количество людей, и к тому же не многие бизнесы могут так легко выделить время людей на такого рода задачи.
Ведь у нас у всех и так всё под завязку, а тут ещё дополнительные встречи. Но об этом чуть позже.
ВКЛЮЧАЙТЕСЬ В СОЦСЕТИ УЖЕ 40 000+ С НАМИ
Екатерина
Сергей
Иван
Елена
Екатерина
3. Роли
А теперь самое необычное, что есть в методологии скрам, что ее отличает от многих. Это роли.
Так как в scrum нет руководителей и явных лидеров (это собственно главный принцип agile-методологии), то кто-то должен модерировать работу команды и работу над проектом в целом. И для этого в методе скрам бывают следующие роли:
- Владелец продукта;
- Скрам-мастер;
- Команда-разработки.
Если честно, когда я впервые встретил реализацию аджайл в компаниях и писал статью про аджайл, то она мне очень понравилось тем, что команда общается неформально, в ней нет лидеров и организационной структуры.
Однако, есть функции, которые должны выполняться в независимости от панибратства, у нас в России иначе никак. Поэтому давайте поговорим о каждой роли более подробно.
3.1 Владелец продукта. Важно, это не заказчик. Это человек из команды, который берет на себя его роль. Его ключевые задачи в проекте:
- Видение со стороны конечного пользователя итогового продукта;
- Решения о любых изменениях в проекте;
- Связь команды и заказчика.
3.2 Скрам-мастер. Как и в любом проекте, в скрам есть люди, которые руководят всем проектом. В нашем подходе это скрам-мастер. Его главные задачи в проекте:
- Контролирование хода всего проекта;
- Организация спринтов и совещаний;
- Выявление затыков и их устранение;
- Доработка продукта до идеального состояния.
О команде разработки мы уже говорили выше. Напомню, это разношёрстные члены компании, которые помогают выполнять и улучшать проект во время своего спринта. Больше добавить тут нечего.
Плюсы и минусы скрам
Если задуматься, то каждый подход управления проектами является своеобразным аккумулятором, в котором есть положительная и отрицательная клемма, то есть плюс и минус.
И скрам не исключение. Есть преимущества scrum перед, например, каскадно-водопадной методологией управления проектами, но есть и свои недостатки.
Разберем их, чтобы уже точно понимать, стоит ли Вам переходить на такой вид управления проектами (и не побоюсь этой фразы, Вашими сотрудниками). Или же оставить это большим компаниям, а Вам поискать что-то попроще, например, Канбан.
Преимущества
1. Отсутствие бюрократии и довольные сотрудники
Я не покривлю душой, если скажу, что мы одна из самых бюрократичных стран в мире. Этой бюрократией также страдает бизнес и его владельцы.
Они ставят на вершину пирамиды бизнес-процессов бумажки и документацию. Но что, если поставить на вершину сотрудников?
И тогда вместо злых и недовольных, которые вынуждены заполнять бумаги, Вы получите сотрудников, которые рады работать в организации, ценящей их мнение. Скрам позволяет получить таких сотрудников с легкостью.
2. Готовый идеальный продукт
Помните старый советский анекдот про “тебе шашечки или ехать?”. Если для Вас важнее получить идеальный продукт, чем документацию по его использованию, то это скрам.
Apрle до сих пор, начиная с 2007 года, работает именно в таком ключе. Им важнее выпустить совершенный новый гаджет, чем правильную инструкцию к нему.
Открою Вам секрет, но у первого iPhone, на момент его презентации Стивом Джобсом в 2007 году, не было полной инструкции и готовой технической документации. Зато был телефон, который перевернул мир. А технические инструкции доделывали уже потом в диком темпе. Но об этом никому, я обещал молчать 😉
3. Получение обратной связи и продукта, который купят (вытекает из преимущества “готовый идеальный продукт”).
Я даже не представляю, какое должно быть разочарование в душе у клиента, который через 3 года создания проекта не смог стать успешным (хотя бы окупиться). А все потому, что было слепое следование планам, без получения обратной связи в ходе действий.
То есть планы просто не меняли всё это время, потому что была цель создать продукт, который все видели в начале пути, без поправок в процессе.
4. Внутренняя обстановка
Представьте, что у Ваших сотрудников нет начальника, который ежечасно проверяет их работу, кричит на них за малейшие недочеты и постоянно их контролирует.
А все это время они занимаются тем, что по-настоящему любят. Их главная задача — не работа для галочки, а реализация наилучшим образом задачи.
Естественно, их работоспособность и вовлеченность в общий процесс / создание продукта / развитие компании (то, о чем мечтают все собственники) будет в разы выше, чем при стандартном подходе с руководителями и классической организационной структурой.
5. Экономия
Метод скрам легок в использовании и его, несмотря на заблуждения, могут использовать маленькие компании, в частности стартапы (не только IT характера), у которых нет средств на поиск и найм дорогих и высоко профессиональных руководителей.
Ведь всё, что Вам нужно, это понимание, как всё устроено и как это реализовать именно у Вас. Дорогостоящее программное обеспечение для этого не обязательно, хотя и желательно.
Недостатки
Звучит это все, конечно, круто и наверное даже фантастически. Столько плюсов! Вы поставили проект и в дальнейшем команда сама работает при минимальном контроле. Но не все так хорошо. Методология скрам имеет и свои минусы.
1. Команда
Наверное, один из самых главных плюсов и в то же время минусов. Подобрать команду — самое сложное.
Они должны не только сочетаться между собой как профессионалы, но и как обычные люди. Если нет руководителя, то это не говорит о том, что команда будет работать на 146% своего КПД.
Требуются затраты (финансовые, временные и моральные) на их сыгранность, обучение и мотивацию. А это крайне непросто и может загубить всю идею на корню.
2. Планирование
Это хорошо, если компания опытная и есть понимание, что будет на выходе и в процессе. Однако, если это делается в первый раз, то практически всегда команда ошибается в планировании.
Например, закладывая либо очень маленькие временные промежутки в спринты, либо слишком большие. То же касается и других необходимых ресурсов, ошибки есть во всём.
3. Время
Помните, что в спринтах постоянно проводятся спичи (мини-планерки)? А теперь посчитайте, сколько это времени занимает в целом проекте.
Немного напоминает ситуацию, что мы уходили-уходили от бюрократии и планерок, но в результате пришли к уменьшению их по времени, но увеличению по количеству. Итог — очень много времени уходит на обсуждения.
4. Жесткость
Она же структура методологии скрам. То есть любой проект разбивается на подчасти, которые делаются в несколько спринтов.
Всё это реализует команды, которыми руководит скрам-мастер. Иначе никак! Нет отдельных игроков, нет нарушения структуры, нет увеличения длительности спринтов в середине процесса. Всё жёстко и по плану.
Коротко о главном для малого бизнеса
Первое мнение, которое у меня сложилось: метод скрам — это только для IT-компаний. Частично это верно.
Но сколько таких компаний в числе наших читателей? Наверное 0,001%. Поэтому подведём итог, основываясь на малом бизнесе, а именно на рознице, услугах, опте и производстве.
В каких из вышеперечисленных бизнесов есть сложные и длительные проекты, для которых требуется команда из 7 человек? Скорее всего Вы скажите, что в НИ-КА-КИХ. В этом и весь смысл. Скрам подходит только в тех случаях, когда Вы создаёте что-то неопределённое, что сами до конца не понимаете. А значит и планировать дальше 2-3 месяцев не можете.
В малом бизнесе нужно использовать обычный каскадный подход (последовательный переход от одного этапа к другому).
Единственное, когда можно рассмотреть Scrum в классическом бизнесе, это когда требуется создать новый продукт, вот тогда в этом есть смысл. А во всём остальном оставьте эту идею для IT-сфер, старт-апов и очень-очень-очень сложных проектов.
Вердикт. Считаю, что для малого и среднего бизнеса шумиха над этой методологией (в том числе про agile) создана, только чтобы Вас поразить, а не чтобы увеличить результат Вам в продажах или оптимизировать работу.
Всё это модное слово, которые используют все, кто хочет отличаться. Но нам же деньги нужны, а не просто отличия, верно?!
Нашли ошибку в тексте? Выделите фрагмент и нажмите ctrl+enter
Источник: in-scale.ru
Все что нужно знать про Scrum
Что такое Scrum методология? Как ее применять в разработке и не только? Почему гибкость не всегда хороша?
Учеба продолжается, три раза в неделю я знакомлюсь с новыми знаниями из области разработки и понимания digital продуктов изнутри. Для маркетолога, это новый мир. Ты слышишь про какой-то там Agile, понимаешь, что связано это с разработкой и вполне можешь поддержать беседу в общих красках. Но как только дело доходит до деталей, “поплыл”.
Методология Scrum является самой популярной среди всего гибкого в разработке и не только. Мне стало интересно разобраться, что это такое и в чем практическое применение этого инструмента. Представляю обзор на ваш суд.
Что такое Scrum
Scrum – гибкая методология разработки или гибкий управленческий фреймворк (т.е. структура) с акцентом на качество процессов.
Суть методологии сводится к тому, что создание продукта делится на определенные части. На выполнение таких частей отводится кусок времени или спринт (обычно 2 недели). В конце каждого такого спринта необходимо проводить демонстрацию завершенного куска. Рисунок выше, это просто общий принцип процессов. Давайте разберем более подробно.
Как работает Scrum
Как Scrum устроен на самом деле смотрите ниже.
Пока это выглядит как китайская грамота, поэтому предлагаю посмотреть на отдельные части и разобрать каждый элемент структуры. Очень рекомендую книгу Бориса Вольфсана “Гибкие методологии” именно она легла в основу данного материала (часть картинок оттуда).
Структура Scrum
Давайте посмотрим из каких элементов состоит Scrum.
Роли
- Владелец продукта (product owner/manager). Ставит задачу, определяет приоритеты по задачам, взаимодействует с заказчиком.
- Скрам-мастер – человек, который отвечает за процессы внутри команды, координирует работу, следит за внутренней атмосферой. Планирует спринт, организует скрам митинг, участвует в демонстрации результатов в конце каждого спринта.
Скрам митинг – ежедневная планерка, летучка, где разбирается ход работы спринта. Что сделали, есть ли проблемы, что планируется сделать. Не более 15 минут на собрание. Все участники команды должны высказаться. Скрам-мастер следит за таймингом и выступлением каждого.
- Команда – 7±2 человек, которые реализуют требования владельца продукта.
Артефакты
- Беклог продукта. Список требований с расставленными приоритетами и трудозатратами.
- Беклог спринта. Часть беклога спринта, то есть несколько задач, которые реально уместить в один спринт.
- Инкремент продукта. Готовая часть продукта для демонстрации. В digital проектах, это может быть функциональность. К примеру, рабочая форма регистрации на сайте, которую можно показать.
Процессы
- Планирование спринта. Команда со скрам-мастером планирует план работ на будущий спринт, то есть составляет беклог спринта (список) задач.
- Обзор спринта. Демонстрация инкремента продукта после каждого спринта. Команда показывает рабочую функциональность владельцу продукта (и заказчику по запросу), а тот, в свою очередь, вносит изменения в требования, если они необходимы.
- Ретроспектива. Обзор прошедшего спринта с целью улучшения процессов. Команда, скрам-мастер и владелец продукта обсуждают прошедший спринт, делают выводы, думают над тем, что можно было бы улучшить.
- Скрам митинг. (см.определение выше в блоке “Роли”)
- Спринт. Как правило двухнедельный этап времени, в течении которого команда успевает разработать готовый для демонстрации функционал.
Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…
Пример Scrum
Представьте себе, что вам необходимо создать сайт/сервис по уборке на своих дачных участках. У вас есть загородный дом, где на участке творится полный швах, а тратить свои выходные на уборку, не представляется возможности, ведь хочется и отдохнуть немного. Поэтому, вуаля, сервис Уберимойдвор!
Мы считаем, что сервис будет базироваться на сайте. Пользователь регистрируется, оставляет заявку и ему перезванивает оператор, который уточняет детали и договаривается об удобном для клиента времени. Для разработки сайта мы хотим применить Scrum.
Выбираем, для примера, важную задачу или историю пользователя (user story) в рамках создания сайта: “Регистрация клиента/пользователя”. И раскладываем ее на более мелкие части. Формируем беклог продукта.
Основная история пользователя раскладывается на мелкие задачи. Далее уже совместно с командой расставляются приоритеты и делятся задачи по спринтам. Не забываем про основное правило, после спринта у нас должна быть готовая функциональность для демонстрации.
На практике, историй пользователя (типа “Регистрация пользователя”) гораздо больше. Сервис/продукт может включать множество таких историй, поэтому приоритезация строится сверху вниз, слева направо. В верхней левой части располагаются самые важные user story (Активность) и самые важные задачи.
Для отображения беклога задач используются обычные стикеры, доска (иногда даже стена). Вот как это может выглядеть.
Понятно, что управлять такой “махиной” в реальном времени просто невозможно, поэтому для удобства работы, вся эта стена переезжает в специальный софт/программу (Jira, Trello, Redmine и прочие трекеры управления проектами). Там вы можете назначать ответственных за задачи и исполнителей, изменять статусы задач и прочее.
Стена работает тоже хорошо, так как на этапе создания вся команда увлечена и чувствует свой вклад в общее дело. Но после ее нужно перенести в подходящий инструмент.
Вернемся к уборке двора. Вот мы выбрали спринты с задачами и преступили к работе. Команда каждый день выполняет объем работ, а скрам-мастер организует 15 минутные планерки (скрам митинги), где обновляет статус задач спринта и выясняет трудности в работе, если они возникли.
Очень важно, чтобы скрам-мастер следил за климатом и отношениями внутри команды, его задача сформировать и поддерживать самоорганизующуюся мотивированную команду. Для этого необходимо решать вопросы и недопонимания между всеми участниками. Скрам-мастер, это тренер, который улучшает команду.
После 2-х недельного спринта скрам-мастер и команда проводит демонстрацию функционала. В нашем примере, мы успели сделать форму регистрации и показываем ее владельцу продукта. Он смотрит и вносит корректировки, если требуется. После принятия работы переходим к следующему спринту.
Ретроспектива: анализ спринта
Через несколько дней после завершения спринта владелец продукта, скрам-мастер и команда должны собраться и провести ретроспективу (обзор спринта). Это собрание на несколько часов (в зависимости от продолжительности спринта и размеров команды), где разбираются сложности, которые возникли в последнем спринте.
Участники делятся мнениями и решают, что можно улучшить в будущих спринтах. Таким образом, идет естественная эволюция процессов, так как с каждой новой итерацией учитывается и разбирается предыдущий опыт.
Как расставлять приоритеты
Хорошо, что мы применяем Scrum управление, но как расставить приоритеты в огромном списке историй пользователя? Ведь проект может включать в себя уйму таких историй.
Для этого и нужен владелец продукта. Именно он понимает потребности аудитории, мониторит рынок и делает выводы, что за чем должно выполняться в беклоге. Главная задача, это решить потребность клиента и начать лучше с самой важной.
В тоже время необходимо учесть возможности команды. Сколько задач она способна решить за спринт? Какого рода эти задачи? Как планировать общий ход выполнения? Поможет оценка внутри беклога.
Оценка историй пользователей внутри беклога
Мы сформировали беклог, но как оценить истории пользователя с точки зрения сложности? Для этого используется метод эталона. Это относительная оценка, которая позволяет понять потенциал команды и приблизительно оценить ресурсы.
Мы берем одну user story из беклога за образец и присваиваем ей ценность единицу (story point). Дальше оцениваем другие истории пользователя с точки зрения выбранной.
Например, в нашем сервисе есть история пользователя “Регистрация пользователя”. Мы берем ее за образец и даем ценность в один бал или один story point (так его называют в гибких методологиях). Каждый участник команды пишет свою оценку к остальным историям пользователя в списке с учетом задачи, которую взяли за образец и отдает ее скрам-мастеру.
В примере выше “Фото галерея с довольными клиентами” стоит 0,5 story point, то есть по сложности она в 2 раза меньше нашей эталонной истории “Регистрация пользователя”. Все оценки участники команды ставят анонимно, можно на стикерах писать и переворачивать.
Когда все проставили оценки, результаты открываются. Скрам-мастер организует обсуждение между участниками, которые поставили самые крайние оценки. На рисунке выше, это 2 и 8. Они договариваются между собой и запускается второй раунд голосования.
Все участники должны прийти к общему мнению и оценки выравниваются. В итоге мы получаем разбивку по всем историям пользователей с учетом относительной оценки.
Далее с учетом приоритетов задачи набираются в спринты и начинается работа. По итогам завершенных спринтов становится понятно, сколько story point-ов приблизительно может выполнить команда. А в процессе разбора (ретроспективы) после могут найтись точки роста.
Таким образом, мы получаем внутренний измеритель или валюту, которую получает команда за спринт. По ней можно мерить эффективность команды и прогнозировать будущие итерации.
Можно ли применять Scrum не только в разработке
И да и нет. До того, как я начал понимать, что означают эти 5 букв (Scrum), часть принципов уже использовал в работе. Планирование, с помощью различных инструментов и выстраивание своего так называемого “спринта задач” уже было.
Но все же это не Scrum. Scrum, это методология и система, которая позволяет быть гибким и постоянно улучшать процессы внутри команды.
Задачи должны быть типовыми. Как ни крути, разработка, это инженерная практика, то есть задача может быть приведена к некоему стандарту. И сделать это гораздо проще, чем, скажем, в области креатива, маркетинга или управления.
Отдельные практики из методологии вполне себе применимы в других областях. Работа с командой и анализ проделанной работы, да. Прогнозирование задач на этапе времени, да. Управление задачами, в удобных программах, тоже да.
Когда применять Scrum
В основном в небольших проектах и старт-апах. Можно и в больших, типа Mail.ru, но там должна быть определенная свобода действий и отдельные функциональные команды со своим владельцем продукта. Не забывайте, что Scrum про гибкость и изменения. Команды не должны быть больше 7±2 человек, иначе невозможно будет эффективно организовать коммуникации.
Нюансы
Если вы решили внедрить Scrum у себя в проектах, то учитываете следующие нюансы:
- Нет ориентации на клиента. Не все заказчики будут готовы к определенным стандартам Scrum.
- Не учитывается система реагирования на риски. Команда может заложить какое-то доп.время на выполнение задач, но при сильных отклонениях от плана, система встанет.
- Команда и человеческие качества. Так как упор сделан на самоорганизующуюся команду, то все участники должны обладать высоким уровнем ответственности и соответствующей мотивацией. Создание такой команды, очень сложная задача.
- Скрам-мастер. Человек отвечающий за процессы и мотивацию команды, должен чувствовать всех участников и связи внутри группы. Это редкий специалист, которого также тяжело найти на рынке.
Завершим
Несмотря на нюансы и особенности методов Scrum, хочется отметить, что он все еще остается самым популярным среди всех гибких методологий. Отдельные его части можно применять в других сферах бизнеса, а принципы могут лечь в основу вашей собственной стратегии развития.
- Agile управление или как построить гибкий бизнес?
- Не нужно все сразу, начните с MVP
Кстати, я уже давно веду авторские семинары по управлению IT продуктами, если интересно, посмотреть их можно тут.
Источник: www.alexcouncil.com
Что такое SCRUM и кому он подходит в 2023 году
Пришла пора разобраться со Scrum — самой популярной методикой гибкого управления, которая идеально подходит для ситуаций, когда ещё не понятно, каким будет продукт, но делать уже что-то надо.
Содержание:
Всё больше команд задумываются о гибких методологиях и методиках, потому что каскадная модель, с теми или иными изменениями, вносит слишком много ограничений. Окружающие условия часто меняются, и под эти изменения нужно уметь подстраиваться. Правда, с Agile есть проблема — на него очень сложно перейти, это целая философия, подразумевающая глобальное изменение мышления команды. Но если очень хочется попробовать гибкое управление, то отлично подойдёт Scrum методология. Он основан на принципах Agile, но перейти на него проще и быстрее.
Откуда возник Scrum
В 1986 году в статье для Harvard Business Review японские учёные Икуджиро Нонака и Хиротака Такеучи рассказали, что проекты с небольшими командами из разнопрофильных специалистов систематически приносят лучшие результаты. Они назвали это «подходом регби». В 1991 году в книге «Нечестивые проблемы, праведные решения» подход впервые называют регбийным термином «scrum».
Но Scrum в более-менее том виде, что мы знаем сейчас, появился позже — в 1995 году Кен Швабер и Джеф Сазерленд впервые представили методику на конференции OOPSLA. В течение следующих лет они продолжали работать над Scrum. Сейчас это детальнейше описанная методика, по которой есть и своё собственное руководство (The Scrum Guide), и куча книг, и даже пара аккредитующих компаний: Scrum Alliance и Scrum.org.
В чём идея Scrum
Scrum — это методика или фреймворк управления разработкой. Чаще всего её применяют именно в разработке, но использовать её можно в любой командной работе. Scrum управление проектами представляет собой набор рекомендаций по организации рабочих процессов, без каких-то пошаговых инструкций. Набор рекомендаций очень жёсткий — если что-то случайно или намеренно упустить, это уже будет не Scrum.
Согласно Scrum, над проектом должна работать небольшая команда от 3 до 9 человек. Если у тебя команда больше, придётся её разбить на несколько небольших. Команда работает непрерывно, короткими итерациями – спринтами продолжительностью по 1–4 недели. В конце каждого спринта команда должна создать что-то ценное для заказчика. Работа не просто разбивается на итерации, а каждая итерация должна иметь смысл и приносить пользу.
Как работает Scrum
Для начала ответим на вопрос, как расшифровывается Scrum. От английского Scrum – это схватка или элемент игры в регби. Если смотреть глубже, то в Scrum кроме итеративного подхода есть ещё специфические сущности: событий, ролей и артефактов. Точно так же, как в спортивной игре участником необходимо следовать определенному порядку. Ниже об этом.
Роли
Итак, над проектом работает так называемая scrum-команда. Она состоит из разработчиков, а также маркетологов, дизайнеров и любых других специалистов, которые нужны в проекте, и других людей, которые берут на себя особые роли: владельца продукта – Product Owner и scrum-мастера.
Владелец продукта отвечает за общий список задач (бэклог продукта) и согласованность работы команды, взаимодействует с заказчиком и определяет требования. И хотя команда может высказывать своё мнение по тем или иным вопросам, именно владелец продукта принимает все решения, определяет приоритетность задач, даёт советы и т. д. Владелец продукта всегда один, чтобы не возникал хаос из-за противоречащих друг другу указаний.
Scrum-мастер — эдакий гуру Scrum и сердце этого инструмента. Он лучше всех знает методику, обучает тонкостям процессов остальных участников команды и отвечает за соблюдение командой scrum-правил. Как и владелец продукта, scrum-мастер старается добиться максимальность продуктивности команды.
Команда отвечает за реализацию задач из бэклога спринта. Крутая scrum-команда сама определяет, какие задачи как именно нужно делать в рамках спринта, чтобы его ценность была выше. Как водится в Agile, участники команды делятся друг с другом своими знаниями, чтобы можно было снизить вероятность чьих-то ошибок. Совместно с владельцем продукта команда создаёт план работ на каждый спринт.
Артефакты
Ещё в Scrum есть три сущности, называемые артефактами:
События
В основе Scrum лежат спринты, но с ними связано ещё несколько важных событий, без которых Scrum не Scrum. Всё начинается с создания бэклога. Владелец продукта общается с заказчиком и командой, собирает список требований к продукту, а затем, на его основе, составляет список задач.
Этот список задач нужно где-то хранить, и обычно для этого отлично подходит система управления проектами с возможностью создания канбан-досок. Например, WEEEK. Разберём подробнее.
Канбан-доска – это инструмент для визуализации процесса работы, который даёт возможность командам управлять и оптимизировать свои процессы.
В WEEEK канбан-доски привязаны к проектам. Чтобы создать канбан-доску грамотно, разбей процесс на этапы и присвой название каждого этапа колонке в доске. Например, процесс работы SMM-агентства будет состоять из таких этапов:
После того, как прописаны все этапы, необходимо собрать все задачи. Когда понятен общий пул задач, команда собирается со scrum-мастером и планирует спринт — ставит цели и решает, какие задачи из бэклога помогут их достичь:
Спринт – это ограниченная по времени итерация непрерывного цикла работы. Как писал выше, средняя продолжительность от недели до двух. В рамках спринта команда должна выполнить запланированный объем.
В течение спринта каждый день участники команды проводят небольшие совещания – стендапы, на которых рассказывают, что сделали вчера, что собираются сделать сегодня и что может помешать. Длительность стендапа для всей команды должна быть не дольше 15-20 минут. Иначе это может привратиться в бюрактические совещания, которые будут только отнимать время, но не нести никакой ценности для команды. С помощью стендапов вы с командой сможете повысить прозрачности, которая будет помогать своевременно обнаружить любую проблему.
Когда спринт заканчивается, вся команда, включая scrum-мастера и владельца продукта, проводит обзор спринта — изучает результаты и дорабатывает бэклог.
После обзора спринта команда проводит ретроспективу — разбирается с тем, что получилось, а что пошло не так, и думает, что можно улучшить в следующем спринте. Без негатива, с реальным желанием что-то изменить.
На основе обзора вы с командой можете изменить и организационную часть работы по Scrum-методологии. Например сократить длительность спринта или увеличить её. Обсудить формат проведения спринтов. Поделиться обратной связью по вовлечению каждого сотрудника в спринт и так далее.
Плюсы и минусы Scrum
Управление проектом по Scrum со всеми этими ежедневными стендапами со стороны выглядит, как тотальный контроль, но у методики есть и свои плюсы:
- минимум лишней бюрократии и ненужной документации;
- методику можно переложить на опыт разных компаний, главное – разбиться на небольшие команды
- к сотрудникам прислушиваются, поэтому они довольны и мотивированы;
- заказчик получит продукт, который понравится аудитории, ведь он разработан с учётом обратной связи.
Правда минусов тоже немало. Кроме проблем с тщательным следованием всем ритуалам –создание бэклога, митинги и т. д., есть ещё:
- в scrum-команду нужны профессионалы, а собрать из них сплочённую команду, даже небольшую, бывает сложновато;
- не у всех есть опыт работы по Scrum — на их обучение нужно потратить время и деньги;
- несмотря на всю щепетильность, с которой, кажется, scrum-команда подходит к планированию, избежать ошибок в нём очень сложно.
Кому подходит Scrum
Сейчас Scrum распространился за пределы разработки ПО — его используют и в маркетинге, и в бизнесе, и в образовании, и много где ещё. Проще всего очертить границы применения Scrum на уровне целей. Scrum можно применять для разработки продуктов и регулярных его обновлений, а также поиска новых решений и технологий. Причём не только в работе, но и в личных делах. Даже приготовление борща можно организовать по Scrum.
Сейчас Scrum распространился за пределы разработки ПО — его используют и в маркетинге, и в бизнесе, и в образовании, и много где ещё.
Что такое Scrum простыми словами? По сути, любой рабочий процесс можно переложить на канбан-доску. Вопрос в целях. Scrum можно применять:
- 1. Для разработки продуктов и регулярных его обновлений.
- 2. Для выстраивания процесса создания контента.
- 3. Для поиска новых решений и технологий – для брейншторма.
- 4. Для работы с клиентами и партнёрами.
- 5. Для организации мероприятий.
- 6. Для редакции блога и сайта компании и любых других процессов, где есть возможность разбивки на этапы.
Даже приготовление борща можно организовать по Scrum!
Другие полезные материалы на эту тему:
- 1. Agile и Scrum для работы в Digital агентстве
- 2. Как ежедневные стендапы помогают в управлении командой
- 3. Как стартапу оптимизировать процесс при создании продукта: Agile, SCRUM, канбан-доски
- 4. В чём суть Канбан-метода
- 5. Как создать успешный продукт или истории известных стартапов
Источник: weeek.net