Достаточно занятная статья про гибкие методологии разработки. https://habr.com/ru/companies/magnus-tech/articles/788860/
Читаешь, и в целом чувствуешь боль автора. Я сам как то пытался по скраму в аутсорсе работать, было безумно больно, больше я так не хочу.
Но по прочтении статьи бросается в глаза следующее: автор не понимает и не проникся идеями гибкой управления разработкой ПО, либо специально некооторые ситуации возводит в определнную степень абсурда.
Если тебе нужны гарантированно конкретные фичи к конкретному сроку, то не надо использовать гибкие методологии. Зачем, они реально будут вредить. Ведь гибкие методологии они про решение проблем, а не про фичи и это ключевой поинт. В аутсорсе ты подписываешься под скоупом проекта и сроками с бюджетом. То есть ты можешь сколько угодно внутри проекта быть гибким, но на результат это не повлияет. Так и зачем страдать? Особенно когда заказчик не готов постоянно коммуницировать и участвовать в развитии продукта.
Про несоответствие методологии реалиям разработки - реальная боль, так бывает увы очень часто. Руководитель сказал - внедряем аджайл, послушные исполнители ответили - ЕСТЬ! Проходят треннинги, приглашают коучей, вот только руководитель в этом никак не участвует. И в целом, требует раз в месяц помимо обычных отчетов еще и отчет о внедрении аджайла! При этом сам он не готов меняться. И делегировать принятие решений в команды не готов, тогда никакого аджайла не получится, хотя утренируйся. Все будут страдать, как описывает автор. Кстати, про выбор скрама или канбана - отличное видео от Алексея Пименова https://www.youtube.com/watch?v=NCEqFh5M12M.
Насчет того, что гибкие методологии не учитывают состав и численность команд вообще смешно, особенно учитыаая, что потом идет речь про LeSS. Про то как он в России "не прижился" отлично рассказывает Артем Кротов из Мир Платформ. Про команды в 40 человек - так же странно, всегда можно попилить команды, было бы желание. Вот у нас сейчас как раз пилим команду из 20 человек на 5. Потом расскажу, как прошло.
Про выгорание разработчиков - вообще никакого отношения к методологии, я видел как на них пахали и в водопаде и в "скраме". Аджайл как раз дает возможность сказать, да, мы облажались и потом подумать, почему так случилось. Если причина объективная, то с этим ничего не поделаешь в моменте.
Про нет метрик качества проделанной работы - тут даже комментировать нечего, чем не угодили Acceptance criteria непонятно. Хотя, учитывая, что автор их называет defenition of done, сразу есть вопросики по тому, как люди используют методологию.
В целом - самое странное, что люди все еще пытаются скрестить ужа с ежом и использовать гибкие методологии там, где они скорее будут мешать. Например, в аутсорсе они будут эффективны только при построенных доверительных отношениях с заказчиком и при условии, что заказчик готов уделять много времени на работу с командой, иначе проще для всех работать с ТЗ.
А вы работали в аутсорсе по гибким методологиям? Поделитесь опытом в комментариях!