На мой взгляд самую коварную ошибку допустили создатели, когда сказали, что скрам это фрэймворк, который нужно адаптировать под себя. Я много раз слышал, как люди ссылаясь на это утверждение, оправдывали отсутствие или модификацию фундаментальных элементов скрама, таких как роль Product Owner, burndown диаграмма, цель спринта, демонстрация, готовый продукт в конце спринта и др. Для таких многочисленных «адаптаций» даже появился специальный термин «Скрамно» (ScrumBut).

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

1. ПОЧЕМУ нужна цель спринта?


Я долгое время не понимал зачем нужна цель спринта. И почему в книге «Scrum и XP — заметки с передовой» Хенрика Книберга написано, что очень важно ее выбрать. Из-за подчеркнутой важности этого элемента скрама, мы всегда его использовали. Но из-за того, что мы не понимали смысла, мы придумывали ужасные цели. Обычно мы просто упрощали процесс выбора цели, задавая негласное правило, брать целью выпуск очередного релиза или реализацию какой-то очередной жирной спринтовой фичи. От этого усиливалось ощущение бесполезности цели, а то и ее вреда.

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

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

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

2. ПОЧЕМУ нужно отправлять письмо с объявлением старта спринта всем заинтересованным лицам и членам команды?


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

У письма есть и другое, более известное назначение. Все заинтересованные лица вводятся в курс задач и сроков команды. Такая осведомленность ЗЛ повышает лояльность к команде и уменьшает поток незапланированных задач.

3. ПОЧЕМУ нужно считать производительность команды и вести график?


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

Также график производительности команды полезен при определении объема задач на спринт на основе метода вчерашней погоды.

4. ПОЧЕМУ важен постоянный ритм?


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

Мы пробовали работать без соблюдения постоянного ритма, периодически меняли состав команды и длину спринта, меняли дни планирования и демонстраций. Когда мы начали работать в постоянном ритме, то заметили прирост скорости команды.

5. ПОЧЕМУ нужно проводить DSM и зачем рисовать burndown?


Все знают, что DSM (daily scrum meeting) нужны для синхронизации команды. Также DSM позволяет своевременно устранять проблемы разработки. Если у кого-нибудь из команды возникает проблема, угрожающая срывом сроков спринта, то она сразу вскрывается и решается совместными усилиями. Таким образом, основная ценность DSM заключается в обеспечении контроля следования плану. Эту ценность можно усилить, если отмечать завершенные задачи на burndown диаграмме в конце каждого DSM. Если burndown сигнализирует о слишком медленном завершении задач, это сразу вскрывается и решается.

6. ПОЧЕМУ в конце спринта должен быть готовый продукт?


Основной причиной этому является необходимость в частых релизов со стороны бизнеса. Но так бывает не всегда. Иногда бизнесу нужны ежеквартальные, а то и полугодовые релизы. Нужны ли нам готовые продукты в конце каждого спринта в этих случаях? Нужны!

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

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

В-третьих, не приходится выпиливать куски кода для пользовательской истории, которая была наполовину реализована один или несколько спринтов назад и сильно упала в приоритете или совсем потеряла актуальность.

Литература:

scrum_xp-from-the-trenches-rus-final.pdf
www.smartagilee.com/2012/06/v-behaviorurldefaultvmlo.html
www.scrum.org/ScrumBut

Поделиться с друзьями
-->

Комментарии (21)


  1. excoder
    19.05.2016 13:51
    +1

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

    ПОЧЕМУ нужно выключать мозг и следовать за «серебряными пулями», вместо того чтобы немного подумать и придти к логичным выводам.


  1. Romanych
    19.05.2016 14:45
    +1

    1. ПОЧЕМУ нужна цель спринта?


    Можно пару хороших примеров целей спринта? А то за отрицанием (не делайте релиз целью) я не могу разглядеть что такое хорошая цель.


    1. ssova
      19.05.2016 20:47

      Продуктовые цели:


      • Повысить конверсию на 5%;
      • Вывести продукт на рынок B2C.

      Такая цель может висеть несколько спринтов подряд, до тех пор пока не будет достигнута.


      Техническая цель:


      • Делать ровно столько, сколько нужно для готовности спринтовой фичи, не закладываясь на будущее;
      • Завершить спринт без хвостов.

      Техническими целями лучше не злоупотреблять. Ставить их нужно только для командного решения наболевших проблем


  1. kMakcu
    19.05.2016 20:00

    Приведите, пожалуйста, примеры правильно поставленных целей спринта из вашего опыта.


  1. vyatsek
    19.05.2016 20:00
    +1

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

    >2.ПОЧЕМУ нужно отправлять письмо с объявлением старта спринта всем заинтересованным лицам и членам команды?
    Какой-то бюррократический оверхед. Заинтересованные лица как правило знают место, где можно посмотреть текущее состояние, плюс спросить у лида или еше кого либо. Пункт для имитации бурной дятельности.

    Вообще метрика только в одних SP попытка объять обним показателем эффективность работы, сомнительная затея. Можно на это потратить кучу времени, но не получить результата.

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

    Мне вообще скрам напоминает: «Организация рабочего процесса для чайников» в желте-черной обложке. В реальности все сложнее и учитывать приходится многие факторы. Тот же DM Daily Meeting обыкновенная оперативка перед работой, быстро поговорили у кого что и как и поехали работать.

    Статья попахивает «скрам головного мозга».


  1. M-A-XG
    19.05.2016 20:00
    +2

    Эти методологии разработки натянуты за уши и не везде подходят.

    Вы не написали, что и на чем программируете.

    1. Цели может и не быть. Ну или цель сделать то, что хочет заказчик. Но это наличие цели ради самого факта наличия цели.

    >Задачи нарезаны таким образом, чтобы результат работы одного члена команды был использован другим членом команды в другом спринте.

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

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

    У каждого члена может быть своя цель…

    2. Бюрократия

    3. Та какой ритм? Как это все считается? Сферический конь в вакууме.

    > Например, на график может повлиять постоянное изменение объема незапланированных задач, от спринта к спринту.

    И что тут такого?
    Баги-то фиксить нужно.

    >Эта проблема в свою очередь может быть причиной срыва сроков спринта.

    Дались Вам те сроки спринта.

    >Также график производительности команды полезен при определении объема задач на спринт на основе метода вчерашней погоды.

    Это все сферический конь в вакууме.

    4. Что вообще такое ритм и производительность.
    Провал ритма — это команда сидит и забила на работу? :)

    5. Это ненужная вещь.
    О проблеме нужно сообщать в задаче сразу, а не ждать DSM!

    6.
    > Во-первых, делая готовый продукт в конце спринта, команда избавляется от хвостов.

    Заливайте в мастер готовые фичи и будет вам готовый продукт в любой момент!

    > Новый спринт начинается с чистого листа, с новыми пользовательскими историями.

    Не всегда успевают протестировать прошлый спринт в течение прошлого спринта!

    >В-третьих, не приходится выпиливать куски кода для пользовательской истории, которая была наполовину реализована один или несколько спринтов назад и сильно упала в приоритете или совсем потеряла актуальность.

    А если она была реализована полностью?
    То как быть с выпиливанием?
    Да и зачем ее выпиливыть, если хранить ее в отдельной ветке?
    Ее в мастере и быть не должно.

    Скрам вроде бы гибкая методология, но она никакая не гибкая.


    1. ssova
      19.05.2016 20:03

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


      1. excoder
        19.05.2016 23:40

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


    1. ssova
      19.05.2016 20:13

      > Но разные люди могут работать над разными участками. Кто-то пишет АПИ, кто-то его использует. Как это можно обойти?

      Если взять 3 недельный спринт, то можно успеть написать API и клиента в одном спринте.


      1. M-A-XG
        20.05.2016 12:58

        А еще лучше 2 мес спринт, чтобы наверняка. :)
        Сама длительность спринта маразм.
        Нужно реализовывать задачи, а не заниматься спринтостроением.


        1. ssova
          24.05.2016 18:45

          Можно и не заниматься спринтостроением, только не нужно называть это скрамом


    1. ssova
      19.05.2016 20:15

      > У каждого члена может быть своя цель

      Может, но это уже не скрам


      1. vyatsek
        19.05.2016 21:44
        +1

        У каждого человека своя цель, важно чтобы личные цели в большей части совпадали с целями компании.


        1. M-A-XG
          20.05.2016 13:12

          Вы говорите о цели, миссии, ценностях компании и прочей фигне?


    1. excoder
      19.05.2016 23:43

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


    1. borv
      20.05.2016 20:03

      Гибкая она, только если знать где гнуть. Скрам это контракт (как программный интерфейс) между тремя сторонами — ПМ, Заказчиком и Инженерами. Реализация этого контракта зависит от много чего. Как и в программировании — хорошее API может быть плохо реализовано. На тренингах этому, к сожалению, этому не учат, а занимаются разбором этого самого интерфейса. Пообщайтесь с кем-то у кого скрам работает — взглянете на это по-другому. Если хотите — спрашивайте в личку.


  1. burjui
    20.05.2016 14:22

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


    1. ssova
      23.05.2016 18:11

      Вполне сойдет для проекта из одного-трёх человек


  1. qadmium
    23.05.2016 17:17

    А у меня команде не было DSM, и была отличная «синхронизация». Когда у тебя в команде 3 человека и один QA которые в постоянном контакте, а не одни социопаты, то все отлично.

    А вот еще помню к нам приезжал Zibsun и говорил что нынче не надо оценивать таски в часах, хотя за несколько лет до этого говорил другое, этож аджайл, куда повернешь туда и поплывет


    1. ssova
      23.05.2016 17:30

      этож аджайл, куда повернешь туда и поплывет

      Как раз об этом моя статья. Нельзя бездумно перекраивать Agile процесс!


      Прочитав ваш комментарий, я представил себе такую картину: сидят члены сообщества Agile за очередной чашечкой кофе и один из них: "А давайте больше не будем считать часы и фокус фактор, а будем считать story points и velocity..." и остальные ему: "Давай, давай, давай".


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


      1. qadmium
        23.05.2016 18:39

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

        >бездумно

        бездумно вообще ничего делать нельзя ))

        >Правила скрама более продуманны, чем может показаться на первый взгляд.

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

        >Прочитав ваш комментарий, я представил себе такую картину: сидят члены сообщества Agile за очередной чашечкой кофе и один из них: «А давайте больше не будем считать часы и фокус фактор, а будем считать story points и velocity...» и остальные ему: «Давай, давай, давай».

        вообще примерно так и было ))