Comments 12
когда вся команда работает над одной задачей совместно, в одном потоке.
Оно даже в теории не работает. Сначала аналитик должен выполнить свою работу и отдать разработчику требования к ПО, потом разработчик должен создать ПО, только после этого тестировщик сможет проверить ПО на ошибки. Это последовательность операций, т.е. конвейер, а не параллельная работа.
Второй момент, если все будут заниматься обсуждением одной задачи, то у вас будут очень большие расходы на коммуникации и мало времени на саму работу. Сюда же стоит добавить, что исполнители, как правило, интроверты, поэтому построить здоровую коммуникацию между интровертами очень сложная задача.
Самоуправляемая, автономная, кросс-функциональная команда
Самоуправляемых команд не существует. Всегда есть лидер или начальник, чьё мнение является решающим. Иначе в команде наступит анархия и "игра престолов" за влияние и за самые интересные задачи.
только после этого тестировщик сможет
А ведь он сможет не только после этого. Тестировщика можно подключить ещё на этапе описания требований, чтобы он: 1 - протестировал сами требования, 2 - заранее начал писать под них тест-кейсы.
Думаю, вопрос в том, что именно считать задачей? И здесь речь явно не идёт о самой последней стадии разбиения, а о какой-то более высокой и общей форме.
Оно даже в теории не работает
Ты бывал на хакатонах? Там оно именно так и работает, аналитика генерируется в процессе разработки решения, обсуждая сразу с разработчиками возможности и наиболее эффективный и быстрый способ сделать фичу.
Тестировщика вообще в скраме существовать не должно. Сам Сазерленд рассказывал, что если речь идет о применении скрама в разработке ПО, то работа должна строиться по extreme programming, с tdd и автотестами.
Ну и в целом аналитик, тестировщик и дизайнер не обязаны в команде быть отдельной ролью, которая ничего больше не умеет. Это может быть T-shape разраб с фокусом на QA или дизайн, или бизнес.
У скрама есть очень ограниченная область применения. Как только речь заходит о том, что команда неспособна работать над одной задачей совместно, не представляет как это работать без этапов и конвейера, то это значит только одно - скрам в такой команде не построить. Лучше посмотреть на другие способы организации работы подходящие конвейерной разработке, тот же канбан например.
Работал в разных проектах и конторах и везде скрам/аджайл свой. Самоуправляемые команды никогда не понимал, обычно, находится 1-2 энтузиаста, которые берут на себя роль лидеров и по сути выполняют работу менеджера, т.к. организационная работа всё равно должна быть выполнена, просто она теперь размазана между членами команды.
Потому, быть может, что в большинстве команд менеджер немного устал, хотел зарплату побольше, а напрягов поменьше, легко согласовал с начальством Agile (потому что так модно и перспективно), а вот вы программисты, - ну вы же умные, сами как-то разберётесь.
Скрам и Скам
Одну букву не пропишешь, а смысл тот же остаётся.
По поводу первой части и инкремента, кмк автор чрезмерно перемешал/переплёл это понятие с релизом. Инкремент - это такая доработка продукта, которая интегрирована в продукт и может быть продемонстрирована заказчику. И вот тут кроется тонкая грань - разве это не тот самый релиз? Релиз. Но. Я предлагаю посмотреть на релиз как на поставку новой версии пользователям.
Касательно роли менеджера в трансформации и ломании каноничного Скрама, я полностью согласен. Цель любого режима - сохранение текущего режима. Манагеры держатся за свои кресла, а трансформаторы должны трансформировать - иначе зачем они нужны?
Я бы сказал, что Скрам -- действительно не самоцель. В реальности приходится строить свой процесс, и он лишь напоминает Скрам, поскольку заимствовал оттуда многие черты.
Что же касается многих идей -- кросс-функциональности, частых релизов, то, увы, это действительно не всегда применимо. Самый радикальный пример -- это когда у вас продукт с 30-летней историей, большая часть которого создана не то что без всех этих Continuous Delivery, а из расчёта, что тестировщики глазами посмотрят. (Конечно, есть вещи, которые надо смотреть именно глазами, но когда 95% функциональности тестируется так, релиз даже каждые две недели -- утопия). Самое смешное, что и новые продукты часто создаются именно так, и ключевой вопрос архитектуры современных продуктов -- "как это непрерывно тестировать?" -- игнорируется с самого начала. И в итоге мы получаем ту же историю и ломаем рекомендуемый процесс под реальность.
Ломать процесс при этом именно приходится, выхода нет. Но жаль, что в эту, пардон, задницу, попадают новые продукты, а не 30-летние монстры с десятками миллионов строк кода, которых действительно могила исправит.
А уж когда на странные процессы внизу накручивается, пардон, какой-нибудь SAFe, смотреть на это часто и вовсе больно.
И снова повестка "скрам и агиле работают, вы просто не умеете их готовить, очень надо нанять того, кто умеет".
Может дело в том, что "карго культ" в этом случае не метафора?! Помимо того, что в самой статье полно противоречий, так она ещё и опирается на 2 "принципа", которые сами по себе являются бредом.
Не бывает никаких самоорганизованных команд. Если ваша команда "самоорганизована" - значит у нее есть неформальный лидер, который координирует ее действия.
А кроссфункциональные команды не существуют, потому что ваш "инкремент" требует участия большого количества людей с разными компетенциями, которые не могут работать одновременно и одинаковое количество времени.
Справедливости ради, если команда имеет неформального лидера, это тоже случай самоорганизации. Но соглашусь, что часто под самоорганизацией ошибочно понимают полное всеобщее равенство и отсутствие иерархий, которое есть утопия.
Кросс-функциональные же и правда редки. Я давно перестал во многих случаях даже пытаться её добиться. Скажем, одна из команд: два тестера, три бекендера, фронтендер и саппортер, большинство -- по аутстаффингу и не очень надолго. И что, мне предлагается убедить их, что надо за счёт заказчика выровнять компетенции? Или чтобы этих выгнали и заменили? Такой бред я им не предложу.
На мой взгляд скрам - методология для разработки маленьких стартапов или продуктов с очень простыми деталями. Когда ваша доработка - небольшая веб страница, кнопка постановки лайка, новый вариант сортировки - всё отлично, задача грумится командой, придумывается решение/дизайе/методы тестирования, бъется на части, инкремент каждый спринт - всё отлично.
Когда у вас задачи - которые только грумить надо неделю - где взаимодействие с 3мя сторонними системами, интеграция в 10 продуктовых флоу (и нет, по одному нельзя - они все связаны), и плюсом непонятна сложность. То начинается бесконечный перенос задачи из спринта в спринт, разбаланисровка команды - потому что бэкенд уже закончил, фронтенд ещё на середине, аналитики уже сидят крутят усы - скрам разваливается)
Карго-культ Scrum: почему команды копируют форму, но теряют суть