Ломай меня полностью… разве это про Scrum?

    На мой взгляд самую коварную ошибку допустили создатели, когда сказали, что скрам это фрэймворк, который нужно адаптировать под себя. Я много раз слышал, как люди ссылаясь на это утверждение, оправдывали отсутствие или модификацию фундаментальных элементов скрама, таких как роль 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

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 23

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

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


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

          0

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


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

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


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


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

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

            0
            На сколкьо корректно делать целью спринта ценность фичи (например реализацию профиля), т.е. разработчики знаю что на этом спринте у нас пользователь должен создавать свой профиль?

              0

              Не корректно

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

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

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

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

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

            Статья попахивает «скрам головного мозга».
              +2
              Эти методологии разработки натянуты за уши и не везде подходят.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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


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

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

                              >бездумно

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

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

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

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

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

                          Only users with full accounts can post comments. Log in, please.