Давайте сравним скрам и «водопад»

24 ноября 2014
16

С точки зрения управления «водопад» подразумевает довольно сложное администрирование. Много ответственных. Есть главный разработчик. Есть главный тестировщик. Есть главный по коммуникациям внутри проекта. Главный аналитик. Возникает «дерево» людей, которые должны как-то коммуницировать, ими надо управлять. Какой артефакт отражает результат проекта? Незыблемый план проекта. Что в этом плане происходит? Мы выставляем какие-то проценты – задача сделана на столько-то. Определяет это менеджер проекта, он устанавливает правила игры.

При этом риск удачи или неудачи находится в самом конце проекта. Основные риски отнесены на момент, когда проектпора сдавать. До этого момента риски незначительны, мы можем их фиксировать как потенциальные, описывать действия по работе с ними, но у нас всегда слишком мало информации, чтобы точно сказать – мы уже близки к реализации этого риска? Он уже реален или нет? Чаще всего возможна только экспертная оценка.

Что происходит в скраме? Происходит очень большое упрощение администрирования проекта. Там всего три роли: владелец проекта, тот, кто говорит, что ему нужно, и именно он постоянно принимает решения о том, что полученный продукт – это то, что ему нужно или нет. Вторая роль – это скрам-мастер, модератор, помогающий контролировать исполнение правил игры. Третья роль, совершенно новая сущность – команда разработки. Внутри нее нет деления на роли.

Нет никаких формальных тестировщиков, аналитиков, разработчиков. Вся эта работа выполняется, но кто что делаети когда – это коллективная ответственность команды за результат. Претензии могут быть только к команде в целом, но ни к кому-то персонально. Поэтому команда должна перестроить свою работу так, что бы принимать решения. Вы как команда подрядились за спринт, за три недели обычно, сделать определенное продвижение? Ну так давайте. В этой методологии действительно нет ничего нового. Она просто принуждает людей перестраивать свои мозги. Нет никого, за кого можно спрятаться, как за менеджера проекта.

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

Так как скрам предполагает итерационность разработки, а периоды, спринты, очень короткие, то очень высокая степень прозрачности. Мы не занимаемся планированием бесконечного будущего. Возможность изменений закладывается в архитектуру продукта. Есть очень серьезное распространенное возражение против скрама – вы не фиксируете масштаб проекта, границы, цель, пределы. На самом деле это неверно. Все фиксируется. Мы определяем, какую же задачу мы должны решить. Мы фиксируем изменения внутри этой задачи. Если мы начали делать CRM, то мы не станем «вдруг» делать SCM потому что «что-то поменялось». Все это приводит к тому, что надо сразу же очень четко определить цели, очертить, какую задачу же мы решаем. Это накладывает ответственность не только на команду разработки, но и на владельцев продукта. Это позволяет до нуля уменьшить нереализованные требования. Но в этот момент начинают появляться новые требования. Ответственность владельца продукта в том, чтобы не менялись границы требований вообще.

Что происходит в начале проекта, когда мы принимаем решение о начале разработки? Мы фиксируем «коробочку». Мы в нее потом накидаем каких-то «кубиков». Мы не будем спорить потом, что вместо вот того одного надо оказывается поставить два других, но из «коробки» все это вылезать не будет. Мы ее фиксируем. Но мы ее набъем по самую крышечку. В «водопаде» за каждый «кубик» начинается битва.

Если мы еще не сделали «кубик» – вы можете передумать. Если мы уже сделали и вы приняли, а теперь хотите чтобы мы переделали – это новая работа, иначе нехорошо получается. На каждом этапе мы спрашиваем – ваше мнение не изменилось? Вы все еще хотите эти «кубики»? Это приводит к тому, что риски не накапливаются.

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

Скрам построен на системе встреч. Их много. У нас трехнедельный спринт. В первый день мы планируем спринт. Два раза в неделю – встречи с бизнес заказчиком. В конце третьей недели происходят две важные встречи: первая – демонстрация, мы показываем, что сделано. Заказчики говорят – то ли это, что хотелось. Вторая встреча– с владельцем продукта. Смотрим на один из немногих артефактор скрама – бэклог, список всех наших задач, который непрерывно ведется, может прирастать и сокращаться. В нем есть толстая красная черта – то, что мы уже сделали и то, что мы точно успеем сделать, это «коробочка». Отдельно – новые требования, но мы их не успеваем сделать за время проекта. В конце каждого спринта идет пересмотр бэклога, полного перечня задач. Что-то удаляется, что-то вносится, расставляются приоритеты.

Степень неопределенности падает к концу проекта. Грамотное тестирование еще более минимизирует риски. Все это дает возможность мониторить отношение бизнес-заказчика к процессу. Мы постоянно в контакте. Надо сказать, что бизнес заказчики очень быстро понимают, что за кажущуюся потерю времени, высокую свою вовлеченность они получают прозрачность и управляемость доселе невиданную. Все проблемы при такой методологии вылезают на свет, причем своевременно.

Если клиент общаться не хочет, и говорит – я вам сейчас расскажу, что мне нужно, а вы потом приходите ко мне с готовым продуктом, то проект практически наверняка обречен на неудачу. Так может не надо нам ввязываться в такой проект? Может быть, стоит объяснить бизнес-заказчику наш подход или отойти в сторону?

Возникает вопрос – где скрам нельзя сделать? Его нельзя делать там, где не нужна прозрачность.

8788
Поделиться
Коментарии: 16

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Максим Шахаб
    Рейтинг: 10
    АО "Лаборатория Касперского"
    Директор по информационным технологиям
    28.11.2014 10:30

    Со скрамом возникают сложности, например, при использовании его в сильно зарегулированных областях (внешними либо внутренними регуляторами).
    Например, ряд документов мы обязаны согласовывать с внешними инстанциями (служба информационной безопасности, управление интеллектуальной собственностью), и этот процесс предполагает водопадную модель организации работ. Т.е. требования создаются в полном объёме, утверждаются и только после этого поступают в работу.
    Мы не можем себе этого позволить, поскольку от нас требуется высокий темп работ. Т.е. мы начинаем работу до разработки требований в полном объёме. Это противоречие порождает целый ряд проблем.

  • Александр Огнивцев
    Рейтинг: 60
    Атомстройэкспорт
    Зам директора по ИТ
    28.11.2014 11:11

    Автор продемонстрировал абсолютное незнание проектных методов, в частности итерационного подхода. На основании некомпетентности в проектом подходе сделаны некоторые выводы, которые обычно и делают приверженцы скрама. На самом деле, методология скрам, пришедшая прямиком из 90-х годов, не нова и не слишком эффективна, особенно в серьезных проектах с серьезным финансированием. Скрам дает преимущества для команды разработчиков, так как размыта персональная ответственность, фиксированных результатов нет, сроков нет, а значит и финансирования по результатам (реального, а не паллиативного) также нет.
    Самый главный результат работы по этой методологии - демонстрация высоких темпов работ, того что называется движухой. Это безусловно сильная сторона скрама. Многие заказчики готовы платить деньги за серьезную движуху и общее бурление, да и просто за оклеивание стен желтыми бумажками.

    • Евгений Панин Александр
      Рейтинг: 10
      Нанософт
      Директор по ИТ
      12.12.2014 15:34

      Главный результат не демонстрация, а правильное разбиение работы на такие этапы, которые можно было бы запустить и использовать.

      Конечно, если не понимать суть, то действительно будет безрезультатное бурление.

      При нормальной скрам-разработке и сроки есть и результаты есть.

      Как обычно, без человеческого влияния не обходится. Недостаточно просто знать термин "скрам", надо ещё и определенный опыт в нём иметь.

      • Александр Огнивцев Евгений
        Рейтинг: 60
        Атомстройэкспорт
        Зам директора по ИТ
        12.12.2014 15:44

        Дело в том, что при правильной организации работы и правильном разбиении на этапы - будет работать и водопад, а в сложных случаях итерационный метод ведения проектов. Адепты секты скрама всё время путают грамотную команду с методологией. Грамотная команда вовсе без методологии мало на что способна, но при наличии ЛЮБОЙ ВМЕНЯЕМОЙ методологии способна на многое. Я не против скрама, я против подмены понятий и абсолютизации очередной модной парадигмы. Тем более, что я из тех, кто знает, что эта парадигма родом из середины 90-ых...:)

  • Константин Варов
    Рейтинг: 10
    Диасофт Платформа
    Управляющий директор
    12.12.2014 11:02

    Большинство крупных проектов, как только их пытаются вести адепты скрама заканчиваются одним и тем же аккордом: деньги, а иногда еще и время, заканчиваются (прожраны на "бантики" в предыдущих спринтах), первоначальное заказчика представление о результате проекта исполнено лишь наполовину, новых денег у заказчика нет (бюджет-то не резиновый), а ехать по-прежнему надо. В итоге заказчик стряхивает с себя это наваждение и говорит, что не готов больше играть по этим правилам, а результат, пожалуйста, принесите вовремя и полном объеме в соответствии с первоначальными ожиданиями. И вот тут-то команду во главе со скаммастером ждет жестокий удар, некоторые его даже не переживают. Так что поддержу Александра в том, что скрам в больших проектах применять противопоказано.

    • Алексей Лапшин Константин
      Рейтинг: 10
      АйТи
      Руководитель проектного сервиса
      12.12.2014 15:07

      Категорически не согласен. Приведу аналогичные аргументы. Начали крупный проект, собрали требования, реализовали, показали. Поняли, что не то, т.к. требования изменились, условия поменялись. Подрядчик говорит, что сделал все, что было согласовано когда-то. Это новые требования, следовательно новый бюджет, новые сроки. И либо все, как вы написали, с заменой скрам мастера на руководителя проекта, либо заставили подрядчика выполнить еще и этот объем работ, угрожая не заплатить деньги за сделанное.
      Scrum подразумевает наличие ГРАМОТНОГО владельца продукта, способного выделить главные задачи и отмести второстепенные, приоритезировать задачи, чтобы бантики не попали в первые спринты, оценить результат спринта на соответствие требованиям и ожиданиям.
      Кроме того, SCRUM подразумевает, что во время grooming происходит оценка user story из backlog на соответствие целям проекта, т.е. user story должна приводить к достижению цели проекта.
      Я уже сравнивал SCRUM и waterfall с геометриями Лобачевского и Евклида. Последняя является предельным случаем первого.
      Я никогда не утверждал, что проекты по waterfall априори не успешны, они более сложны в управлении и достижении результата.
      На мой взгляд, дискуссия развернулась в плоскости, что scrum не возможен, если заказчик (бизнес-заказчик, а не ИТ заказчика) не хочет или не может выполнять свою роль в scrum команде. Это так. Но и для waterfall эта ситуация губительна.

      • Александр Огнивцев Алексей
        Рейтинг: 60
        Атомстройэкспорт
        Зам директора по ИТ
        12.12.2014 15:48

        Вы путаете проблемы в организации работы команды, проблемы в квалификации команды с применением методологии. Ни проектная методология, ни любые разновидности аджайла НИЧЕГО НЕ ГАРАНТИРУЮТ. Но если проектная методология предусматривает вменяемое бюджетирование, то "гибкие" методики его не предусматривают по умолчанию. Я исполнителей не авансирую, не знаю что это такое. Приемка осуществляется только по факту выполнения работ. Можно это в скраме? НЕТ. Исполнитель ИЗНАЧАЛЬНО мотивирован на возможно более долгое и интенсивное бурление, вместо результата.

    • Евгений Панин Константин
      Рейтинг: 10
      Нанософт
      Директор по ИТ
      12.12.2014 15:28

      Тут дело не в скрам, а в скорее в скраммастере :-)

      • Константин Варов Евгений
        Рейтинг: 10
        Диасофт Платформа
        Управляющий директор
        12.12.2014 16:17

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

  • Ольга Мельник
    Рейтинг: 40
    Независимый эксперт
    12.12.2014 16:25

    Ну я бы сказала, что сам по себе факт "размазывания" кого-либо еще не говорит о том, что все было плохо, причем плохо по вине подрядчика. Так могло произойти и по другим причинам, например, если означенный банк совершенно не знаком со скрам и по такой модели работать не умеет. А сразу, наверно, не научишься, какого бы гуру к тебе не прислали.

  • Аркадий Затуловский
    Рейтинг: 80
    ОАО "Нордеа Банк"
    ИТ директор
    23.12.2014 10:32

    Коллеги, спорить о сравнении Scrum и PMBok можно только если мы говорим о статистике, т.е. о большом количестве проектов, которые управляются большим количеством РП. Рассматривать случай очень профессионального РП и "ГРАМОТНОЙ" команды бессмысленно - такая комбинация всегда добьется успеха. Но если мы говорим о массе, то в этом случае оценки разнятся.
    Водопад по сути ориентирован на глобальное снижение рисков и тотальный контроль. В принципе это не плохо, но до определенной степени. Это хорошо работало в эпоху не частых изменений и когда проектов было не так много потому что ИТ еще не стал частью жизни всех людей. Но если рассматривать водопад с т.з. мотивации людей, то это не о нем :)
    Scrum (как и другие методики) по моему мнению больше направлены на мотивацию людей и повышению эффективности работы команды и больше отражают реалии сегодняшнего дня, когда перемены идут в 10 раз больше и быстрее.
    У обеих методик есть свои плюсы и минусы, поэтому каждая из них больше подходит для определенного типа проектов и меньше для другого типа.
    На мой взгляд, в ближайшее время мы увидим сближение этих методологий, а именно водопад будет двигаться в сторону agile методик и скорее всего именно scrum.

    P.S. не очень понял о чем аргумент "эта парадигма родом из середины 90-ых.." ? Слишком молодая что-ли или уже очень старая ? :)

  • Ольга Мельник
    Рейтинг: 40
    Независимый эксперт
    23.12.2014 18:20

    Подробное описание проекта в Альфа-банке, выполненное по методологии скрам.

  • Борис Позин
    Рейтинг: 10
    ЕС-Лизинг
    CTO
    23.12.2014 22:33

    Спросите скрам мастера в начале проекта, какой результат он получит. Запишите и попробуйте продать это описание заказчику, как описание результата проекта. Думаю, не купит. Всё дело в том, что, согласно известным работам Боэма, Липаева, Каперса Джонса, самым сильным фактором, влияющим на успешность проекта, является опыт работы в прикладной области. Каким бы методом вы не работали. Кроме того, есть сложность (в том числе масштаб) разрабатываемой системы. Есть опыт работы на платформе и с языками программирования. Исходя из этих и еще многих факторов следует выбирать метод работы. И скрам далеко не всегда подойдет для решения сложной задачи.
    Почему-то никто не затронул вопрос о том, сколько людей нужно опросить, чтобы сформулировать требования. Совсем не всегда один человек может стать их носителем. Как в этом случае работает скрам?
    Интересно, сколько проектов, реализованных в скрам и водопаде анализировал автор начального материала, чтобы сделать такие выводы? Надо всё-таки не путать маркетинг с техникой, мне кажется.

  • Михаил Рябко
    Рейтинг: 10
    АО МПО им.И .Румянцева
    Начальник отдела проектов 1С
    27.01.2015 19:21

    А можно еще и комбинировать оба метода. Например, на верхнем уровне управления большим проектом использовать водопадный метод, а этапы с какого-то уровня отдавать командам на скрам.
    Как клюшки для гольфа - своя для каждой ситуации :)

  • Павел Кастеневич
    Рейтинг: 10
    Andersen
    CIO
    15.05.2015 14:43

    У меня изначалаьно вопрос, почему все говорят Scrum, потому что это модно? Или имеется в виду чистый Scrum, как он должен быть и которого в природе не существует (еще не слышал и не видел ни одного проекта, который делался бы по всем правилам scrum)? Скорее статья про Agile в целом и каскадные методы ведения проекта.
    Ясное дело, что применять Scrum везде где не попадя - будет ошибкой; другое дело разработать или подобрать гибкую методологию, которая, учитывая специфику проекта, довела его до успешного релиза, вот в чем задача и уровень исполнителя.

Предметная область
Отрасль
Управление