Методология SCRUM — базовые понятия и принципы. SCRUM vs Водопад?

Сравнение  SCRUM и Водопада — война или дружба?

До этого фактически все свои проекты вел по Водопаду и в принципе был доволен результатом — все проекты удачно запускались, сроки практически не ехали, бюджет изменялся в пределах разумного — до 15% прироста. Однако тут наткнулся на очень интересную книгу «Scrum. Революционный метод управления проектами» и решил почитать, уж больно часто слышал про SCRUM последние годы.

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

Главный вывод, который сделал для себя, что это ошибка большинства противопоставлять эти две модели друг другу. По здравому  размышлению эти модели могут и должны дружить друг с другом. почему? Давайте посмотрим сначала на сущность SCRUM.

Главные идеи SCRUM:

  1. Работой отдельных экспертов РП не управляет.
  2. Рабочая группа является саморегулирующимся механизмом.
  3. Задача РП организовать спринт и устранить препятствия с пути рабочей группы, контролировать общий результат и руководить совещаниями в роли SCRUM-мастера.
  4. Эффект высокой производительности

Основы применения методологии SCRUM.

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

Вывод:

Неважно будете ли вы использовать SCRUM и спринты — вам все равно нужно изначально продумать план проекта крупными мазками и в данном случае Водопад единственный вариант. Да при этом мы все знаем, что первоначальная оценка по срокам и бюджету мягко говоря неточная — если повезет, то точность оценки в начале будет 50%, что можно приравнять к тому, что мы говорим, что просто не знаем когда закончится и сколько будет стоить. Тут то апологеты SCRUM и набрасываются на Водопад 🙂 А зря. Действительно, если реализацию вести по принципу, разработал все, протестировал все, запустил пилот всего, запустил в промышленную эксплуатацию, то можно нарваться на большие проблемы при длительном проекте. А я говорю — не ругайтесь, а после формирования предварительного плана начните его реализовывать по SCRUM с тестированием каждого этапа с привлечением экспертов заказчика и вы получите союз Водопада и SCRUM, при этом SCRUM с большой вероятностью позволит если не улучшить изначальные планы, то выполнить их хотя-бы.

Добавить комментарий