Внедряем скрам. С чего начинать.

12 октября 2015
25

В эту дискуссию вынесен фрагмент книги Джеффа Сазерленда  «Революционный метод управления проектами». Она вышла в издательстве «Манн, Иванов и Фербер» в текущем году. Мы не раз обсуждали на портале гибкие методики, разные формы Agile  и скрам в том числе (например, «Мы за скрам» ). В ходе этих дебатов много раз ставился вопрос: «А что тут нового-то? Помню, еще при Царе Батюшке, в 1913 году мы, бывалоча, не раз точно так же все делали». И этот тезис вполне реалистичен. С другой стороны, все же четкая методика и неформализованная практика – это разные вещи. Другой вопрос, что эти формальности дают или могут дать? Казалось бы, формальности и скрам – две вещи несовместные, но тем не менее, отрывок ниже – именно об этом.

Итак, если вы решились попробовать, то слово Джеффу Сазерленду.

«Я предлагаю краткое описание механизма, с помощью которого вы начнете любой проект. Изложение самого процесса внедрения общее и короткое, но для начала этого вполне хватит. Книга  была написана для того, чтобы объяснить вам, почему методология Scrum работает. Здесь, в приложении, вы получили ответ на вопрос, как она работает.

1. Выберите ВЛАДЕЛЬЦА ПРОДУКТА

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

2. Выберите КОМАНДУ

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

3. Выберите СКРАМ МАСТЕРА

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

4. Создайте БЭКЛОГ ПРОДУКТА

Это список абсолютно всех требований, предъявляемых к продукту и расставленных по их приоритету. Бэклог существует и развивается на протяжении всей жизни продукта, чьим ориентиром он является. Бэклог продукта — единственная и однозначная концепция «всего, что команда в принципе может сделать, в порядке приоритетности».

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

5.Уточните и оцените БЭКЛОГ ПРОДУКТА

Крайне важно, чтобы участники группы, которые будут выполнять задания из бэклога, оценили, сколько усилий это потребует. Команда должна взглянуть на каждую задачу и определить, выполнима ли она в принципе. Достаточно ли информации, чтобы выполнить задачу? Достаточно ли она обозрима, чтобы ее можно было оценить? Есть ли общее понимание, каким стандартам и критериям она должна соответствовать, чтобы быть выполненной? Создается ли при этом действительная стоимость? Должна быть обеспечена возможность продемонстрировать результат выполнения каждой задачи. Не оценивайте задания бэклога в часах, поскольку люди плохо с этим справляются. Оценивайте в относительных размерах: «малый», «средний», «большой». Лучше использовать последовательность Фибоначчи и присваивать каждой задаче количество баллов: 1, 2, 3, 5, 8, 13, 21.

6. ПЛАНИРОВАНИЕ СПРИНТА

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

Если команда уже прошла пару спринтов, ей следует учитывать то число баллов, которое было в прошлом спринте. Количество баллов мы называем ДИНАМИКОЙ ПРОИЗВОДИТЕЛЬНОСТИ. Скрам-мастер и команда должны в каждом спринте наращивать динамику. Планирование спринта — это еще одна возможность для владельца продукта и команды удостовериться, что все точно понимают, как реализация заданий служит воплощению замысла. На этой встрече все должны договориться о цели спринта и определить, что должны выполнить за спринт.

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

7. РАБОТА ДОЛЖНА БЫТЬ ВИДИМОЙ.

Прозрачность всех действий и процессов обеспечивает скорейшее достижение цели. Наиболее распространенный способ добиться этого — завести СКРАМ-ДОСКУ с колонками: «Нужно сделать, или бэклог»; «В работе»; «Сделано». Стикеры — это пользовательские требования, которые нужно реализовать; по мере того как они выполняются, команда перемещает стикеры из одной колонки в другую.

Еще один способ сделать работу видимой — создать ДИАГРАММУ ВЫГОРАНИЯ ЗАДАЧ. На одной оси — количество баллов, которое команда взяла в этом спринте, на другой — количество дней. Каждый день скрам-мастер подсчитывает количество баллов за выполненные задачи и отражает это на графике. В идеале к концу спринта должен быть резкий спад до нуля.

8. ЕЖЕДНЕВНОЕ СОБРАНИЕ НА ХОДУ , или ЕЖЕДНЕВНЫЙ SCRUM.

Это пульс всего процесса Scrum. Каждый день в одно и то же время не более чем на пятнадцать минут команда и скрам-мастер встречаются и дают ответы на три вопроса.

1.Что ты делал вчера, чтобы помочь команде завершить спринт?

2.Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?

3.Какие препятствия встают на пути команды?

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

9. ОБЗОР СПРИНТА

Это встреча, на которой команда рассказывает, что сделано за спринт, и демонстрирует готовые части продукта. Присутствуют владелец продукта, скрам-мастер, команда и любые заинтересованные лица: заказчик, представители руководства, потенциальные потребители. Это открытая встреча, где команда демонстрирует, что удалось переместить в колонку «Сделано» за время спринта.

Демонстрировать команда должна только то, что соответствует определению «Сделано». Что полностью и окончательно готово. Это может быть полностью выполненный продукт или его отдельная готовая функция.

10. РЕТРОСПЕКТИВНОЕ СОБРАНИЕ

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

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

Что могло бы ускорить ход работ?

Особенно важно, что люди ощущают себя командой и берут на себя ответственность за все процессы и их результаты. Решения ищут всей командой. Участники группы должны обладать определенной психологической выдержкой, чтобы их обсуждения были направлены на решение злободневной проблемы, а не на поиски виноватых. Абсолютно недопустимо, чтобы даже один член команды вынужден был занимать оборонительную позицию, — все в группе должны слышать и понимать друг друга.

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

11. Немедленно начинайте следующий спринт, учитывая как возникшие препятствия, так и результаты непрерывного совершенствования.»

Примечательно, что за последний год число публичных упоминаний о том, что крупные проекты серьезных заказчиков делались по методологии скрам, явно выросло. Особенно это видно в докладах про внедрение BPM. Причем заказчики уже начинают утверждать, что иначе BPM- проект и нельзя вести. Поэтому вопрос: а вы видите вокруг рост популярности этого подхода? Если да, то где?

Насколько, с вашей точки зрения, описанная последовательность действий применима и реалистична? Всегда трогательно услышать такой ответ на вопрос, .внедрен ли у вас ITIL: «Да, конечно, только он у нас свой. Мы же его адаптировали под себя». Надо думать, и скрам у каждого свой?

И еще один связанный с этим же вопрос. Анонс книги гласит: «За 20 лет существования Scrum помогла не только большинству разработчиков программного обеспечения, но и ФБР, автопроизводителям, фармацевтам и простым людям, планирующим свои дела. Неважно, хотите ли вы изменить систему образования, изобретать новые технологии, бороться с голодом, просто открыть стартап или управлять своей командой в разы эффективнее — Scrum поможет вам успевать больше, затрачивая меньше времени и ресурсов.»

Тут тоже напрашивается аналогия с ITIL,который вполне можно применять не только в ИТ отделе, но и в АХО. А скрам? Есть ли примеры универсальности подхода?

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

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

  • Виктор Федько
    Рейтинг: 325
    Свободен
    Свободная
    14.10.2015 11:07

    в том числе (например, «Мы за скрам» ).

    Ссылка некорректна, дает ошибку.

    Мы за скрам

    • Леонид Воронин Виктор
      Рейтинг: 10
      ПротивоПожарная Автоматика, ООО
      сайт менеджер
      15.10.2015 07:36

      корректная ссылка на "Мы за скрам"

      http://www.globalcio.ru/workshops/576/

  • Виктор Федько
    Рейтинг: 325
    Свободен
    Свободная
    14.10.2015 11:10

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

    • Марк Шварцблат Виктор
      Рейтинг: 10
      КТ "Акведук"
      ИТ-директор
      14.10.2015 11:17

      Единоначалие - наше всё. Два хозяина = нет хозяина. :)

      • Виктор Федько Марк
        Рейтинг: 325
        Свободен
        Свободная
        14.10.2015 11:39

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

        • Марк Шварцблат Виктор
          Рейтинг: 10
          КТ "Акведук"
          ИТ-директор
          14.10.2015 11:51

          В одну телегу впрячь неможно
          Коня и трепетную лань.
          Забылся я неосторожно:
          Теперь плачу безумства дань...
          Может быть у кого-то и были заметные успехи с "коллегиальным хозяином", а у меня нет. Как говорится - на чём зарабатываем? На реальном продукте или на виртуальных кредитах-отчетах. Тот и главный.

          • Виктор Федько Марк
            Рейтинг: 325
            Свободен
            Свободная
            14.10.2015 12:06

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

            Хотя и "дань безумства" платить приходится)))

            • Марк Шварцблат Виктор
              Рейтинг: 10
              КТ "Акведук"
              ИТ-директор
              14.10.2015 12:11

              А нервные клетки восстанавливаются медленно, а "лекарства" всё дорожают. :)

  • Виктор Федько
    Рейтинг: 325
    Свободен
    Свободная
    14.10.2015 13:57

    Нет, лекарства осваивать))))

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

    Конечно есть примеры универсальности подхода. Возьмите бригаду лесорубов - работает точно также. Только вместо скрам-доски - стол из горбыля. Визуализация результатов - внешний вид делянки.
    Тем людям которые на формализации скрам подхода сделали себе имя и бизнес - большой респект.

  • Татьяна Орлова
    Рейтинг: 89
    ЗАО "ЕС-лизинг"
    Замдиректора по инновационной и экспериментальной деятельности, консультант по управленческим дисциплинам
    14.10.2015 20:47

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

    • Марк Шварцблат Татьяна
      Рейтинг: 10
      КТ "Акведук"
      ИТ-директор
      15.10.2015 09:57

      Вот-вот. Мыслительно-согласовательный процесс коллегиальный - а единоначалие должно быть. Пусть и переходящее.

  • Сергей Аблаев
    Рейтинг: 10
    Ф-л "МЕГАМАРТ" АО "Дикси ЮГ"
    Руководитель отдела развития ИТ
    15.10.2015 07:41

    Я про скрам не знаю ничего практически - не было потребности...
    Но вот вопросы к тем пробовал:

    Термины "спринт", "ДИНАМИКА ПРОИЗВОДИТЕЛЬНОСТИ" звучат как то напрягающе - какова текучесть людей на таких проектах? Сильно ли проф выгорание при регулярном "спринте"? И как мотивировать людей на постоянные забеги?

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

  • Игорь Столяренко
    Рейтинг: 10
    АО "Россельхозбанк"
    Информационная безопасность
    22.10.2015 14:54

    Коллеги, рекомендую СКРАМ попробовать применить при работах по матрице требований к проекту! Вам понравиться результат.) Дальше, больше...

  • Марк Шварцблат
    Рейтинг: 10
    КТ "Акведук"
    ИТ-директор
    22.10.2015 15:23

    Adopt Scrum for Competitive Advantage

  • Игорь Столяренко
    Рейтинг: 10
    АО "Россельхозбанк"
    Информационная безопасность
    18.01.2016 18:22

    Чтобы всем проснуться, замечу, что скрам хорош только при стабильных командах. Иногда достаточно просто канбан или других методов из agile! Есть желание продолжить дискуссию коллеги или кризис подточил всю иннициативу у директоров?)

    • Марк Шварцблат Игорь
      Рейтинг: 10
      КТ "Акведук"
      ИТ-директор
      20.01.2016 11:36

      Кризис заставляет перемещаться со скоростью электровеника. :)

    • Сергей Волков Игорь
      Рейтинг: 10
      Уинаморе
      CIO
      26.01.2016 18:31

      Почему только при стабильных командах?

      • Игорь Столяренко Сергей
        Рейтинг: 10
        АО "Россельхозбанк"
        Информационная безопасность
        26.01.2016 19:19

        Методика расчета параметров в Scrum предполагает наличие предыдущего богатого опыта по их накоплению. Поэтому при часто-меняющихся составов команд, scrum не эфеективен - бесполезен!

        • Сергей Волков Игорь
          Рейтинг: 10
          Уинаморе
          CIO
          26.01.2016 19:32

          Речь идет о действующем проекте, и то что он основан на имеющихся данных.
          И в отдельно взятом проекте команда может быть разная. Даже если она не стабильная, работа идет. И метод применяется не только при программировании (практика).
          Хотя мнение насчет "стабильная команда" могут различаться.

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