Как бы мы закрывали уязвимости в SELECTOS, если бы у нас были спринты

Значимый прорыв формирует отрасль ИИ: Liisign 1 минуту назад Как бы мы закрывали уязвимости в SELECTOS, если бы у нас были спринты 7 мин 10 Блог компании Selectel Карьера в IT-индустрии Agile * Управление проектами * Ответ: так же быстро как и сейчас, расходимся! А если серьезно, то давайте обсудим, в какой момент классические подходы к управлению проектами стали альтернативными, и зачем в IT до сих пор натягивают скрам на дедлайны, как сову на глобус. Я Наташа, менеджер проектов в Selectel.

Уже дважды я выносила спринты из команд ногами вперед, и хочу поделиться этим опытом с теми, кто ищет предсказуемости и результативности в сложных технических продуктах. Напомню, что спринты пришли в нашу жизнь, как инструмент скрама и внутри этой методологии вполне себе эффективны. Вот только если внимательно почитать скрам-гайд, становится очевидно, что примерно ноль продуктов на нынешнем рынке укладываются в этот подход к разработке.

Технические детали

Серьезно, где вы последний раз видели вот такого сферического коня в вакууме:владелец продукта тщательно приоритизирует бэклог;на грумминге пятеро кроссфункциональных разработчиков ясно осознают, что от них требуется и дают каждой задаче оценку (правда попадать в оценки они начнут дай бог к пятому спринту, и то при условии, что никто не болеет, не ходит в отпуск, не увольняется, не нанимается);на планировании спринта достаточно лишь перетянуть нужное количество стори поинтов в спринт;у спринта есть цель: команда вместе работает над конкретной фичей или итерацией, которую можно в конце показать как завершенную единицу работы;в конце спринта есть, что показать на демо, потому что даже если кто-то из разработчиков не успевает, любой свободный (ахах) коллега, пусть даже дизайнер, спешит на помощь. А если разработчик пошлет такую помощь, что сделаем? ) Об этом позаботится скрам-мастер;команда пилит продукт до тех пор, пока на очередном демо заказчик не скажет, что всем доволен и этого достаточно.

Ничего не имею против этой методологии, просто она не выживает в наших суровых реалиях. IT-сфера так разрослась, что люди имеют довольно узкие компетенции и не так уж взаимозаменяемы. Одних только дизайнеров сейчас десятки видов, а что уж говорить о разных стеках разработчиков.

Технологии быстро развиваются и так же быстро появляются новые сложные продукты-платформы. Конкуренция высокая, так что щупать воду и идти итерациями можно, но с понятными сроками и ресурсами. А тем временем в пересчете на месяц обслуживание идеального сферического скрама в вакууме сопоставимо с оплатой труда еще одного сотрудника, и от таких затрат хочется увидеть сопоставимых бенефитов.

Отраслевые последствия

В чем проблемаКоманды продолжают верить в ритуалы скрама, забывая о ролях, ценностях и артефактах этого фреймворка. Хорошо, если в команде кто-то очнулся и решил привести это в порядок. Но плохо, если менеджер начинает слепо настраивать скрам по правилам, не замечая того, что в его обстоятельствах эта методология не подходит.

Как итог, цель и процесс подменяют друг друга.

Этот прогресс даёт важные сигналы о будущем отрасли, и технологический мир внимательно наблюдает.