Как методология превращает хаос в результат: инструкция по подбору Макро-методологий и фреймворков, применяемых в IT для управления процессом разработки, чуть меньше, чем дофига. Гибких, негибких и гибридных. Разбирать каждую - писать пост до пенсии, поэтому сегодня пробежимся по четырём самым популярным ин зе ворлд. Это пост о том, как и в зависимости от каких обстоятельств подбирать методологию под тот или иной проект. Waterfall ("Водопад", каскадная модель) Классический последовательный процесс, подразумевающий следующий набор этапов: 1) сбор и формирование требований; 2) проектирование; 3) реализация; 4) тестирование; 5) внедрение и сопровождение. Строго, скучно, старомодно, негибко (надо же), в реальности часто обрастает бюрократией. Когда целесообразно применять: ▪️когда работаете в госсекторе и жестко облеплены индустриальными регламентами (например, военпром, медицина), как комарами в карельском лесу; ▪️когда бюджет, сроки и документация - железобетон, хоть ты тресни. Scrum Гибко на дистанции, но строго в рамках отдельно взятого спринта. Подразумевает наличие спринтов, ритуалов (планирование, дейлики, ретрики) и внутрикомандных ролей (PO, SM). Когда целесообразно применять: ▪️когда требования периодически меняются; ▪️когда есть потребность регулярно обновлять продукт и тестировать гипотезы; ▪️когда нужно придать коллективу чуть больше тонуса и структурности (за счет жестко фиксированного объема работы в рамках спринта, четких ролей и некоторых ритуалов); ▪️когда нужно держать руку на пульсе, чувствовать ритм команды. Исходя из сказанного выше: Скрам идеален для стартапчиков и/или команд с вышедшей из чата рабочей дисциплиной. Kanban Непрерывный поток задач без истерик и страха не закрыть спринт, минимум митингов, акцентированная работа с доской задач. Когда целесообразно применять: ▪️когда сложно спланировать поток работы: летят баги, делаются хотфиксы, возникают вопросы и задачи, требующие оперативного решения; ▪️когда поток задач в принципе непрерывен и нет смысла делить разработку на итерации, планируя уникальный набор фич и фиксов каждый раз; ▪️когда важно оставаться сверхгибкими, когда важно иметь возможность отвлекаться на внезапно возникающие задачи/проблемы; Исходя из сказанного выше: Канбан чаще подходит для поддержания уже действующих продуктов, пребывающих в КЭ, а также для зрелых и сыгранных команд. Scrumban Scrumban - гибрид Скрама и Канбана. Целесообразно применять в командах, не готовых к закрученным по самое не хочу гайкам, как в Скраме, но, всё же, требующих определенного порядка и структуры. Грубо говоря: не тратим время на кучу ритуалов, оставляя только реально полезные, имеем условные спринты (релизимся раз в полмесяца-месяц) и размытое планирование, хаваем все типы тикетов в любое время: новые фичи, баги от QA-отдела и техподдержки. Скрамбан чаще подходит для поддержания уже действующих, но всё еще активно развивающихся и видоизменяющихся продуктов.