Сравнение SCRUM и Водопада — война или дружба?
До этого фактически все свои проекты вел по Водопаду и в принципе был доволен результатом — все проекты удачно запускались, сроки практически не ехали, бюджет изменялся в пределах разумного — до 15% прироста. Однако тут наткнулся на очень интересную книгу «Scrum. Революционный метод управления проектами» и решил почитать, уж больно часто слышал про SCRUM последние годы.
Самое странное для меня было, что его фактически противопоставляют Водопадной модели и вот решил изучить этот вопрос.
Главный вывод, который сделал для себя, что это ошибка большинства противопоставлять эти две модели друг другу. По здравому размышлению эти модели могут и должны дружить друг с другом. почему? Давайте посмотрим сначала на сущность SCRUM.
Главные идеи SCRUM:
- Работой отдельных экспертов РП не управляет.
- Рабочая группа является саморегулирующимся механизмом.
- Задача РП организовать спринт и устранить препятствия с пути рабочей группы, контролировать общий результат и руководить совещаниями в роли SCRUM-мастера.
- Эффект высокой производительности
Основы применения методологии SCRUM.
- Сформировать команду численностью не более 7 человек.
- Команда должна быть самодостаточна для решения поставленных перед ней работ.
- Все задачи проекта должны быть декомпозирована до уровня, когда можно четко сформулировать что нужно сделать, зачем, как проверить и для кого делается.
- Все декомпозированные задачи необходимо ранжировать по степени важности — для этого можно использовать метод Делфи.
- Необходимо также необходимо определить емкость той или иной задачи — для этого могут использоваться колоды карт с последовательностью Фибоначи (несколько упрощенной 1, 2, 3, 5, 8, 13 — этого достаточно)
- Далее формируются первый спринт из первостепенных задач, пул задач для перового спринта формируется на установочной встречи этого спринта. Количество задач первого спринта определятся исходя из оценки их по трудоемкости.
- Для оценки трудоемкости задач спринта использовать можно и это эффективно «Покер планирования» — например доступен здесь http://www.planitpoker.com/board/#/rooms.
- В качестве SCRUM доски можно использовать — http://scrum-time.com
- После завершения планирования спринта внесение изменений в задачи запрещено.
- Каждый день совещания на 15 минут не более, что сделано, что планируется сделать, какие проблемы — от каждого.
- Далее работа — РП убирает препятствия с пути рабочей группы, рабочая группа самостоятельно занята решением задач.
- По завершению спринта — демонстрация новой версии продукта.
- Установочная встреча, определение что и где можно усовершенствовать для большей эффективности работы, планирование следующего спринта.
Вывод:
Неважно будете ли вы использовать SCRUM и спринты — вам все равно нужно изначально продумать план проекта крупными мазками и в данном случае Водопад единственный вариант. Да при этом мы все знаем, что первоначальная оценка по срокам и бюджету мягко говоря неточная — если повезет, то точность оценки в начале будет 50%, что можно приравнять к тому, что мы говорим, что просто не знаем когда закончится и сколько будет стоить. Тут то апологеты SCRUM и набрасываются на Водопад 🙂 А зря. Действительно, если реализацию вести по принципу, разработал все, протестировал все, запустил пилот всего, запустил в промышленную эксплуатацию, то можно нарваться на большие проблемы при длительном проекте. А я говорю — не ругайтесь, а после формирования предварительного плана начните его реализовывать по SCRUM с тестированием каждого этапа с привлечением экспертов заказчика и вы получите союз Водопада и SCRUM, при этом SCRUM с большой вероятностью позволит если не улучшить изначальные планы, то выполнить их хотя-бы.