Comments 31
Настоящая Agile-команда должна строго следовать принципам Scrum.
Ага, главное при этом не дай бог кому то из членов Agile-команды не вспомнить сами принципы манифеста аджайл. Его тут же и выкинут в окошко. Потому что любая так называемая аджайл команда, живущая по скраму на самом деле боиться упоминания манифеста как черт ладана. Ибо никто из них никакого отношения к аджайлу не имеет.
А в чем конкретно обычно противоречие с манифестом? Я аж подумал, может забыл что, открыл перечитал сначала сам манифест, потом 12 принципов - для нашей скрам-команды все обстоит прям так как и написано, хоть галочки напротив каждой строчки ставь. Можете примеров привести, как оно не совпадает в тех случаях, про которые говорите вы?
Скрам на самом деле вводит довольно жесткие ограничения, которые одновременно являются ну оочень спорными, а иногда даже абсурдными. Например абсурдные:
Внутри Scrum Team нет подкоманд и иерархий. Это сплоченное объединение профессионалов, в любой момент времени сфокусированных на одной цели — Product Goal.
Scrum Teams являются кросс-функциональными, то есть их участники обладают всеми навыками, необходимыми для создания ценности в каждом Sprint
То есть Скрам-команда эта всегда команда фулл-стэков, каждый из которых одинаково хорошо занимается и дизайном, и фронтенд разработкой, и бэкендом, и мобильной разработкой.
Или отдельно команда бэкенд-разработчиков, отдельно фронт-енд разработчиков и пр., но тогда не понятно, как каждая команда по отдельности может создавать что-то ценное для пользователя.
Или вот, например:
Также они самоуправляемы, то есть сами решают, кто, что, когда и как делает.
Команды самоуправляемы, но есть СМ который контроллирует соответствие Скраму, и как быть?
Кросс-функциональная команда - это когда у вас в команде есть и бэкендер, и фронтендер.
Я трактую эти фрагменты иначе, взгляните:
Внутри Scrum Team нет подкоманд и иерархий.
Это значит, что все Разработчики в Scrum Team имеют одинаковый авторитет и права. Если этот принцип нарушается, то команда теряет ценности Скрама, со всеми последствиями.
Scrum Teams являются кросс-функциональными.
Это не означает, что это команда из фулл-стэков. Это означает, что если (утрируя) на каждый спринт Вы то добавляете в команду участников с нужными компетенциями и убираете из команды участников с невостребованными компетенциями, то у Вас нет команды.
Также они самоуправляемы, то есть сами решают, кто, что, когда и как делает.
СМ контролирует соответствие Скраму, но не решения участников. СМ не распределяет задачи между Разработчиками - они делают это самостоятельно через консенсус.
Тем более, никакой вышестоящий начальник не влияет на решения команды. (Зато, например, он может распустить саму команду).
Написано "вредные советы", т.е. не сверяем точность, планируем как хочется, не планируем спринты в запас, прогуливаем дейлики, ретро, спринт-ревью? - пфф, и тд
Спасибо, переименовал заголовки советов таким образом, чтобы их дословная трактовка не создавала двусмысленность.
не сверяем точность
Сверять точность стори-пойнтов действительно плохая идея. Как и в целом использовать их таким образом что подобная сверка может понадобиться.
планируем как хочется
Описанная схема планирования это ад который надо избегать. А как правильно это делать, и делать ли вообще, оставляю читателю на подумать.
Не планируем спринты в запас
Не планируем конечно. Исказить представление о том что такое "итерация" до такой степени, что планировать несколько итераций наперёд, нужно очень постараться.
Если границы спринта для вас не означают +- ничего, зачем вам спринты?
прогуливаем дейлики
Прогулять дейлик в том формате, который предложен в статье в качестве вредного совета, действительно может быть эффективнее для работы чем присутствовать на таком :)
что важнее спринт закрыть или задачу?
давненько работаю в айти, но еще ни разу не довелось встретить SCRUM в первозданном виде, поэтому не могу на практике оценить его преимуществ и недостатков. кто-нибудь встречал строгое следование канонам? везде что-то по мотивам... задумался - повезло мне или нет?
Не хочу никого обидеть, но скрам - это полная, никому не нужная бесполезная шляпа.
Ведь как устроен нормальный мир разработки на самом деле? Есть задачи, есть разработчики которые их решают, тестировщики, есть прожект манагер, есть продуктовая команда, дизайнеры в т.ч. Есть релизы (в любом виде, будь то спринты, итерации, суть одна и та же). Продакт рулит фичами, прожект - временем разработчиков. Разработчики пилят фичи, двигают их в тестирование, оттуда собирается релиз/итерация.
Если грубо то вот собственно и вся разработка. Какую проблему в данном случае решет скрам вообще непонятно. Нужен лишь адекватный продакт и хороших прожект. Все, не нужен никакой специальный процесс для этого, нужно лишь прост уметь общаться с людьми и оценивать риски. Какие нахрен стори-поинты, раскладывание покера, раньше за такое можно было и по лицу получить.
Для понимания контекста, назвовите, пожалуйста, свою специализацию стаж и чем занимается компания?
До какого-то момента тоже так думал, но, оказалось, что там всё продумано:
чётко выделено время для общения на тему текущих задач, а в остальное время, неожиданно, можно эти задачи решатьюь, а не отбиваться от вопросов коллег или заказчика
временем рулить вообще не нужно, точнее не нужен выделенный человек, всем рулит команда
общее понимание задачи хорошо проверяется и утверждается тем самым покером (хотя мы его так и не внедрили на полную, но он действительно удобен)
Если честно, не знаю на сколько у нас классический скрам, но он отлично работает :-)
И да, есть команды, которые и без всякого срама отлично справляются)
чётко выделено время для общения на тему текущих задач, а в остальное время, неожиданно, можно эти задачи решать, а не отбиваться от вопросов коллег или заказчика
Скрам не выделяет время для того чтобы задавать вопросы по задачам. Или вы для каждого вопроса возникшего во время выполнения ждёте 2 недели до следующего планирования?
Скрам вообще никак не выделяет время для индивидуальных митингов(или с участием определенного набора заинтереснованных людей). Вы для решения любого вопроса привлекаете всю команду?
общее понимание задачи хорошо проверяется и утверждается тем самым покером (хотя мы его так и не внедрили на полную, но он действительно удобен)
Зачем проверять общее понимание задачи людьми, которые ей не занимаются?
Зачем для этого понимания скрам-покер и стори-пойнты? Не проще ли если один человек сделает задачу и опишет её в коде/документации достаточно понятно для других?
И да, есть команды, которые и без всякого срама отлично справляются)
И сколько времени и внимания разработчиков они экономят на этом?
Или вы для каждого вопроса возникшего во время выполнения ждёте 2 недели до следующего планирования?
Если этот относится к теме спринта, тот каждый день есть Дейли, а если вдруг зачесалась левая пятка на поболтать про светлое будущее, то можно подождать, может быть даже не две недели.
Скрам вообще никак не выделяет время для индивидуальных митингов
Он их и не ограничивает, а манифест, прямо таки кричит, что взаимодействие людей важнее всего.
Зачем проверять общее понимание задачи людьми, которые ей не занимаются?
Почему не занимаются? Один описывает, другой реализует, третий тестирует, четвёртый внедряет, а пятый через месяц фиксит баги.
Покер же просто подталкивает людей рассказать о своём видении и обсудить его, это способ инициировать обмен информацией, а пойнты - мера понимания задачи в рамках сессии. Один видит простым, другой сложным - значит первый должен рассказать, почему это просто, возможно он больше знает о проекте и это знание нужно передать, сессия покера - время для этого.
Если что, то ни для чего другого пойнты не используем - не прижились.
Не проще ли если один человек сделает задачу и опишет её в коде/документации достаточно понятно для других?
Проще, а ещё проще работать одному, когда сам отвечаешь за всё, но в команде нужно взаимодействие и его удобно формализовать. Скрам - не самый плохой способ такой формализации, если его правильно готовить 😁
Вот прямо любопытно, вы видели реального аналитика, который может описать так, чтоб потом не было вопросов, со всеми форматами логов и ещё бог знает каких мелочей, которые потом понадобятся тестировщика и внедренцу? А разработчика, который всё это реализует прямо так, как написано, и чтоб не подкопаться? Наверное, даже почти точно, если собрать такую команду, то скрам не нужен. А если потом такой чудо аналитик, ну, или кто там, уйдёт в кругосветку, найдете такого же? Быстро?
И сколько времени и внимания разработчиков они экономят на этом?
Сложный вопрос, вполне возможно, что ни сколько, они просто выработали свои процедуры обмена информацией, за кружкой чая, например (про чай - это вполне реальный кейс).
Тут важно понимать, что скрам у каждой команды свой и он постоянно меняется. Важно помнить, что команда - не просто сумма участников и следить за тем, чтоб сумма эта была побольше, а для этого развивать не только отдельных участников, но и команду в целом.
К стати, очень интересный тезис: скрам - это не про эффективность распределения ресурса, а про эффективность команды (скорость доставки изменений). Он про то, что если потратить время на входе, то с большей долей вероятности, но без гарантий, дальше можно будет работать параллельно, не мешая соседу и не отвлекаясь самому.
Да, есть затраты, которые кажутся лишними для каждого конкретного участника, но в среднем команда при этом будет эффективнее.
Это как с вакцинацией: для каждого гражданина - сугубое зло, но для общества в целом даёт позитивную статистику, если угадали со штаммом 🤷♂️
Если этот относится к теме спринта, тот каждый день есть Дейли
Ну то есть если одному разработчику необходима консультация другого по какой-то фиче, они делают это во время стендапа блокируя всех остальных?
Он их и не ограничивает, а манифест, прямо таки кричит, что взаимодействие людей важнее всего.
Изначальный тезис был, что в Скраме "чётко выделено время для общения на тему текущих задач".
А кричит о том что взаимодействие важнее всего Agile манифест. Scrum к Agile-манифесту не имеет отношения. В Скраме как раз появляются такие замечательные(нет) штуки как "проблемы решаем по расписанию, раз в спринт на ретро".
> Не проще ли если один человек сделает задачу и опишет её в коде/документации достаточно понятно для других?
Проще, а ещё проще работать одному, когда сам отвечаешь за всё, но в команде нужно взаимодействие и его удобно формализовать. Скрам - не самый плохой способ такой формализации, если его правильно готовить 😁
Я не спорю что взаимодействие нужно. Мой вопрос: "Зачем проверять общее понимание задачи людьми, которые ей не занимаются?"
Если представление о задаче изменилось во время выполнения, об этом тоже нужно устроить отдельный митинг с обсуждением на всю команду?
Вот прямо любопытно, вы видели реального аналитика, который может описать так, чтоб потом не было вопросов, со всеми форматами логов и ещё бог знает каких мелочей, которые потом понадобятся тестировщика и внедренцу?
А разработчика, который всё это реализует прямо так, как написано, и чтоб не подкопаться? Наверное, даже почти точно, если собрать такую команду, то скрам не нужен.
А зачем? Более точное понимание задачи приходит во время выполнения, и это нормально. Разработчик при обнаружении каких-то неясных моментов может обсудить это с аналитиком или разработчиком-экспертом. Зачем всю команду дёргать для этого?
Если хотите чтобы сложной задачей занимались несколько разработчиков - есть парное программирование, есть mob programming - подходы когда люди буквально вместе садятся и делают задачу. И это будет значительно эффективнее, чем если разработчик на условном дейли будет пытаться словами в подробностях объяснить чего он где поменял/добавил в рамках задачи
Тут важно понимать, что скрам у каждой команды свой и он постоянно меняется.
Мне кажется вы тут слово "скрам" используете просто в значении "процессы".
Скрам это когда разрешение реальных потребностей команды заменяется на "А давайте сделаем скрам", последующие проблемы решаются через "А как же нам по скраму правильно это сделать"?
Моё предложение - выкинуть скрам, процессы подстраивать под потребности.
Оке, давай уточним. Выделенное время важно, чтоб не превращать остальное рабочее время в хаос решения мелких вопросов. В выделенное время я уверен, что не помешаю соседу в решении его задачи. Разве этого мало? Лично для меня это просто спасение.
И да, никто не мешает подойти и спросить, если точно знаешь кого.
Моё предложение - выкинуть скрам, процессы подстраивать под потребности.
Так выкидывайте. Только не говорите потом, что "Скрам не работает". Скрам декларирует, что при соблюдении всех правил участники получат определённые плюшки. Не соблюдаете какие-то правила - теряете плюшки, в целом или частично. Иногда довольно неочевидным образом.
Так выкидывайте. Только не говорите потом, что "Скрам не работает".
Я не говорю "не работает". Я говорю что Скрам добавляет бесполезные ритуалы, нередко занимаюшие 5-10% общего рабочего времени, и идущие наперекор своевременной коммуникации.
Примеры проблем я привёл. Приведу ещё разнообразия ради:
Коммуникация по Скраму происходит по расписанию. Адекватная коммуникация(и соответствующая Agile-принципам, если вам это важно) должна происходить при появлении потребности в ней.
Итерация здоровой команды завершается на закрытии какой-то фичи/проекта/майлстоуна. Скрам-"итерация" завершается спустя фиксированное количество времени.
Скрам декларирует, что при соблюдении всех правил участники получат определённые плюшки.
А можно цитату из Скрам гайда про то, какие плюшки Скрам даёт?
Тут такое дело, если делать коммуникацию бесполезной, то она будет бесполезной. Сделаешь полезной и жизнь заиграет новыми красками.
Дальше как-то бессмысленно - практики говорят, что хорошо, но вместо того, чтоб понять в чем отличие от мест, где плохо, твердим, что затраты времени и всё бессмысленно. Сам такой был))
Да не просто и если не следить, не вкладываться, то будет плохо, но будет очень круто, если вложиться 🤷♂️
Тут такое дело, если делать коммуникацию бесполезной, то она будет бесполезной. Сделаешь полезной и жизнь заиграет новыми красками.
Да не просто и если не следить, не вкладываться, то будет плохо, но будет очень круто, если вложиться 🤷♂️
Я предлагаю вложиться здоровые методы коммуникации, а не в Скрам. Вот и всё :)
Опираться при этом на рациональные аргументы в пользу тех или иных подходов и методов, а не ориентироваться на то "как в Скрам гайде написано".
Отмечу, что цитату из скрам гайда с преимеществами Скрама вы не привели.
практики говорят, что хорошо, но вместо того, чтоб понять в чем отличие от мест, где плохо
Я не считаю что Скрам-гайд это непоколебимая и универсальная истина, дарованная нам богами. Соответственно, что хорошо и что нет определяю не тем что написано "в практиках".
Если в практике написано что делать что-то - хорошо, но при этом в пользу этого не приведено ни единого аргумента, грош цена такой практике.
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.
Третий совет очень важный, но при этом не так уж и часто о нём говорят. Обычно говорят "планирование" - и имеют в виду следующий спринт. Такая схема может работать только в идеальном мире, где все оценки точны, весь код работает без фатальных ошибок и... нет изменений по ходу спринтов.
Оценка бэклога и формирование спринтов наперёд - важная штука. И я бы даже назвал это одним из признаков зрелой команды.
Третий совет очень важный, но при этом не так уж и часто о нём говорят.
Если что, статья про "вредные советы", и то о чем я пишу имхо ужасные практики, которые перетекают из команды в команду только потому-что какой-нибудь менеджер где-то на курсах услышал что "Скрам это стильно, модно, молодёжно, весь мир уже использует скрам, присоединяйтесь".
Обычно говорят "планирование" - и имеют в виду следующий спринт. Такая схема может работать только в идеальном мире, где все оценки точны, весь код работает без фатальных ошибок и... нет изменений по ходу спринтов.
Зачем вам спринты, если вы планируете их несколько наперёд?
Где все оценки точны
Если итерация заняла больше времени чем команда ожидала, то вы либо доводите итерацию до конца, если считаете это целесообразным, либо завершаете её как неудачный эксперимент, и срезаете косты. Если у вас это работает иначе, то это просто не итерация.
Под планированием в таких командах, обычно, имеют ввиду: "Сейчас мы возьмём пачку задач которые нам принес менеджер, и потратим пол дня на споры о том как проставить каждой из них количество стори-пойнтов в джире, на которые никто никогда не посмотрит".
Простые вопросы:
Зачем вам оценивать каждую задачу?
Действительно ли их оценка влияет на их приоритеты, или может про какие-то задачи заранее известно, что их делать нужно? Если не влияет то зачем оценивать?
Действительно ли вам для оценки задачи нужны метрики более подробные чем "простая" / "могут быть подводные камни" / "сложная, нужно поработать и декомпозировать"?
Зачем вам оценка задачи каждым участником команды? Почему недостаточно одного человека обладающего нужной экспертизой?
С вами интересно дискутировать 😁
Зачем вам оценивать каждую задачу?
Можно не оценивать каждую. Некоторые команды не оценивают баги и технические задачи. Например, по багам принимают соглашение, всегда делать "малой кровью" без серьёзных изменений кода и отдельно планировать серьёзные изменения по следам этих багов.
Действительно ли их оценка влияет на их приоритеты
Кажется никогда не влияет? И всегда есть задачи, от которых не отвертишься. Если честно не понял в чем суть этого пункта, кажется это "мухи и котлеты", которые отдельно
Действительно ли вам для оценки задачи нужны метрики более подробные чем...
Вопросом на вопрос: а зачем такая низкодискретная оценка, что она даст? Кроме последней, которая должна повлечь декомпозицию?
Почему недостаточно одного человека обладающего нужной экспертизой?
Потому что-тогда только этот человек и будет обладать экспертизой и станет узким местом команды. Что-то там про бас-фактор навевает )
Можно не оценивать каждую. Некоторые команды не оценивают баги и технические задачи. Например, по багам принимают соглашение, всегда делать "малой кровью" без серьёзных изменений кода и отдельно планировать серьёзные изменения по следам этих багов.
И не проводить планирование, ибо мероприятие это довольно бестолковое, но времязатратное и выматывающее :)
Кажется никогда не влияет? И всегда есть задачи, от которых не отвертишься. Если честно не понял в чем суть этого пункта, кажется это "мухи и котлеты", которые отдельно
Если не влияет, то зачем оценка?
Вопросом на вопрос: а зачем такая низкодискретная оценка, что она даст? Кроме последней, которая должна повлечь декомпозицию?
То же самое что и стори-пойнты, только на порядок проще и быстрее - понимание сложности задачи у менеджера, и общее понимание сложности у команды, при необходимости.
Потому что-тогда только этот человек и будет обладать экспертизой и станет узким местом команды. Что-то там про бас-фактор навевает )
Люди не станут экспертами предметной области, от того что поучаствуют в тыканьи пальцем в небо оценке задачи.
В том и фишка, что если каждый раз обсуждать структуру проекта на планированиях, проблемы проекта на ретроспективах, заставлять (!) обсуждать почему один оценил низкой оценкой, а второй высокой, чем эта задача сложней аналогичной из прошлого месяца, то люди вполне себе становятся экспертами, а оценки, волшебным образом осмысленными.
Собственно низкодискретная оценка не даёт возможности различать оценки, чтобы было понятно есть ли расхождение в понимании.
Scrum: вредные советы