Scrum vs Waterfall — Борьба продолжается!

Олеся Макаренко

Аккаунт-менеджер

Scrum vs Waterfall — Борьба продолжается!

Не так давно я побывала на семинаре, где один из спикеров рассказывал о гибкой методологии разработки — Scrum. Меня заинтересовала эта тема, так как я непосредственно сталкиваюсь с этим в своей работе. Я решила подробнее разобраться и сравнить, какая же из этих методологий больше подходит для ведения проектов «тяжеловесная» водопадная или динамичная Scrum?

Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами, предоставить заказчику готовые задачи проекта, для которых определён наибольший приоритет. Задачи реализуемые в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. Сроки спринтов так же строго фиксированы. Длительность одного спринта от 2 до 4 недель. Считается, что чем короче спринты, тем легче можно вносить изменения в проект, тем гибче он получается, т.к. при коротких итерациях можно быстро получить комментарии от заказчика и внести изменения. Разные компании определяют длительность спринта сами, на это могут влиять различные факторы, но часто он определяется методом проб и ошибок. Не смотря на то, что Scrum считается очень гибким, за счет коротких итераций и возможности часто вносить изменения, на протяжении спринта никто не имеет права менять список требований к работе, определенном на этапе планирования спринта.

Планирование спринтов происходит следующим образом: из общего количества работ проекта выбираются наиболее важные по приоритету. После того, как выбрана работа, оценивается время её реализации (обычно в человеко-часах), работа разбивается на задачи, которые не должны длиться более 12 часов, в противном случае задача разбивается на подзадачи. Обсуждается и определяются пути достижения реализации работы. В ходе исполнения заказчик ежедневно получает информацию о проделанной работе и о планах на день.

Существует диаграмма сгорания задач — диаграмма, показывает количество сделанной и оставшейся работы. Она обновляется ежедневно с тем, чтобы в простой форме показать подвижки в работе над спринтом. График является общедоступным, как для работников так и для заказчика.

По моему мнению огромным плюсом является именно возможность общения с заказчиком в ходе выполнения задач, что уменьшает риски недопонимания, которые могут быть плачевны для компании-исполнителя. Но есть и минусы этой методики — Scrum не дает точных сроков готовности разработки. Заранее сказать заказчику сколько займет реализация «полного» проекта и гарантированно уложиться в этот срок нельзя. Исполнитель либо фиксирует скор разработки, т.е. определяется время а количество работ не определено, либо определяется объём выполненных работ за N-количество времени.

Скорость разработки в Scrum — это не та скорость с которой проект реализуется согласно определённому графику, а скорость с которой выполняется задача. Если план хорошо соответствует реально проделываемой работе, чего достичь очень сложно, то это будет одно и то же, если же план не доработан, то увы задачи будут реализованы с отставанием, либо пострадает качество.

Суть методики в том, что нужно не стремиться за месяц выполнить план, а к тому чтобы за месяц было сделано максимум полезного при заданных ресурсах и нормальном режиме работы. Если поставить людям жёсткий план то это неизбежно приведёт к описанному выше — проект начнёт отставать от плана, сотрудников будут подгонять чтобы этот план реализовать, в итоге скорость работы над проектом временно вырастет, но потом, к сожалению надолго падает, что показывают мировые практики.

Теперь вернёмся к классической каскадной модели или waterfall model — модель разработки в которой в которой процесс разработки разбит на этапы, жёсткая последовательность этапов работ не дает возможности корректировки или перехода на предыдущий этап. То есть переход от одной части проекта к другой строго последователен и перейти к реализации следующего этапа не закончив текущий невозможно.

Waterfall требует определения чёткого технического задания, в котором подробно описаны способы и планы реализации указанных этапов. После того, как начались работы над проектом внесения изменений в техническое задание не может осуществляться, что делает этот метод в противоположность методике Scrum абсолютно не гибкой. Тем не менее каскадная модель при разработке крупных проектов позволяет снизить риски, при чёткой формализации и структурированности. Но главным плюсом модели является абсолютная прозрачность процесса, благодаря последовательному переходу от этапа к этапу. И как показала практика жёсткая последовательность позволяет дать точную оценку стоимости разработки и её сроков.

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

У меня возник вопрос а можно ли объединить гибкую Scrum и водопадную модель разработки проектов. Мне кажется у каждой из моделей есть свои преимущества и недостатки, но можно поспорить и сказать, что всё лучшее обоих методов может быть объединено в один процесс, в ходе которого можно добиться наилучших результатов. Мне кажется результаты могут быть ещё выше, если в команде будет адекватный менеджмент, который поймёт что возможно достичь одновременно качества работы и соблюдения всех сроков и требований. Такой подход может продвинуть компании к более современному и продуктивному методу разработки проектов, хоть он и может показаться нетрадиционным.

scrum-vs-waterfall

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

Комментарии

Тут без вас никак. Поделитесь с нами вашими мыслями

Горячие вакансии