sprint goal что это
SCRUM: стоит ли прогибаться под изменчивый мир?
Scrum — методология гибкой работы команды. На сегодняшний день пользуется большой популярностью, применяется во многих крупных компаниях. В этой статье разберемся, когда и при каких обстоятельствах возникла техника, на каких базовых принципах строится ее реализация, что важно учитывать при работе и многое другое.
История появления Scrum
У истоков развития разработки программного обеспечения стоял «водопадный» подход к работе, его использовало большинство команд и делило реализацию продукта на следующие этапы:
Так работали из года в год, пока одна команда новаторов долгое время наблюдала за успешными коллективами: теми, кому удавалось соблюдать дедлайны и делать качественный продукт. В результате у них возникло понимание, что успех кроется в гибкости процесса.
На основе выводов, сделанных по результатам долгих наблюдений, вывели «Манифест гибкой разработки программного обеспечения». В него включили четыре пункта:
В 2001 году они детально описали принципы своей методологии и выпустили книгу «Agile Software Development with SCRUM». На сегодняшний день этот подход считается одним из самых популярных среди разработчиков.
Базовые принципы Scrum
У методологии есть несколько базовых принципов, которые помогают ориентироваться на клиента и давать ожидаемый результат при минимальных ресурсных и временных затратах.
Базовые принципы Scrum:
Scrum-команда
Scrum-команда в большинстве случае состоит из 5-9 человек, реже — из 3-4. В рамках скрама коллектив не может быть больше, потому что усложняется взаимодействие между каждым звеном, что негативно сказывается на эффективности работы.
Состав
В команде есть три основные роли:
Владелец продукта
Владелец — ответственное за разработку лицо. Эту роль занимает заказчик продукта или его официальный представитель. В редких случаях — представитель рынка, на котором впоследствии реализуют запланированный проект.
Владелец отвечает за составление бизнес-плана, в котором отражается ожидаемый экономический эффект. Также в нем он определяет план развития, в котором для каждого пункта рассчитывается коэффициент окупаемости вложений. Еще один важный документ, формированием которого занимается владелец, — список требований, они сортируются по важности.
Если говорить просто, то владелец продукта — центр принятия решения для проектной команды. Он должен быть единственным в рамках проекта, иначе принцип быстрого принятия важных решений нарушается.
Примерный перечень обязанностей владельца:
Скрам-мастер
Скрам-мастер отвечает за соблюдение методологии Scrum в работе: контролирует инициативность и самостоятельность всех членов команды, удовлетворенность получаемыми результатами, атмосферу в коллективе и итоги работы в общем.
Причем важно понимать, что скрам-мастер — это не просто какое-то обособленное лицо, наблюдающее за разработкой со стороны. Он — член команды и должен наравне с контролем принимать непосредственное участие в технической реализации продукта.
Скрам-мастер отвечает за взаимодействие всех членов команды между собой, поддержание работоспособности на высоком уровне, устранение проблем, следованием намеченному графику работ.
Примерный перечень обязанностей скрам-мастера:
Разработчики
Разработчики — те, кто отвечают за техническую реализацию продукта. Как правило, на одну команду приходится 5-9 разработчиков. Первая задача — постановка реально достижимых, прогнозируемых, интересных и значимых целей для каждого спринта.
Вторая задача — достижение поставленных целей каждого спринта в установленные сроки (дедлайн). Достижение цели — растяжимое понятие и определяется в каждом проекте индивидуально. Например, где-то задачу считают выполненной после написания всех кодов, а где-то добавляют еще и окончание тестирования. В общем, все руководствуются собственным видением и опытом.
Ключевые навыки для команды разработчиков — планирование, объективная оценка выполненной работы, умение взаимодействовать с другими членами коллектива.
Примерный перечень команды разработчиков:
Принципы работы Scrum-команды
Успешная работа по методологии Scrum возможна при соблюдении трех принципов:
Процесс работы Scrum-команды
Работа команды, руководствующей методологии Scrum, условно делится на несколько этапов.
1. Планирование списка задач спринта. Каждый спринт начинается с планирования. Все члены команды собираются, оценивают бэклог продукта в целом и выбирают приоритетные задачи, которые необходимо выполнить в рамках текущей итерации. Так формируется список задач (бэклог) текущего спринта.
После этого на основе бэклога оговаривается объем работ и длительность цикла. Также заранее определяют результат: что должны получить по итогам спринта.
2. Проведение регулярных совещаний. Ежедневно или еженедельно команда проводит короткие совещания (не более 15-30 минут). В них участвуют владелец продукта, скрам-мастер и все разработчики. Цель встреч — получить от каждого ответы на три вопроса:
3. Организация скрам-доски. В конференц-зале, где проводятся регулярные совещания, вешается доска, разделенная на три части: «что нужно сделать», «в работе» и «сделано».
В каждой части размещают стикеры разных цветов с основными задачами. По мере выполнения они перемещаются от одной части к другой. Это помогает отслеживать прогресс текущего спринта каждому члену команды.
4. Изменение планов в ходе итерации. Команда должна быть открытой и если один специалист не успевает уложиться в срок, то сообщает об этом владельцу продукта. Он поменяет расстановку задач, оптимизирует рабочее время и поможет уложиться в дедлайн.
То же самое делается и при слишком быстрой работе, когда задачи выполняются быстрее запланированных сроков. Руководитель дополняет бэклог новыми целями по собственному усмотрению, чтобы реализация продукта протекала быстрее.
5. Подведение итогов. После завершения каждого спринта проводится тестирование выполненной части программного обеспечения. В нем также принимают участие потенциальные потребители (фокус-группа). Владелец собирает обратную связь и принимает решения для успешной работы в дальнейшем.
Артефакты Scrum
Scrum-проекты включают в себя три важных документа, их еще называют артефактами:
Журнал продукта
Журнал продукта в самом начале готовит владелец. Документ (артефакт) включает в себя требования, отсортированные по значимости. Первичную версию дополняют разработчики: оценивают стоимость реализации каждого требования.
Бэклог продукта должен включать в себя не только технические аспекты, необходимые для реализации, но и функциональные. Для каждого требования определяется приоритет (например, от 1 до 5). Самые приоритетные описываются детально, чтобы команда смогла оценить их и протестировать.
Владелец продукта обязан не только подготовить журнал продукта, но и предоставить его в оговоренные сроки. В противном случае своевременная реализация проекта невозможна.
Журнал спринта
Как вы помните, в рамках скрам-методологии продукт реализуется мелкими итерациями. Как правило, один спринт — одна функция. Для эффективной работы она разбивается на мелкие задачи так, чтобы на реализацию уходило не больше 2-3 рабочих дней.
Грамотная разбивка функций на задачи позволяет к концу итерации выполнить все необходимое, чтобы определенная часть программного обеспечения работала корректно и представляла ценность для конечного потребителя.
После составления бэклога спринта его оценивает команда разработчиков и сопоставляет с журналом продукта. При наличии существенных отклонений коллектив определяет наиболее приоритетные задачи в рамках текущего спринта и менее важные, которые допустимо перенести на следующую итерацию.
Задача владельца продукта — исключить из бэклога мелкие и незначительные задачи, выполнение которых никак не повлияет на конечный результат работы.
График спринта
График спринта — это расписанный задачами календарь работы в рамках текущей итерации. В нем отображается оставшийся до конца спринта объем работы. Команда регулярно оценивает график и при необходимости оперативно реагирует на какие-либо изменения.
Особое внимание календарю уделяет владелец продукта. По нему оценивается скорость работы и соблюдение дедлайнов. Например, если со временем объем работы не уменьшается, значит, в процессе есть какие-то отклонения и требуется срочная корректировка действий команды.
Как правильно внедрить Scrum-методологию
Для повышения эффективности работы команды необходимо правильное внедрение Scrum-методологии. Допущенные ошибки могут не только ничего не изменить, но и негативно сказаться на продуктивность.
Если вы решились на изменения, проводите внедрение поэтапно:
Кому-то из команды нововведения могут не понравиться. Это естественно, когда люди противятся чему-то новому. Ваша задача — донести до каждого члена команды пользу новой методологии.
Подведем итоги
Scrum — это методология гибкой разработки, основанная на принципах Agile. Ее разработкой занялись в 90-х годах прошлого столетия, а широкую известность она начала обретать в начале 00-х годов. На сегодняшний день скрам используют многие команды, чья деятельность тесно связана с проектами.
Scrum можно внедрить в свою компанию за 6 шагов, но следует тщательно подходить к организации процесса. Специальных знаний от сотрудников методология не требует, здесь скорее вопрос в организации и правильном построении рабочего времени.
При этом не забывайте, что скрам — не волшебная пилюля, если у вас наблюдается постоянный срыв дедлайнов, плохая атмосфера внутри коллектива, внедрение новой техники не решит всех проблем. Поэтому изначально наладьте коммуникации внутри команды, постройте эффективную работу, а затем внедряйте scrum для повышения продуктивности.
Scrum — реальный опыт работы по методологии
В данной статье я привожу обзор организации процесса создания программного обеспечения в команде, в которой работаю. Моя цель – это поделиться опытом разработки и управления командой разработчиков.
Для организации процесса работ над проектом мы решили выбрать популярную методологию Scrum. Отчасти это дань моде, отчасти большое количество публикаций в сети Интернет на тему «Scrum сделал за нас все!».
Какие роли есть в Scrum
С чего обычно начинается разработка программного обеспечения? С идеи: «Как было бы замечательно, если бы у меня было некое ПО, которое делало бы примерно вот это. Было бы просто супер!» Человека, который в команде будет представлять эту идею, называют Product Owner (PO) или Владелец продукта. Product Owner – это тот, кто видит цель продукта или кому кажется, что он видит цель продукта, но важно то, что он может ее сформулировать и начать процесс движения к ее достижению. Цель он формирует в виде списка своих пожеланий (хотелок). Этот список называется Product Backlog Items (PBI). Он постоянно модифицируется в зависимости ситуации на рынке или от разрастающегося аппетита Product Owner’a.
Команда. По Scrum считается, что наибольшая эффективность разработки достигается в том случае, если команда сама будет самостоятельно принимать решения в отношении того, как она будет двигаться к цели. Поэтому основное требование к команде – она должна быть самоорганизующейся и самоуправляемой. Обеспечьте одно это требование, и этого будет достаточно для успеха проекта. Так как требование серьезное, то в команду вводится роль ScrumMaster’a, который следит за тем, чтобы соблюдались правила Scrum.
Что такое спринт и зачем он нужен
ProductOwner сформулировал свою цель в виде некого пункта B, который нужно достичь, начав движение с пункта A. Но пункт B – это не точка, в которую можно попасть, просто нарисовав прямую линию между ней и пунктом А. На самом деле пункт B это окрестность точки, и радиус ее может варьироваться.
Чтобы попасть в эту окрестность, лучше всего разрабатывать ПО короткими шагами (точнее забегами): спринтами. В конце спринта все оценивают, что получается, и корректируют направление движения. ProductOwner всегда в курсе того, что его идеи правильно поняты (а если нет, то это можно скорректировать уже на следующем спринте), и спокоен. Команда знает, что делает то, что нужно, и удовлетворена своей работой.
Как формируется список задач на спринт
В команде спринт длится 2 недели. За неделю ничего не успевается, за месяц все забывается. Поэтому 2 недели для нас самый оптимальный вариант. Первый день спринта уходит на планирование. На ранних этапах на планирование уходило даже 2 дня. Планирование – это процесс, при котором команда берет из списка требований наиболее приоритетные и разбивает на задачи, которые позволяют достичь результата. Каждая задача оценивается в часах. Желательно, чтобы задача не занимала времени больше, чем 4 часа. Если участник команды говорит, что сделает задачу за 5 дней, значит, он понятия не имеет, что нужно сделать.
Общее количество часов в спринте на каждого человека рассчитывается из того, что спринт длится 2 недели или 10 рабочих дней. Это 80 часов минус один день на планирование. Итого 72 часа. Но это идеальные часы. Это значит, что человек ни на что не отвлекается, не ест, не пьет, с места не встает, а только работает и не устает. Во время планирования задача оцениваются в идеальных часах. Но набирается для человека не 72 часа, а 72 часа, умноженные на некий коэффициент, который называется производительностью команды. Обычно это 0.5. Удивительно, но это какое-то магическое число, именно при нем весь спринт сдается успешно. Кто-то из великих сказал: «Возьмите время, которые назвал вам разработчик, умножьте его на два и еще немного прибавьте и получите срок, за который вам программист выдаст результат». И это действительно так.
В Scrum есть несколько рекомендаций в отношении того, как исполнителю оценивать время на задачу. Например, играть в покер. Но мы этим не грешим. Что бы там не говорили, но если какой-то модуль начал делать кто-то один, то он его и будет продолжать наращивать из спринта в спринт. И только он может оценить, сколько ему нужно времени на выполнение задачи. Единственные, кто ему может помешать завысить сроки, это его совесть (помните про самоорганизацию) и ScrumMaster.
Как проверить, что требование ProductOwner’а выполнено
Есть список требований. Но как проверить, достигнуто это требование в ходе разработки или нет? Для этого необходимо написать тесты, в которых будет детально описано то, что считать достижением требования. Просто говоря, в них описано то, на какую кнопку нажать, и что при этом получится. В команде тесты пишут аналитики. И тесты эти должны быть готовы к моменту запуска очередного спринта. У нас в команде аналитики и дизайнеры работают с опережением команды разработчиков на 1 спринт.
Главное требование – тесты должны быть очень подробными.
Что происходит во время спринта
Начинается процесс исполнения спринта. Главная его цель – добиться, чтобы тесты, предъявляемые к требованиям, к концу спринта выполнялись.
Для сплоченного движения команды к цели Scrum предлагает делать ежедневные митинги. Митинг – это когда каждый, стоя у доски с маркером, вычеркивает то, что он сделал вчера и пишет то, что он собирается сделать сегодня.
Это очень мощная практика. Благодаря ей каждый знает, куда движется проект в целом. К тому же когда человек, рассказывает, что он будет делать сегодня, то он автоматически координирует свои действия с другими участниками. Другие участники могут тут же предложить лучшие решения задачи. А еще написанная на доске задача, а по сути — это обещание всем своим коллегам, очень хорошо мотивирует самого исполнителя. Единственное, ScrumMaster не должен забывать объявлять, что начался митинг.
Митинги проводить желательно стоя и длительностью не более 15 минут. Мы начинаем митинги в 9 утра.
Что происходит в конце спринта
Наступает долгожданный конец спринта, обычно это пятница в 16:00, и команда сдает спринт Product Owner’у и всем-всем, кто заинтересован в продукте. Каждый отчитывается по задачам, которые выполнял и рассказывает о том, каких успехов достиг, а также объясняет причины, по которым не удалось достичь цели. Главное правило — никогда не переносите срок сдачи спринта.
Иногда после сдачи спринта делается анализ того, почему что-то происходит или не происходит, и что нужно предпринять, чтобы исправить ситуацию.
А в понедельник все повторяется сначала.
Накопленный опыт
Мы для себя выработали несколько правил, несоблюдение которых приводило к провалу спринта:
• Спринт надо планировать детально, не жалея на это сил. Если что-то из требований непонятно, то надо прояснять требование. Если это не удается сделать, то не надо брать задачу в спринт, а требование отправлять на доработку.
• Ни при каких условиях не брать дополнительные задачи, которые идут вне спринта. А если все-таки «навязали», то согласовать с Product Owner’ом, что будут удалены из спринта другие задачи.
• Количество человек в команде не должно превышать 5-6 человек. Когда наша команда выросла до 16 человек, митинг начал затягиваться на 2 часа. Ввели фиксированное время выступления для каждого и стояли с секундомером. Но тогда человек не успевал донести свою мысль, и митинг превращался в формальность. Поэтому мы просто разделились. Сначала поделились на клиентщиков и ядерщиков, а потом начали делиться по задачам. Т.е. каждая команда делает свою фичу, и в этой подкоманде есть как клиентщики, так и ядерщики. Этот подход используется до сих пор, и для нас он наиболее эффективен.
Вывод
Scrum может быть хорошей отправной точкой для начала движения. В процессе работ некоторые правила могут эволюционировать или отпасть за ненадобностью. Это уже будет решать команда, отношения в команде и сама жизнь. Но правила, которые сформируются на основе Scrum, послужат хорошим плацдармом для достижения командой желаемого результата.
Кто мы?
Команда, в которой я работаю, называется «Юниклауд Лабс». Это дружный коллектив интересных людей, реально болеющих за свое дело.
Вариков Андрей VAndrey
Технический директор ООО «Юниклауд Лабс»
Sprint Goal**
Смысл Sprint в том, чтобы доставить ценность заинтересованным лицам. Однако, простое следование списку Sprint Backlog Item (например, задач), не обязательно приводит к созданию максимально возможной ценности.
…вы на Sprint Planning и вы готовы начать Sprint.
Смысл Sprint в том, чтобы доставить ценность заинтересованным лицам. Однако, простое следование списку Sprint Backlog Item (например, задач), не обязательно приводит к созданию максимально возможной ценности.
Когда команда создает план работ исходя из индивидуальных задач или результатов, легко взять отдельный элемент и работать над ним индивидуально в течение Production Episode. Однако, это снижает возможность инноваций, возникающих в результате коллаборации людей, которые привносят в работу различные точки зрения. Офисные стены могут стать барьерами на пути к непрерывному общению, которое важно для всех разработчиков (участников Development Team) и всей команды в целом. Страдает командная работа.
Команде, возможно, надо частично перепланировать текущий Sprint, чтобы убедиться, что ценность будет создана к концу Sprint.Новая работа может появиться в самый последний момент, и команда должна обновить план. Следование первоначальному плану может привести к тому, что максимально возможная ценность не будет создана. Другое частое явление — в ходе Sprintстановится понятно, что команда не завершит все Элементы Sprint Backlog. Это часто происходит потому, что объем работы, необходимой для завершения Элемента Бэклога Спринта, увеличивается.
Другой сценарий, когда команде для разработки Product Backlog Item (PBI) нужно получить важные технические знания. Разработчикам (или даже Product Owner) может понадобиться технический прототип, чтобы проверить архитектуру или узнать рабочие характеристики технологии. Несмотря на то, что PBI должен идентифицировать такую работу, его неопределенный характер требует, чтобы команда сфокусировалась на получении знаний, а не на завершении всей запланированной работы. Технический прототип становится критическим пунктом для успеха Sprint.
Иногда наибольшая ценность не привязана к конкретному Product Backlog Item. Например, наибольшей ценностью для команды было увеличение дохода за Sprint, и команда посвятила Product Backlog Item этой цели. С другой стороны, иногда большая часть ценности в Sprint связана с одним конкретным PBI.
Следовательно:
Scrum Team привержена достижению короткой формулировки ценности, которую она создает во время Sprint. Она становится фокусом всей работы в течение Sprint.
Вся Scrum Team совместно создает Sprint Goal. Product Owner будет драйвить создание Sprint Goal, потому что он лучше всех понимает следующие шаги к Product Vision и то, как создать Greatest Value. Scrum Team становится привержена достижимой Sprint Goal.
Scrum Team может использовать Sprint Goal для выбора PBI’s в Sprint, но в некотором смысле, Sprint Goal важнее, чем сумма отдельных PBI’s. Sprint Goal создает согласованность между PBI’s, помогая создать ценный Product Increment. Один из хороших первоначальных подходов к формированию Product Backlogсостоит в том, чтобы выразить его в виде списка Sprint Goals, который Product Owner и Development Team вместе уточняют в форме PBI’s.
Участники Autonomous Teams должны быть в состоянии самостоятельно контролировать достижение целей, а в Developer-Ordered Work Plan указано, что Development Teams могут упорядочивать работу в Production Episode так, как считают нужным. Sprint Goal — единственный механизм, как Product Ownerможет влиять на потенциальный порядок, в котором Development Team выполняет свою работу (делая вывод о срочности и важности, которую передает Sprint Goal), но, опять же, только с согласия Development Team.
Во время Sprint Planning, Scrum Team определяет, что она стремится достичь к концу Sprint; короче говоря, это то, для чего создается Sprint Goal. Development Team определяет детали того, как достичь эту Sprint Goal, создавая Sprint Backlog. Если Development Team приходит к выводу, что достичь Sprint Goal невозможно, ее следует посоветоваться с Product Owner. Ключевым результатом Sprint Planning является то, что Development Team в состоянии объяснить, как она достигнет Sprint Goal и как поймет, что та достигнута. Для этого нужно глубокое понимание предстоящей работы, что повышает шансы достижения Sprint Goal за Sprint.
Development Team привержена достижению Sprint Goal. Sprint Goalспособствует объединению Development Team (см. Unity of Purpose), и это служит укреплению доверия заинтересованных лиц к команде.
Sprint Goal должна быть прозрачна для команды; например, помещена на Скрам Доску или использована в другом Information Radiator.
Development Team продолжает держит Sprint Backlog в актуальном состоянии во время Sprint, поддерживая достижение Sprint Goal. Прогресс выполнения Sprint Backlog (как показано на Sprint Burndown Chart) подобен прогрессу на футбольном поле: хотя каждый ярд движения по полю приближает мяч к финалу, ценность приходит только, когда гол забит в ворота. Иногда возможно достичь Sprint Goal, не завершив все SBIs. Это помогает командам справляться с непредвиденными ситуациями и дает Developersгибкость в изменении их рабочего плана каждый день во время Daily Scrum. Например, возникающие препятствия могут поставить под угрозу достижение Development Team всего Sprint Backlog. В этом случае команда автоматически прибегает к Sprint Goal как к «Плану Б», не тратя долгие часы на перепланирование.
Согласно исследованию, проведенному Университетом Карнеги-Меллон, команды, которые заранее готовятся к прерываниям, справляются с ними на 14% лучше. Команды, которые готовятся к прерываниям, завершают задачи, на которые прерываются, на 43% быстрее.
Теоретически возможно постоянное достижение Sprint Goal когда каждый Sprint завершается только часть PBIs. Это должно быть редкостью, потому что Sprint Backlog должен соответствовать Sprint Goal; если этого не происходит, то существует серьезная проблема с Value Stream.
Скорость (см. Notes on Velocity) помогает командам понять, работают ли они все правильно. Sprint Goal помогает командам убедиться в том, что они разрабатывают правильные вещи. Речь идет о понимании того, «почему» команда разрабатывает что-то, для фокуса в случае изменений.
Джефф Сазерленд добавляет, что кроме фокуса Sprint Goalпоощряет Swarming: Можем ли мы стимулировать всех работать над чем-то одним вместе? Он рассказывает:
В Кремниевой Долине в 2007 году компания Palm работала над Web OS, которая впоследствии была приобретена компанией Hewlett-Packard. Каждый Sprint команды хорошо работали, пока через пару Sprints не появилось ощущение, что они уперлись в стену. PBIs не заканчивались. Разработчики были демотивированы и рано уходили домой. Меня пригласили и совместно с Product Owners и Scrum Masters мы провели час, опрашивая членов команды о том, почему они демотивированы. Мы обнаружили, что они не понимают, почему они должны усердно работать над низкоуровневыми PBIs.
Мы провели послеобеденное время, разбирая Product Backlog, показывая четкую связь между историями высокого уровня и иерархией декомпозиции. Как только разработчики поняли, что Sprint Goal было улучшение производительности Web OS на 10%, у них появилась мотивация завершить низкоуровневые истории, и скорость вернулась к норме.
Для разработчиков, и особенно для глубоких экспертов, важно понимать, почему разрабатываются PBI(s).
Sprint Goal обычно имеет отношение к Ценности Продукта. Команда может альтернативно связать Sprint Goal с процессами, например: “выполнять всю работу через парное программирование”, или “появляться вовремя на Daily Scrum каждый день”.
Движение к Sprint Goal мотивирует и вовлекает команду и наоборот, Happiness Metric может быть эффективным инструментом для определения Sprint Goals.
В 2001 году Кен Швабер и Майк Бидл были первыми, кто описал Sprint Goal.