Комментарии 18
Нашёл что-то новое для себя. Впервые услышал, что это не методология. Не думаю, что кто-то за это будет какие-то "баллы" снимать. Раньше (в бородатые времена) на этом никто не акцентировал внимания.
Методология
Говорит ЧТО, КОГДА и КАК делатьФреймворк
Говорит ЧТО делать
И ниже по тексту,
"Событие" - Sprint Planning
"Когда" - Каждый раз перед стартом спринта.
"Агенда" - Планируется работа, которая будет сделана в следующем спринте... Обычно на этом мероприятии стараются ответить на следующие вопросы...
"Участники" - Обязательно - Development team, Product owner, Scrum master...
Т.е. кроме ЧТО, КОГДА И КАК ещё и КТО есть.
Мне нравится пример с выпечкой тортика
А если без тортиков - то получается, что у скрама просто маленькие итерации (например 2 недели). И за эти 2 недели получается что-то завершённое и потенциально готовое к релизу. Сравнительно мало документации, и больше основано на feedback-ах, и методе проб и ошибок, получить быстрый отклик от Product Owner либо от пользователей. А методология рассказывает типичный процесс - ивенты, роли и артефакты. Чем меньше релиз, тем лучше предсказуемость, и ещё разработчиков держит в напряжении.
В Waterfall итерация может длиться годами, которая будет включать по очереди фазу сбора требований, разработку и тестирование. И только, например, через 3 года вы поймёте, что где-то сделали ошибку в требованиях, либо на самом деле хотели по-другому, ошиблись в оценке на пол года. И разработчики будут на расслабоне 2.5 года ) А в скраме - только первую неделю, а вторую на жилах рвать :) А там, где смотрят за burn down чартом нормально, то вообще не расслабишься.
Скажите, а где спрашивают такие вопросы про скрам? На роль скрам мастера?
Скрам-подмастерье должен цитировать таблицы с разницей мпжду фреймворками и методологиями в любое (доброе) время суток.
В Эпаме спрашивают обычно пару-тройку заковыристых вопросов, как раз про различия фреймворка и методологии и т.п. на любом интервью, если планируется работа по скраму=) Ну и я спрашиваю у тех, кто приходит на позицию бизнес-аналитика на тех.интервью.
Высокий уровень свободы и креативности
Вообще не увидел в этой схеме высокого уровня свободы и креативности. Скорее высокую скорость конвейера и выгорание :)
Недостаточно процитировать определение скрама (это легкий фреймворк, который…) и сразу перейти к разницам между фреймворком и методологией. Надо сперва объяснить, что такое фреймворк отдельно. Затем объяснить, что такое метод, методика, методология.
И уже после сказать, что скрам это фреймворк, а не методология. Будет понятно сразу, без таблиц.
Потом уже вы вспомните, что это всë называется и пишется SCRUM, но будет ли это важно и существенно…
Нет гибкости, проект должен пройти все предписанные шаги
То есть метология Agile, к которой относится SCRUM не обладает гибкостью?
Цель спринта (Sprint Goal) - единственная цель на Sprint.
У вас на каждый спринт только одна единственная цель?
А как работают проекты, где не просто больше чем 1.5 девелопера, а например 3-5 команд девелоперов?
Agile - философия, а не методология, это указано в шпаргалке.
Да, на спринт - одна цель. Если у вас 3-5 команд, то можно прочитать Nexus гайд, который описывает, как работают несколько скрам-команд над одним продуктом. Скрам - про одну маленькую команду, работающую над одной целью в спринте.
А если такая ситуация: команда маленькая, 7 человек. Бэкендер, андроид-разработчик, ios-разработчик, тестировщик, аналитик, пм, по. Команда в этом спринте делает фичу, которая реализуется параллельно на обеих мобильных платформах плюс завязана на бэкенд. Все пилят эту фичу параллельно. В следующем же спринте мобильные разработчики пилят чисто юайные фичи, для которых не требуются изменения на бэкенде, а бэкендер чтобы не простаивать начинают пилить новую большую фичу, которую фронты подхватят аж через спринт. И тогда получается что в этом спринте у фронтов одна задача, у бэка другая. Разделить их на разные команды? Но это будет неудобно, тестировщик один, его в какую команду? И как быть со спринтами когда все параллельно одну фичу пилят? Объединяться снова в одну команду? Я к тому что стоит ли так строго определять что один спринт - одна цель? Чем плохо что время от времени целей может быть несколько?
Есть и другие варианты.
Часть разработчиков пилит фичу, часть пилит багфиксы, причем разные.
Я вообще не очень представляю, в каком проекте работал автор, что у него не было таких ситуаций. Я всегда считал что Agile методологии в очень широких пределах подстраиваются под проект. И вот это одна цель на спринт - вообще выбивается даже из какой-то адекватности.
Да, и такое бывает. И бывает что аналитики в этом спринте описывают фичу которую разрабы будут пилить в следующем спринте. А разрабы в этом спринте пилят фичу, которую аналитики писали в прошлом) а тестеры вообще взяли задачу по актуализации тесткейсов или что-то ещё. И получается что у аналитиков одна цель, у разрабов другая, у тестеров третья)
А бывает что даже в рамках разрабов две цели - допилить фичу из прошлого спринта (допустим что ее зарелизили в том спринте но нужны доработки) и начать новую - итого две цели.
Работала в разных проектах, и были проекты, в которых ставились несколько целей, но обычно такие проекты ничем хорошим не заканчивались.
Про "одну цель на спринт" - это про одну важную цель,которую вы будете стараться добиться в этом спринте, у вас могут быть еще задачи, но если вдруг не получается достичь цель, то все другие задачи отодвигаются на второй план.
Например, у нас была задача через три месяца выйти в прод с MVP. Мы работали и над другими вещами в спринте, и аналитики работали над задачами на следуюший спринт, но когда нужно было выводить систему в прод, подключились все. Аналитики бросили все и помогали разрабочикам и тестерам в интеграционном тестировании, потому что целью было выйти закончить MVP и выйти в прод.
В целом, не не считаю корректным "не представляю в каких проектах работал автор", потому-что я не описываю в статье свой опыт. Это конспект скрам-гайда.
Например, у нас была задача через три месяца выйти в прод с MVP. Мы работали и над другими вещами в спринте, и аналитики работали над задачами на следуюший спринт, но когда нужно было выводить систему в прод, подключились все. Аналитики бросили все и помогали разрабочикам и тестерам в интеграционном тестировании, потому что целью было выйти закончить MVP и выйти в прод.
Другими словами менеджеры не смогли правильно разделить цель на задачи, чтобы проект был сделан в штатном режиме, и "как обычно" делали в аврале.
Я бы сказал что скрам в этом случае не помогает или работает плохо.
Всегда есть задача которая самая приоритетная и она обычно становится целью спринта. Если в вашем примере самая важная задача допилить фичи на приложениях, то чем бы не занимались бэекндер и тестер, если/когда нужна помощь мобильщикам они должны помочь. Если например задача не просто допилить фичу, а продемить её, тестер может начать готовить демо/презу, а бэкендер например генерить тестовые данные для демо параллельнос тем как мобильщики допиливают фичу. Ответственность скрам мастера подключить нужных людей когда и он понимает что нужна помощь.
Странная несистемная мешанина того, что происходит без логической связки и философии самого подода.
Сравнение с водопадом очень поверхностно и как-то нелепо. Просто они нужны для разного. Например, строительство моста или другого монстра по скрам будет неуместно.
Моя шпаргалка по Скраму для подготовки к интервью. Часть 1