Комментарии 18
Судя по минусу, разработчики (и не только разработчики) устали от Agile . Собственно в чем смысл этой статьи, вроде ничего нового нет?
Всегда любил абстрактные рассуждения в вакууме. Нужен ли человеку костыль. Давайте подумаем...
Думаю, что разработчики хотят, чтобы им просто уже не мешали работать :)
Правильно ли я понял, что скрам - это такая штука, при которой в перерывах между митингами программистам разрешается немного поработать?)
Андрей, я вам очень рекомендую посмотреть это гениальное выступление Кевина Хенней под названием Agility ≠ Speed. А после - выступление Аллена Холуба: The Death of Agile. Они внесут немного хаоса в ваши взгляды и помогут посмотреть на знакомые вещи под другим углом.
поставка нового релиза раз в 2-3-4 месяца
Аджайл церемонии на это не влияют от слова совсем. Чтобы релизы деплоились часто нужен не аджайл, а нормальная инфраструктура: автоматические ci/cd пайплайны, интеграционные авто-тесты, деплой в один клик без остановки сервиса, непрерывный мониторинг, возможность быстро откатить релиз назад. В идеале цикл «сделал маленькое изменение, пушнул, сбилдил, прогнал тесты, отправил на прод» - должен занимать 15 минут, тогда команда сама начнёт релизить на прод несколько раз в неделю, а то и в день без всяких скрамов и целей спринта.
тогда команда сама начнёт релизить на прод несколько раз в неделю, а то и в день без всяких скрамов и целей спринта
А куда девать свору аджайл-коучей? Да и кучу прочей околоайтишной братии? Если они начнут работу работать, никакие пайплайны не спасут…
А вот и не согласен.
CI/CD, автотесты и т.п. - это инструменты.
Они ничего не дадут, если команде фиолетово какие там у клиента проблемы, и целью спринта считается закрыть все взятые в спринт таски.
Ну а релизить несколько раз в день конечно хорошо, главное релизить то что надо клиенту или пользователям, а это бывает не всегда )
А как вы узнаете, сделали ли вы "то что надо клиенту", или нет, не релизнув? :)
Так это был ответ на посыл "можно релизить без всяких скрамов и целей"
Можно то можно, но на практике подход "просто дайте программистам работать, без скрамов и управлений проектами" работает редко :) Мне кажется весь этот Скрам-хайп уже прошел пик, дальше будет нормальное использование там где это уместно
Не забываем про технические задачи, польза от которых прямо сразу не видна заказчику, потому что функционально они ничего не добавляют. Но задачи эти делать надо, и выделять время на них надо прилично, чтобы потом со временем не начала проседать скорость введения новых фич по причине того, что команда погрязла в техническом долге, запутанном спагетти-коде, лавине багов и т.д. А в особо запущенных случаях на прод может незаметно просочиться то, что я называю "фатальный баг": неприятная поломка, спровоцировавшая цепочку негативных событий и приведшая к банкротству всей компании.
Вы всё детально разложили по полочкам! Из личного - в зависимости от характера ПО, стоит объяснять заказчику что это не проект типа "сделал-запустил-забыл", а продукт "сделал-запустил-развиваю". И техническая составляющая - большАя часть этого развития, от которой никуда не деться.
P.S. тем паче, частые релизы помогают узнать, не сломалось ли что-то из технической составляющей.
С помощью скрама сделали высосанные из пальца дедлайны ("спринты"), к ним высосали из пальца концепцию "цель спринта", а теперь статья про успешный успех, как эти цели формулировать.
Если у продукт овнера реально есть важный фокус для команды, то он и так донесёт до разрабов: обычно это задачи с суперприоритетом. Но иногда (очень часто) бывает так, что одной цели нет: там подправить, там дописать доку, а тут поисследовать. И это нормально. Не надо натягивать сову на глобус, и всё впихивать в вымученную цель
Странная статья. Вроде бы правильные слова, но ни о чем. Непонятна ни цель написания и достигнутый результат
Важна же не цель и ее формулировка, важна работа команды с целью, научение команды этой работе.
Цель спринта удобно использовать в качестве фильтра для того, чтобы брать в спринт только релевантные задачи и от этого строить приоритизацию. Приносит пользу если у вас много стейкхолдеров, либо PO склонен хотеть разного (обычно все и сразу).
И вот уже у вас вместо Скрама лишь пустой по сути карго-культ, и руководство ищет на замену нового менеджера или Скрам-мастера, потому что этот "поломался"...
А срам это и есть пустой карго-культ и волшебная таблетка для менеджмента. И возможность откосить от самостоятельного выстраивания процессов «своим умом».
Нужна ли команде Цель спринта в Scrum?