В этой статье я поделюсь своим видением смысла и пользы некоторых элементов скрам. Я это сделаю в формате вопроса «почему этот элемент важен?». Это те почему, которые удалось мне выявить, путем проб и ошибок, а также внимательного наблюдения за процессами скрам в компаниях, где я работал.
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
www.smartagilee.com/2012/06/v-behaviorurldefaultvmlo.html
www.scrum.org/ScrumBut
Комментарии (21)
Romanych
19.05.2016 14:45+1- ПОЧЕМУ нужна цель спринта?
Можно пару хороших примеров целей спринта? А то за отрицанием (не делайте релиз целью) я не могу разглядеть что такое хорошая цель.
ssova
19.05.2016 20:47Продуктовые цели:
- Повысить конверсию на 5%;
- Вывести продукт на рынок B2C.
Такая цель может висеть несколько спринтов подряд, до тех пор пока не будет достигнута.
Техническая цель:
- Делать ровно столько, сколько нужно для готовности спринтовой фичи, не закладываясь на будущее;
- Завершить спринт без хвостов.
Техническими целями лучше не злоупотреблять. Ставить их нужно только для командного решения наболевших проблем
kMakcu
19.05.2016 20:00Приведите, пожалуйста, примеры правильно поставленных целей спринта из вашего опыта.
vyatsek
19.05.2016 20:00+1>Таким образом, цель спринта — это командообразующий элемент скрама и хорошо подобранная цель
В корне неверное суждение. Командообразующий элемент это подбор праивльных людей в команду и организациея иерархии и ролей в команде.
>2.ПОЧЕМУ нужно отправлять письмо с объявлением старта спринта всем заинтересованным лицам и членам команды?
Какой-то бюррократический оверхед. Заинтересованные лица как правило знают место, где можно посмотреть текущее состояние, плюс спросить у лида или еше кого либо. Пункт для имитации бурной дятельности.
Вообще метрика только в одних SP попытка объять обним показателем эффективность работы, сомнительная затея. Можно на это потратить кучу времени, но не получить результата.
>Если у кого-нибудь из команды возникает проблема, угрожающая срывом сроков спринта, то она сразу вскрывается и решается совместными усилиями.
Это работает и без скрама при адекватном руководстве, при неадекватном проблему можно вскрывать каждый раз.
Мне вообще скрам напоминает: «Организация рабочего процесса для чайников» в желте-черной обложке. В реальности все сложнее и учитывать приходится многие факторы. Тот же DM Daily Meeting обыкновенная оперативка перед работой, быстро поговорили у кого что и как и поехали работать.
Статья попахивает «скрам головного мозга».
M-A-XG
19.05.2016 20:00+2Эти методологии разработки натянуты за уши и не везде подходят.
Вы не написали, что и на чем программируете.
1. Цели может и не быть. Ну или цель сделать то, что хочет заказчик. Но это наличие цели ради самого факта наличия цели.
>Задачи нарезаны таким образом, чтобы результат работы одного члена команды был использован другим членом команды в другом спринте.
А как их нужно резать? Чтобы результаты работы одного члена команды использовал тот же член команды?
Но разные люди могут работать над разными участками. Кто-то пишет АПИ, кто-то его использует.
Как это можно обойти?
>Таким образом, цель спринта — это командообразующий элемент скрама и хорошо подобранная цель — это то к чему стремится каждый из членов команды в течении спринта и это то что важно для всей команды в целом.
У каждого члена может быть своя цель…
2. Бюрократия
3. Та какой ритм? Как это все считается? Сферический конь в вакууме.
> Например, на график может повлиять постоянное изменение объема незапланированных задач, от спринта к спринту.
И что тут такого?
Баги-то фиксить нужно.
>Эта проблема в свою очередь может быть причиной срыва сроков спринта.
Дались Вам те сроки спринта.
>Также график производительности команды полезен при определении объема задач на спринт на основе метода вчерашней погоды.
Это все сферический конь в вакууме.
4. Что вообще такое ритм и производительность.
Провал ритма — это команда сидит и забила на работу? :)
5. Это ненужная вещь.
О проблеме нужно сообщать в задаче сразу, а не ждать DSM!
6.
> Во-первых, делая готовый продукт в конце спринта, команда избавляется от хвостов.
Заливайте в мастер готовые фичи и будет вам готовый продукт в любой момент!
> Новый спринт начинается с чистого листа, с новыми пользовательскими историями.
Не всегда успевают протестировать прошлый спринт в течение прошлого спринта!
>В-третьих, не приходится выпиливать куски кода для пользовательской истории, которая была наполовину реализована один или несколько спринтов назад и сильно упала в приоритете или совсем потеряла актуальность.
А если она была реализована полностью?
То как быть с выпиливанием?
Да и зачем ее выпиливыть, если хранить ее в отдельной ветке?
Ее в мастере и быть не должно.
Скрам вроде бы гибкая методология, но она никакая не гибкая.ssova
19.05.2016 20:03Вы правы. Скрам хорошо работает только в продуктовой и инхаус разработке. В других случаях лучше канбан или что-нибуть из каскадо-водопада
excoder
19.05.2016 23:40Или же постановка действительно адекватных, интересных целей, соотнесённых с видением компании и требованиями заказчика, и здравый смысл. И никакой сахарной пудры сверху.
ssova
19.05.2016 20:13> Но разные люди могут работать над разными участками. Кто-то пишет АПИ, кто-то его использует. Как это можно обойти?
Если взять 3 недельный спринт, то можно успеть написать API и клиента в одном спринте.
excoder
19.05.2016 23:43Так ведь скрам-тренеры и напирают на то, что надо следовать букве этого скрама, а мы вам продадим свои услуги, чтобы ему ещё более лучше следовать. В любой методологии есть здравый смысл, но когда его возводят в ранг истины в первой инстанции, то проблемы искать надо в самой компании — команде, менеджменте.
borv
20.05.2016 20:03Гибкая она, только если знать где гнуть. Скрам это контракт (как программный интерфейс) между тремя сторонами — ПМ, Заказчиком и Инженерами. Реализация этого контракта зависит от много чего. Как и в программировании — хорошее API может быть плохо реализовано. На тренингах этому, к сожалению, этому не учат, а занимаются разбором этого самого интерфейса. Пообщайтесь с кем-то у кого скрам работает — взглянете на это по-другому. Если хотите — спрашивайте в личку.
burjui
20.05.2016 14:22Уж не знаю, дело во мне, или все эти методологии разработки — на самом деле жалкие попытки впихнуть разработку в прокрустово ложе бюрократии, но я пока что признаю только эту методологию, самую простую и понятную.
qadmium
23.05.2016 17:17А у меня команде не было DSM, и была отличная «синхронизация». Когда у тебя в команде 3 человека и один QA которые в постоянном контакте, а не одни социопаты, то все отлично.
А вот еще помню к нам приезжал Zibsun и говорил что нынче не надо оценивать таски в часах, хотя за несколько лет до этого говорил другое, этож аджайл, куда повернешь туда и поплыветssova
23.05.2016 17:30этож аджайл, куда повернешь туда и поплывет
Как раз об этом моя статья. Нельзя бездумно перекраивать Agile процесс!
Прочитав ваш комментарий, я представил себе такую картину: сидят члены сообщества Agile за очередной чашечкой кофе и один из них: "А давайте больше не будем считать часы и фокус фактор, а будем считать story points и velocity..." и остальные ему: "Давай, давай, давай".
Правила скрама более продуманны, чем может показаться на первый взгляд.
qadmium
23.05.2016 18:39тем не менее команда нисколько не пострадала, а решение не было бездумным, мы просто выкинули раздражающий и отвлекающий фактор. каждый день мы были вынуждены слушать все, что и так знали. кстати ретроспектива отправилась в ту же топку. скрам ли это после таких изменений? я не знаю, но хуже точно не стало.
>бездумно
бездумно вообще ничего делать нельзя ))
>Правила скрама более продуманны, чем может показаться на первый взгляд.
я знаю насоклько они продуманы, у меня была возможность увидеть как работает та или иная вещь в других командах, и все же посмею утверждать, что они не универсальны, иначе это превращается в серебряную пулю
>Прочитав ваш комментарий, я представил себе такую картину: сидят члены сообщества Agile за очередной чашечкой кофе и один из них: «А давайте больше не будем считать часы и фокус фактор, а будем считать story points и velocity...» и остальные ему: «Давай, давай, давай».
вообще примерно так и было ))
excoder
> Из-за подчеркнутой важности этого элемента скрама, мы всегда его использовали. Но из-за того, что мы не понимали смысла, мы придумывали ужасные цели. Обычно мы просто упрощали процесс выбора цели, задавая негласное правило, брать целью выпуск очередного релиза или реализацию какой-то очередной жирной спринтовой фичи. От этого усиливалось ощущение бесполезности цели, а то и ее вреда.
ПОЧЕМУ нужно выключать мозг и следовать за «серебряными пулями», вместо того чтобы немного подумать и придти к логичным выводам.