Scrum - популярный в командах разработки фреймворк. Но так ли он важен и нужен в действительности?
В статье в формате "вредных советов" приведены порочные практики, которые можно встретить в Scrum-командах.
Некоторые из них противоречат принципам фреймворка, некоторые наоборот. Тем не менее, если предлагаемые в статье практике стоят на повестке дня в вашей команде/компании, вероятно имеет смысл приостановиться и задуматься - вводятся ли нововведения осмысленно, и нет ли в них элемента Карго-культа.
1. Обязательно сверяйте точность стори-пойнтов перед планированием
Неоднозначное представление о соотношении стори-пойнтов и времени, необходимого на выполнение задачи - очень серьёзная проблема. Может оказаться, что в середине итерации команде не хватает задач, и придётся инициировать планирование второй раз за спринт.
Если вдруг окажется, что оценка завышена, Product-owner'у придётся переносить задачи в следующий спринт, и он будет очень недоволен этим фактом.
2. Планирование не закончено, пока все участники команды не сошлись в единой оценке
Для наиболее точной оценки, важно услышать каждого участника, имеющего представление, как делать задачу.
Чтобы убедиться, что каждый разработчик делает оценку осмысленно, а не просто соглашается с чужой оценкой, не вовлекаясь в процесс, можно использовать такую технику как Scrum-покер.
3. Имейте план на ближайшие несколько спринтов
Гарантированно избежать проблем, описанных в пунктах 2 и 3, можно при оценке задач не ограничиваться только задачами текущего спринта. Например, можно оценивать задачи при попадании в бэклог или иметь список оцененных задач на N следующих спринтов.
Чтобы всё работало правильно, также учитывайте, что оптимальная длина Scrum-спринта - 2 недели, а не столько сколько нужно, для выполнения цели спринта.
4. Обсуждайте все накопившиеся вопросы на Дейли-скрам
Daily stand-up - важный ритуал скрама, обеспечивающий коммуникацию между участниками команды.
Во время ежедневного стэндапа разработчики могут обсудить проблемы, возникшие в ходе решения их задач. Стейкхолдерам участие в дейли-скрам даёт возможность получить более точную оценку каждой задачи.
Есть мнение, что дейли-скрам нужно проводить стоя, чтобы уложиться в 5 минут, но это не наш случай.
5. Учитывайте фидбек от разработчиков во время ретроспективы
Ретроспектива в Скраме обязательна для получения фидбека от разработчиков. В ходе ретроспективы Тимлид или Скрам-мастер должны опросить каждого разработчика и составить список вещей, которые:
а) Помогли разработчику приблизиться к выполнению цели спринта;
б) Мешали разработчику эффективно приближать выполнение цели спринта.
При отсутствии ретроспективы может случиться ситуация, когда разработчик отвлекает тимлида своими проблемами в неподходящее для этого время, а не ждёт две недели до ретроспективы.
6. Обязательно проводите Sprint-review в запланированное время
Обзор спринта необходим для понимания, чем занималась команда последние 2 недели.
Идеально для полного контроля, если каждый разработчик по очереди продемонстрирует, какие задачи сделал лично он.
7. Настоящая Agile-команда должна строго следовать принципам Scrum
Разработчики, не понимающие ценности Scrum, могут пытаться саботировать выполнение необходимых ритуалов.
Задача Скрам-мастера в этом случае - пресекать подобное и направлять команду в правильное русло.
8. Помните, Scrum - простая методология
Если вы начинающий тимлид, внедрение Scrum будет первым шагом к успеху вашей команды карьеры.
9. Выше velocity - выше продуктивность
При оценке команд или индивидуальных разработчиков обязательно учитывайте, сколько стори-пойнтов успевает выполнить человек за спринт.
Наиболее отличившихся можно награждать премиями.
10. Scrum не сделал команду эффективнее?
Вы делаете Scrum неправильно. Для того, чтобы достоверно проверить соответствие команды scrum-ценностям и корректность соблюдения ритуалов, вам необходимо привлечь сертифицированного Scrum-мастера со стороны. Желательно в штат.
Комментарии (31)
TAZAQ
00.00.0000 00:00Написано "вредные советы", т.е. не сверяем точность, планируем как хочется, не планируем спринты в запас, прогуливаем дейлики, ретро, спринт-ревью? - пфф, и тд
EvgeniiR Автор
00.00.0000 00:00Спасибо, переименовал заголовки советов таким образом, чтобы их дословная трактовка не создавала двусмысленность.
EvgeniiR Автор
00.00.0000 00:00не сверяем точность
Сверять точность стори-пойнтов действительно плохая идея. Как и в целом использовать их таким образом что подобная сверка может понадобиться.
планируем как хочется
Описанная схема планирования это ад который надо избегать. А как правильно это делать, и делать ли вообще, оставляю читателю на подумать.
Не планируем спринты в запас
Не планируем конечно. Исказить представление о том что такое "итерация" до такой степени, что планировать несколько итераций наперёд, нужно очень постараться.
Если границы спринта для вас не означают +- ничего, зачем вам спринты?
прогуливаем дейлики
Прогулять дейлик в том формате, который предложен в статье в качестве вредного совета, действительно может быть эффективнее для работы чем присутствовать на таком :)
Nialpe
00.00.0000 00:00+1давненько работаю в айти, но еще ни разу не довелось встретить SCRUM в первозданном виде, поэтому не могу на практике оценить его преимуществ и недостатков. кто-нибудь встречал строгое следование канонам? везде что-то по мотивам... задумался - повезло мне или нет?
Tatsianka
00.00.0000 00:00+2Он и не должен быть первозданным. Цель сделать работу конкретной команды эффективной. А если работают "по книжке", значит команда не понимает, что им нужно.
odiszapc
00.00.0000 00:00+2Не хочу никого обидеть, но скрам - это полная, никому не нужная бесполезная шляпа.
Ведь как устроен нормальный мир разработки на самом деле? Есть задачи, есть разработчики которые их решают, тестировщики, есть прожект манагер, есть продуктовая команда, дизайнеры в т.ч. Есть релизы (в любом виде, будь то спринты, итерации, суть одна и та же). Продакт рулит фичами, прожект - временем разработчиков. Разработчики пилят фичи, двигают их в тестирование, оттуда собирается релиз/итерация.
Если грубо то вот собственно и вся разработка. Какую проблему в данном случае решет скрам вообще непонятно. Нужен лишь адекватный продакт и хороших прожект. Все, не нужен никакой специальный процесс для этого, нужно лишь прост уметь общаться с людьми и оценивать риски. Какие нахрен стори-поинты, раскладывание покера, раньше за такое можно было и по лицу получить.
ozzyBLR
00.00.0000 00:00+2Для понимания контекста, назвовите, пожалуйста, свою специализацию стаж и чем занимается компания?
auddu_k
00.00.0000 00:00До какого-то момента тоже так думал, но, оказалось, что там всё продумано:
чётко выделено время для общения на тему текущих задач, а в остальное время, неожиданно, можно эти задачи решатьюь, а не отбиваться от вопросов коллег или заказчика
временем рулить вообще не нужно, точнее не нужен выделенный человек, всем рулит команда
общее понимание задачи хорошо проверяется и утверждается тем самым покером (хотя мы его так и не внедрили на полную, но он действительно удобен)
Если честно, не знаю на сколько у нас классический скрам, но он отлично работает :-)
И да, есть команды, которые и без всякого срама отлично справляются)
EvgeniiR Автор
00.00.0000 00:00+2чётко выделено время для общения на тему текущих задач, а в остальное время, неожиданно, можно эти задачи решать, а не отбиваться от вопросов коллег или заказчика
Скрам не выделяет время для того чтобы задавать вопросы по задачам. Или вы для каждого вопроса возникшего во время выполнения ждёте 2 недели до следующего планирования?
Скрам вообще никак не выделяет время для индивидуальных митингов(или с участием определенного набора заинтереснованных людей). Вы для решения любого вопроса привлекаете всю команду?
общее понимание задачи хорошо проверяется и утверждается тем самым покером (хотя мы его так и не внедрили на полную, но он действительно удобен)
Зачем проверять общее понимание задачи людьми, которые ей не занимаются?
Зачем для этого понимания скрам-покер и стори-пойнты? Не проще ли если один человек сделает задачу и опишет её в коде/документации достаточно понятно для других?
И да, есть команды, которые и без всякого срама отлично справляются)
И сколько времени и внимания разработчиков они экономят на этом?
auddu_k
00.00.0000 00:00Или вы для каждого вопроса возникшего во время выполнения ждёте 2 недели до следующего планирования?
Если этот относится к теме спринта, тот каждый день есть Дейли, а если вдруг зачесалась левая пятка на поболтать про светлое будущее, то можно подождать, может быть даже не две недели.
Скрам вообще никак не выделяет время для индивидуальных митингов
Он их и не ограничивает, а манифест, прямо таки кричит, что взаимодействие людей важнее всего.
Зачем проверять общее понимание задачи людьми, которые ей не занимаются?
Почему не занимаются? Один описывает, другой реализует, третий тестирует, четвёртый внедряет, а пятый через месяц фиксит баги.
Покер же просто подталкивает людей рассказать о своём видении и обсудить его, это способ инициировать обмен информацией, а пойнты - мера понимания задачи в рамках сессии. Один видит простым, другой сложным - значит первый должен рассказать, почему это просто, возможно он больше знает о проекте и это знание нужно передать, сессия покера - время для этого.
Если что, то ни для чего другого пойнты не используем - не прижились.
Не проще ли если один человек сделает задачу и опишет её в коде/документации достаточно понятно для других?
Проще, а ещё проще работать одному, когда сам отвечаешь за всё, но в команде нужно взаимодействие и его удобно формализовать. Скрам - не самый плохой способ такой формализации, если его правильно готовить ????
Вот прямо любопытно, вы видели реального аналитика, который может описать так, чтоб потом не было вопросов, со всеми форматами логов и ещё бог знает каких мелочей, которые потом понадобятся тестировщика и внедренцу? А разработчика, который всё это реализует прямо так, как написано, и чтоб не подкопаться? Наверное, даже почти точно, если собрать такую команду, то скрам не нужен. А если потом такой чудо аналитик, ну, или кто там, уйдёт в кругосветку, найдете такого же? Быстро?
И сколько времени и внимания разработчиков они экономят на этом?
Сложный вопрос, вполне возможно, что ни сколько, они просто выработали свои процедуры обмена информацией, за кружкой чая, например (про чай - это вполне реальный кейс).
Тут важно понимать, что скрам у каждой команды свой и он постоянно меняется. Важно помнить, что команда - не просто сумма участников и следить за тем, чтоб сумма эта была побольше, а для этого развивать не только отдельных участников, но и команду в целом.
auddu_k
00.00.0000 00:00К стати, очень интересный тезис: скрам - это не про эффективность распределения ресурса, а про эффективность команды (скорость доставки изменений). Он про то, что если потратить время на входе, то с большей долей вероятности, но без гарантий, дальше можно будет работать параллельно, не мешая соседу и не отвлекаясь самому.
Да, есть затраты, которые кажутся лишними для каждого конкретного участника, но в среднем команда при этом будет эффективнее.Это как с вакцинацией: для каждого гражданина - сугубое зло, но для общества в целом даёт позитивную статистику, если угадали со штаммом ????♂️
EvgeniiR Автор
00.00.0000 00:00Если этот относится к теме спринта, тот каждый день есть Дейли
Ну то есть если одному разработчику необходима консультация другого по какой-то фиче, они делают это во время стендапа блокируя всех остальных?
Он их и не ограничивает, а манифест, прямо таки кричит, что взаимодействие людей важнее всего.
Изначальный тезис был, что в Скраме "чётко выделено время для общения на тему текущих задач".
А кричит о том что взаимодействие важнее всего Agile манифест. Scrum к Agile-манифесту не имеет отношения. В Скраме как раз появляются такие замечательные(нет) штуки как "проблемы решаем по расписанию, раз в спринт на ретро".
> Не проще ли если один человек сделает задачу и опишет её в коде/документации достаточно понятно для других?
Проще, а ещё проще работать одному, когда сам отвечаешь за всё, но в команде нужно взаимодействие и его удобно формализовать. Скрам - не самый плохой способ такой формализации, если его правильно готовить ????
Я не спорю что взаимодействие нужно. Мой вопрос: "Зачем проверять общее понимание задачи людьми, которые ей не занимаются?"
Если представление о задаче изменилось во время выполнения, об этом тоже нужно устроить отдельный митинг с обсуждением на всю команду?
Вот прямо любопытно, вы видели реального аналитика, который может описать так, чтоб потом не было вопросов, со всеми форматами логов и ещё бог знает каких мелочей, которые потом понадобятся тестировщика и внедренцу?
А разработчика, который всё это реализует прямо так, как написано, и чтоб не подкопаться? Наверное, даже почти точно, если собрать такую команду, то скрам не нужен.
А зачем? Более точное понимание задачи приходит во время выполнения, и это нормально. Разработчик при обнаружении каких-то неясных моментов может обсудить это с аналитиком или разработчиком-экспертом. Зачем всю команду дёргать для этого?
Если хотите чтобы сложной задачей занимались несколько разработчиков - есть парное программирование, есть mob programming - подходы когда люди буквально вместе садятся и делают задачу. И это будет значительно эффективнее, чем если разработчик на условном дейли будет пытаться словами в подробностях объяснить чего он где поменял/добавил в рамках задачи
Тут важно понимать, что скрам у каждой команды свой и он постоянно меняется.
Мне кажется вы тут слово "скрам" используете просто в значении "процессы".
Скрам это когда разрешение реальных потребностей команды заменяется на "А давайте сделаем скрам", последующие проблемы решаются через "А как же нам по скраму правильно это сделать"?
Моё предложение - выкинуть скрам, процессы подстраивать под потребности.
auddu_k
00.00.0000 00:00Оке, давай уточним. Выделенное время важно, чтоб не превращать остальное рабочее время в хаос решения мелких вопросов. В выделенное время я уверен, что не помешаю соседу в решении его задачи. Разве этого мало? Лично для меня это просто спасение.
И да, никто не мешает подойти и спросить, если точно знаешь кого.
Mausglov
00.00.0000 00:00Моё предложение - выкинуть скрам, процессы подстраивать под потребности.
Так выкидывайте. Только не говорите потом, что "Скрам не работает". Скрам декларирует, что при соблюдении всех правил участники получат определённые плюшки. Не соблюдаете какие-то правила - теряете плюшки, в целом или частично. Иногда довольно неочевидным образом.
EvgeniiR Автор
00.00.0000 00:00+1Так выкидывайте. Только не говорите потом, что "Скрам не работает".
Я не говорю "не работает". Я говорю что Скрам добавляет бесполезные ритуалы, нередко занимаюшие 5-10% общего рабочего времени, и идущие наперекор своевременной коммуникации.
Примеры проблем я привёл. Приведу ещё разнообразия ради:
Коммуникация по Скраму происходит по расписанию. Адекватная коммуникация(и соответствующая Agile-принципам, если вам это важно) должна происходить при появлении потребности в ней.
Итерация здоровой команды завершается на закрытии какой-то фичи/проекта/майлстоуна. Скрам-"итерация" завершается спустя фиксированное количество времени.
Скрам декларирует, что при соблюдении всех правил участники получат определённые плюшки.
А можно цитату из Скрам гайда про то, какие плюшки Скрам даёт?
auddu_k
00.00.0000 00:00Тут такое дело, если делать коммуникацию бесполезной, то она будет бесполезной. Сделаешь полезной и жизнь заиграет новыми красками.
Дальше как-то бессмысленно - практики говорят, что хорошо, но вместо того, чтоб понять в чем отличие от мест, где плохо, твердим, что затраты времени и всё бессмысленно. Сам такой был))
Да не просто и если не следить, не вкладываться, то будет плохо, но будет очень круто, если вложиться ????♂️
EvgeniiR Автор
00.00.0000 00:00Тут такое дело, если делать коммуникацию бесполезной, то она будет бесполезной. Сделаешь полезной и жизнь заиграет новыми красками.
Да не просто и если не следить, не вкладываться, то будет плохо, но будет очень круто, если вложиться ????♂️
Я предлагаю вложиться здоровые методы коммуникации, а не в Скрам. Вот и всё :)
Опираться при этом на рациональные аргументы в пользу тех или иных подходов и методов, а не ориентироваться на то "как в Скрам гайде написано".
Отмечу, что цитату из скрам гайда с преимеществами Скрама вы не привели.
практики говорят, что хорошо, но вместо того, чтоб понять в чем отличие от мест, где плохо
Я не считаю что Скрам-гайд это непоколебимая и универсальная истина, дарованная нам богами. Соответственно, что хорошо и что нет определяю не тем что написано "в практиках".
Если в практике написано что делать что-то - хорошо, но при этом в пользу этого не приведено ни единого аргумента, грош цена такой практике.
p.s. Завершу цитатой из гайда:
Scrum is free and offered in this Guide. The Scrum framework, as outlined herein, is immutable. While implementing only parts of Scrum is possible, the result is not Scrum. Scrum exists only in its entirety and functions well as a container for other techniques, methodologies, and practices.
ozzyBLR
00.00.0000 00:00Третий совет очень важный, но при этом не так уж и часто о нём говорят. Обычно говорят "планирование" - и имеют в виду следующий спринт. Такая схема может работать только в идеальном мире, где все оценки точны, весь код работает без фатальных ошибок и... нет изменений по ходу спринтов.
Оценка бэклога и формирование спринтов наперёд - важная штука. И я бы даже назвал это одним из признаков зрелой команды.
EvgeniiR Автор
00.00.0000 00:00+1Третий совет очень важный, но при этом не так уж и часто о нём говорят.
Если что, статья про "вредные советы", и то о чем я пишу имхо ужасные практики, которые перетекают из команды в команду только потому-что какой-нибудь менеджер где-то на курсах услышал что "Скрам это стильно, модно, молодёжно, весь мир уже использует скрам, присоединяйтесь".
Обычно говорят "планирование" - и имеют в виду следующий спринт. Такая схема может работать только в идеальном мире, где все оценки точны, весь код работает без фатальных ошибок и... нет изменений по ходу спринтов.
Зачем вам спринты, если вы планируете их несколько наперёд?
Где все оценки точны
Если итерация заняла больше времени чем команда ожидала, то вы либо доводите итерацию до конца, если считаете это целесообразным, либо завершаете её как неудачный эксперимент, и срезаете косты. Если у вас это работает иначе, то это просто не итерация.
Под планированием в таких командах, обычно, имеют ввиду: "Сейчас мы возьмём пачку задач которые нам принес менеджер, и потратим пол дня на споры о том как проставить каждой из них количество стори-пойнтов в джире, на которые никто никогда не посмотрит".
Простые вопросы:
Зачем вам оценивать каждую задачу?
Действительно ли их оценка влияет на их приоритеты, или может про какие-то задачи заранее известно, что их делать нужно? Если не влияет то зачем оценивать?
Действительно ли вам для оценки задачи нужны метрики более подробные чем "простая" / "могут быть подводные камни" / "сложная, нужно поработать и декомпозировать"?
-
Зачем вам оценка задачи каждым участником команды? Почему недостаточно одного человека обладающего нужной экспертизой?
auddu_k
00.00.0000 00:00С вами интересно дискутировать ????
Зачем вам оценивать каждую задачу?
Можно не оценивать каждую. Некоторые команды не оценивают баги и технические задачи. Например, по багам принимают соглашение, всегда делать "малой кровью" без серьёзных изменений кода и отдельно планировать серьёзные изменения по следам этих багов.
Действительно ли их оценка влияет на их приоритеты
Кажется никогда не влияет? И всегда есть задачи, от которых не отвертишься. Если честно не понял в чем суть этого пункта, кажется это "мухи и котлеты", которые отдельно
Действительно ли вам для оценки задачи нужны метрики более подробные чем...
Вопросом на вопрос: а зачем такая низкодискретная оценка, что она даст? Кроме последней, которая должна повлечь декомпозицию?
Почему недостаточно одного человека обладающего нужной экспертизой?
Потому что-тогда только этот человек и будет обладать экспертизой и станет узким местом команды. Что-то там про бас-фактор навевает )
EvgeniiR Автор
00.00.0000 00:00Можно не оценивать каждую. Некоторые команды не оценивают баги и технические задачи. Например, по багам принимают соглашение, всегда делать "малой кровью" без серьёзных изменений кода и отдельно планировать серьёзные изменения по следам этих багов.
И не проводить планирование, ибо мероприятие это довольно бестолковое, но времязатратное и выматывающее :)
Кажется никогда не влияет? И всегда есть задачи, от которых не отвертишься. Если честно не понял в чем суть этого пункта, кажется это "мухи и котлеты", которые отдельно
Если не влияет, то зачем оценка?
Вопросом на вопрос: а зачем такая низкодискретная оценка, что она даст? Кроме последней, которая должна повлечь декомпозицию?
То же самое что и стори-пойнты, только на порядок проще и быстрее - понимание сложности задачи у менеджера, и общее понимание сложности у команды, при необходимости.
Потому что-тогда только этот человек и будет обладать экспертизой и станет узким местом команды. Что-то там про бас-фактор навевает )
Люди не станут экспертами предметной области, от того что поучаствуют в
тыканьи пальцем в небооценке задачи.auddu_k
00.00.0000 00:00В том и фишка, что если каждый раз обсуждать структуру проекта на планированиях, проблемы проекта на ретроспективах, заставлять (!) обсуждать почему один оценил низкой оценкой, а второй высокой, чем эта задача сложней аналогичной из прошлого месяца, то люди вполне себе становятся экспертами, а оценки, волшебным образом осмысленными.
Собственно низкодискретная оценка не даёт возможности различать оценки, чтобы было понятно есть ли расхождение в понимании.
GospodinKolhoznik
Ага, главное при этом не дай бог кому то из членов Agile-команды не вспомнить сами принципы манифеста аджайл. Его тут же и выкинут в окошко. Потому что любая так называемая аджайл команда, живущая по скраму на самом деле боиться упоминания манифеста как черт ладана. Ибо никто из них никакого отношения к аджайлу не имеет.
MiraclePtr
А в чем конкретно обычно противоречие с манифестом? Я аж подумал, может забыл что, открыл перечитал сначала сам манифест, потом 12 принципов - для нашей скрам-команды все обстоит прям так как и написано, хоть галочки напротив каждой строчки ставь. Можете примеров привести, как оно не совпадает в тех случаях, про которые говорите вы?
EvgeniiR Автор
Скрам на самом деле вводит довольно жесткие ограничения, которые одновременно являются ну оочень спорными, а иногда даже абсурдными. Например абсурдные:
То есть Скрам-команда эта всегда команда фулл-стэков, каждый из которых одинаково хорошо занимается и дизайном, и фронтенд разработкой, и бэкендом, и мобильной разработкой.
Или отдельно команда бэкенд-разработчиков, отдельно фронт-енд разработчиков и пр., но тогда не понятно, как каждая команда по отдельности может создавать что-то ценное для пользователя.
Или вот, например:
Команды самоуправляемы, но есть СМ который контроллирует соответствие Скраму, и как быть?
SergeyMax
Кросс-функциональная команда - это когда у вас в команде есть и бэкендер, и фронтендер.
EvgeniiR Автор
Как команда совмещающая в себе людей с разными навыками соответствует требованию "Отсутствие подкоманд и иерархий"?
Я то только за кросс-функциональные команды, но против Scrum :)
SergeyMax
А в чём проблема?
Mausglov
Я трактую эти фрагменты иначе, взгляните:
Это значит, что все Разработчики в Scrum Team имеют одинаковый авторитет и права. Если этот принцип нарушается, то команда теряет ценности Скрама, со всеми последствиями.
Это не означает, что это команда из фулл-стэков. Это означает, что если (утрируя) на каждый спринт Вы то добавляете в команду участников с нужными компетенциями и убираете из команды участников с невостребованными компетенциями, то у Вас нет команды.
СМ контролирует соответствие Скраму, но не решения участников. СМ не распределяет задачи между Разработчиками - они делают это самостоятельно через консенсус.
Тем более, никакой вышестоящий начальник не влияет на решения команды. (Зато, например, он может распустить саму команду).