В Scrum итерация работы команды называется "спринт" (sprint). Ее длительность определяется конкретными условиями и требованиями к процессам разработки программного обеспечения и создаваемому продукту. Оптимальной длительностью спринта считается интервал 2 недели, максимально возможной - 6 недель. Не рекомендуется делать его более полутора месяцев, иначе могут возникнуть проблемы с создаваемым инкрементом.
(рис 7.1) Диаграмма спринта
Результатом спринта является инкремент готового продукта (build), который можно передать заказчику для установки на продуктивный информационный ландшафт. Именно в реализации готового инкремента в короткие сроки и с минимальными трудозатратами, который заказчик может использовать и получать от этого определенную бизнес-ценность, заключается вся прелесть и уникальность Scrum в сравнении с альтернативными видами разработки программного обеспечения.
За счет коротких спринтов обеспечивается оперативный ответ Scrum-команде от заказчика. При этом заказчик получает возможность гибко управлять объемами работ и направлять разработку в нужном для себя направлении, оперативно оценивая результат спринта и предлагая улучшения создаваемого продукта.
Улучшения должны фиксироваться и попадать в бэклог продукта. После этого они оцениваются в соответствии с существующими бизнес-приоритетами во всем объеме существующих задач. В следующий спринт попадают задачи, которые имеют самый высокий приоритет.
Каждый спринт представляет собой маленький "водопад". На протяжении спринта делаются все работы по сбору требований, разработке и тестированию инкремента продукта. Объем работ, включенных в спринт (бэклог спринта), должен быть фиксированным. Это позволяет команде давать обязательства на тот объем работ, который должен быть сделан в спринте. Это означает, что бэклог спринта не может быть изменен никем, кроме команды.
Спринт имеет свой жизненный цикл, который, как было сказано выше, похож на классический подход к разработке программного обеспечения в миниатюре:
Сначала выполняется комплексное планирование спринта в два этапа.
В начале каждого спринта проводится его планирование. В этом мероприятии участвуют владелец продукта, ключевые пользователи, Scrum-мастер и команда разработки.Планирование спринта состоит из двух последовательных митингов:
| а) | Первый митинг. Определение целей спринта. Участники: команда, владелец продукта, Scrum-мастер. Цель этой встречи - определить цель спринта и наполнить его бэклог. |
| б) | Второй митинг. Определение способа реализации задач, взятых в бэклог спринта. Участники: команда, Scrum-мастер. Цель этого митинга - определить, как именно будет разрабатываться функциональность для того, чтобы достичь цели спринта и синхронизировать понимание всех разработчиков о том, что именно будет сделано. Именно на этой встрече применяется техника Planning Poker для оценки трудоемкости и продолжительности задач. Если в ходе реализации задач выясняется, что члены команды могут не успеть сделать запланированное, отслеживаемое по диаграмме сгорания задач, то Scrum-мастер, владелец продукта и команда встречаются и выясняют, как можно сократить работы и при этом достичь поставленной цели спринта. |
Разработка инкремента спринта.
Активные участники: команда. Пассивные участники: Scrum-мастер, владелец продукта. Цель - разработка продукта силами команды. Это основной процесс, в рамках которого команда занимает активную позицию, от которой будет зависеть результат их деятельности. Scrum-мастер и владелец продукта готовы помогать и отвечать на вопросы при необходимости.
Остановка спринта.
Остановка спринта производится только в самых исключительных ситуациях. Спринт может быть остановлен до того, как закончится отведенное на него время. Остановку должна выполнять команда, если обоснованно понимает, что не может достичь цели спринта в отведенное на спринт время. Спринт может остановить и владелец продукта, если необходимость в достижении поставленных целей исчезла.После того как произошла остановка спринта, должен проводиться командный митинг, на котором обсуждаются причины остановки. После этого жизненный цикл спринта должен повториться начиная с планирования.
В период проведения спринта каждый день необходимо проводить короткую встречу, называемую "дэйли", для того чтобы все члены команды понимали, кто и чем занимается в данное конкретное время. Продолжительность дэйли - максимум 15 минут. Его проведение предназначено для решения явных и потенциальных проблем. Ведущим этого митинга является Scrum-мастер, который по кругу задает каждому члену команды три вопроса:
Все остальные вопросы и обсуждения должны быть вынесены за пределы митинга и обсуждаться между заинтересованными в его решении лицами.
Если команда достигла достаточного уровня самоорганизации, то участие в этом митинге Scrum-мастера не требуется.
После того как спринт достиг своего завершения, необходимо проводить демонстрацию реализованного функционала и последующий анализ спринта. Активность демонстрации называется "Обзор Спринта" (Sprint review), а анализ спринта - "ревью" или "Ретроспектива Спринта" (Sprint Retrospective).
В назначенное время на Обзор Спринта приходят команда, владелец продукта, ключевые пользователи. В процессе этой активности члены команда рассказывают о поставленных задачах, о том, как они были решены, какие препятствия возникали у них на пути, какие были приняты решения, какие проблемы остались нерешенными, и демонстрируют реализованный функционал, а владелец продукта и пользователи оценивают достигнутый результат.
На Ретроспективе Спринта команда и Scrum-мастер обсуждают ход выполнения процесса, отмечают его достоинства и недостатки, принимают решения о возможной корректировке процесса в целях его улучшения. Scrum-мастер является непосредственным организатором этих мероприятий и отвечает за общую подготовку к нему. Команда помогает ему составить адженду и запланировать расписание выступления. Подготовка к митингу не должна занимать у команды много времени (правило - не более двух часов). Для проведения демонстрации запрещено использовать инструменты типа Power Point. Функционал должен демонстрироваться непосредственно в рабочем программном продукте. Подготовка к митингу также не должна занимать у команды более 2 часов. В следующих главах мы продолжим обсуждение, связанное с рассмотрение отдельных этапов и мероприятий, более подробно. Здесь же необходимо акцентировать внимание на таком важном понятии процессов гибкой разработки программного обеспечения, как цель спринта.
Большинство современных команд сконцентрировано на выполнении запланированных задач спринта, выполнение которых было согласовано с владельцем продукта. Таким образом, возникает потогонная система, основной критерий успеха которой - полностью выполненные и продемонстрированные задачи.
Если какая-то история не сделана - вечный позор разработчикам, которые отвечали за нее, полный провал спринта, катастрофа вселенского масштаба и непрекращающаяся скорбь, инициированные заказчиками работ.
В ответ на это появляется экстремистская реакция самой Scrum-команды. Есть мнение, что в объем спринта нельзя вносить изменения после того, как спринт начался, а это, соответственно, ограничивает заказчика. Но если убрать рамки спринта по времени и объему задач, то мы "скатываемся" к классической, водопадной модели разработки информационных систем.
И первая, и вторая ситуации - это совсем не "гибко". Истина, как это часто бывает в 100% ситуаций, где-то посередине. Для достижения этой середины в Scrum появилось понятие - цель спринта. Это командная установка, определяющая, зачем мы собираемся потратить время и ресурсы спринта, чего хотим достичь с точки зрения инкремента ценности для заказчика. И это не просто набор разрозненных требований. Цель позволяет и предписывает нам быть более гибкими и толерантными, как к небольшому изменению объема спринта, так и к неожиданным причинам, не позволившим нам реализовать то или иное требование в спринте. Успешный спринт - спринт, достигший своей цели. Если мы реализовали ожидания заказчика, пришедшего на демо, то это успех.
Цель спринта - инструмент, дающий нам гибкость в управлении ожиданиями заказчиков и работы команды внутри спринта. Единственное условие - цель спринта не должна меняться в рамках самого спринта.
Теперь более подробно поговорим о мероприятии, которое, по мнению большинства экспертов, является самой полезной практикой гибких процессов. Дэйли, как было отмечено выше, - это ежедневные встречи для синхронизации работ членов команды в единую согласованную командную работу (рис 7.2).
(рис 7.2) Процесс проведения StandUp
Знание о том, чем занимаются коллеги по команде, помогает в:
Длительность дэйли строго ограничена и не должна превышать 15 минут. Эта встреча не предназначена для решения проблем. Все требующие специального обсуждения вопросы должны быть вынесены за ее пределы.
Встреча проводится каждый день всегда в одно и то же время, чаще всего это утро, но в распределенных командах это может быть день или вечер.
Scrum-мастер ведет эту встречу, задавая каждому члену команды по три вопроса:
Каждый член команды должен отвечать на необходимые вопросы.
Важно, чтобы все, отвечая на вопросы, не вдавались глубоко в детали и, боже упаси, уж точно не пытались тут же их решать.
С одной стороны, это кажется не такой уж и большой проблемой, но по факту оказывается, что отвлечение сотрудников от плана встречи приводит к тому, что через какое-то время многие не видят в ней необходимости. В тот момент, когда кто-то углубляется в повествование о деталях, большинство незаинтересованных начинает скучать, погружаться в серфинг социальных сетей посредством мобильных гаджетов и т. д.
Для того чтобы перебороть неправильное развитие Scrum-процесса и направить дэйли в нужное русло, нужно:
Следующим по важности мероприятием является груминг - продолжительная встреча, на которой Scrum-команда вместе с владельцем продукта рассматривает существующий бэклог продукта, а также требования, которые планируется включить в ближайший спринт, добавляет необходимые технические и бизнес-задачи, чтобы зафиксировать направления проектирования или решить необходимые архитектурные вопросы развития продукта и его инкремента. Без регулярного груминга планируемой работы спринт становится громоздким и очень запутанным.
Груминг бизнес-задач - это согласование объема работ, которые нужно выполнить для того, чтобы владелец продукта на ближайшем обзоре был удовлетворен ценностью от реализованного командой инкремента.
Эту активность по возможности необходимо проводить в очном режиме присутствия всех ее участников. В противном случае велика вероятность, что она разрастется во времени.
Груминг стоит проводить до или в начале спринта, с тем чтобы детально разобрать подготавливаемые задачи к реализации разработчиками. Периодичность его проведения должна быть один раз в спринт. Время, затрачиваемое на груминг, должно составлять 10% от общей продолжительности спринта.
Сначала, для вновь собранной команды, на груминг может уходить немало времени. Это связано с "притиранием" разработчиков и владельца продукта друг к другу, более глубинным пониманием бизнес-смысла разрабатываемого программного обеспечения, осознанием деталей и взаимосвязей влияния автоматизируемых процессов и т. д. Но это нужно делать. Как результат появится прогресс в работе над задачами, члены команды уйдут от "слепого" анализа требований к осознанному совершенствованию системы.
После того как количества "перегрумленных" историй хватит на два-три спринта вперед, стоит сбавить темп и уделять грумингу чуть меньше времени. Два-три спринта - это оптимальный интервал для обеспечения полной декомпозиции выполняемых задач. Не больше и не меньше. Если "перегрумить" слишком много задач, то велика вероятность того, что к моменту начала реализации наиболее отдаленных задач их решение будет уже не совсем актуально, а возможно, даже устареет и команда опять потратит время на то, чтобы погрузиться в актуальные условия задачи и принять наиболее правильное техническое решение для ее реализации. Все разобранные на груминге задачи стоит поместить в самую "верхушку" бэклога продукта и постепенно наполнять из него бэклоги спринтов:
Чтобы груминг прижился в операционной деятельности каждой команды, необходимо следовать нескольким простым правилам:
Эти характеристики, в соответствии с которыми задачу можно брать в работу на спринт.
Способ принятия решений (DoD) при проведении груминга о возможности взять задачу в работу - это не догма (в Scrum их практически нет). Этот способ выбирает команда и может изменить его в зависимости от своей "развитости". Могут быть использованы следующие подходы:
Для того чтобы повысить профессионализм проведения груминга, целесообразно использовать методы оценки задач, о которых было сказано в предыдущей главе, - к примеру, метод Planning Poker.
Среди основных ценностей гибкой разработки важную роль играют взаимное доверие и самоорганизация, к развитию и работе над которыми должны стремиться все члены команды. Если люди обижаются, когда другие не соглашаются с их мнением, это означает, что они ставят свое профессиональное эго выше интересов команды. Так бывает в командах, которые стали таковой вынужденно, по управленческому указанию или иной причине. Члены команды используют основные принципы и совершают процедуры, но никто не думает об их основном смысле. Внедрение ценностей Scrum - основная задача Scrum-мастера. Он постоянно должен объяснять и воспитывать, в первую очередь на собственном примере. После того как будут воспитаны несколько лидеров, остальные начнут тянуться за ними.
Груминг бизнес-задач - очень важный этап на пути осознания командой ценности разрабатываемого ими программного продукта, но часто для того, чтобы правильно провести этот тип груминга, необходимо основательно подготовиться с технической точки зрения, то есть разложить по шагам алгоритм реализации сложных требований. А для этого существует груминг технических задач.
Теперь мы добрались до рассмотрения специфичного вида активности, чья значимость, однако, не меньше предыдущих.
После того как становится понятен набор бизнес-задач и способ их реализации, которые должна выполнить команда в рамках текущего и следующих спринтов, целесообразно выполнить декомпозицию наиболее сложных и комплексных из них для того, чтобы все члены команды однозначно представляли себе способ и объем планируемой автоматизации, которая должна быть произведена в рамках реализации.
Если провести параллель с классическим подходом к разработке информационных систем, то эта стадия соответствует стадии технического проектирования. Разница состоит в том, что в водопадной и инкрементальной модели за эту стадию отвечает отдельно выделенный специалист - как правило, технический лидер или системный архитектор, а в Agile ответственность за технический груминг ложится на команду в целом.
В Scrum над проектированием работает группа разработчиков, каждый из которых отвечает за область взятых на себя задач и за их гармоническую интеграцию с задачами коллег.
С одной стороны, это повышает риски создания концептуально целостного продукта, но, с другой стороны, снижает вероятность "остаться вдали" от критически важных изменений, которые происходят постоянно при реализации отдельных задач, выполняемых разными разработчиками из Scrum-команды. Совместное взаимодействие членов коллектива позволяет достичь нужного уровня восприятия информации и во многом закладывает базис активности управления знаниями на нужном уровне понимания.
Правила и советы проведения технического груминга соответствует правилам проведения бизнес-груминга. Очень важно, чтобы на техническом груминге присутствовал владелец продукта или кто-то из его представителей. Любое решение, принимаемое в процессе декомпозиции и принятия технического решения, связано с условиями и факторами автоматизируемых бизнес-процессов.
Чем более глубоко происходит интеграция продукта, команды, владельца продукта и других бизнес-пользователей, тем глубже становится понимание того, что нет требований, которые не оказывают влияние на качество результата их совместной работы. Не важно, о каком виде требований идет речь: функциональных или нефункциональных, их решения в любом случае сводятся к качеству создаваемого программного продукта.
В самом конце каждого спринта наступает момент, когда все члены команды должны продемонстрировать то, что было ими выполнено. Этот этап называется Обзор Спринта.
Эта встреча проводится в заранее запланированном месте, в заранее запланированное время. Цель обзора - показать заинтересованным лицам все, что команда сделала за период спринта. Кажущаяся легкость организации этого мероприятия не должна вводить в заблуждение. Для эффективной демонстрации реализованных задач необходимо потратить немало времени и сил. Отсутствие ясности и прозрачности в организации обзора приводит к тому, что участники этого процесса, кроме членов команды, не понимают статус разработки информационной системы, не понимают ценность реализуемых задач, не понимают, что именно им показывают и для чего это разрабатывается. Чтобы избежать подобных проблем, Scrum-мастер должен с большой ответственностью отнестись к организации этого мероприятия.
Подготовка к обзору не должна занимать у команды более 2 часов. В начале обзора необходимо четко и однозначно озвучить цель прошедшего спринта. Если на обзоре приглашены сотрудники, которые имеют лишь отдаленное представление о разрабатываемом продукте, то следует уделить пару минут, чтобы ввести их в курс дела.
Члены команды рассказывают:
Если в компании есть проблемы с менеджментом встреч, тогда начинать имеет смысл тогда, когда пришли ключевые участники. Не имеет смысла ждать всех. После того как несколько встреч начнутся вовремя с участием лишь одного или двух пользователей, остальные участники поймут, насколько важно приходить вовремя.
Следует соблюдать назначенный план обзора, который необходимо прописать в описании к встрече. Внезапно возникающие хаотичные дискуссии следует пресекать и выносить за рамки встречи так же, как это делается на дэйли.
Обзор - это не только одно из необходимых мероприятий Scrum. Оно несет в себе множество посылов, управление которыми поможет во внедрении и развитии гибких методологий в вашей компании:
На обзоре необходимо соблюдать следующие принципы:
Обзор должно происходить быстро и быть сфокусировано на идее показа реализованной функциональности. Сконцентрируйтесь на создании не столько красивого, сколько динамичного демо. Это поможет приучить всех участвующих к соблюдению заданного тайминга и не отвлекаться на посторонние вещи.
Обзор должно быть ориентированным на бизнес-пользователей и подготовленной командой ценностями. Сфокусируйтесь на том, "что мы сделали", а не на том, "как мы это делали". Технические детали очень важны, но смысл демонстрации в том, чтобы показать реализованную ценность. Технические детали команда должна обсуждать в процессе работы.
Аудитория обзора может сама попробовать разработанный продукт. Возможность "поиграть" с продуктом действует на пользователей вдохновляюще.
Не нужно показывать кучу ошибок и то, как они были исправлены. О них нужно упомянуть, но демонстрировать их не стоит, потому что это заберет у вас много времени и снизит внимание к более важным задачам.
Если команду заставлять проводить обзор, когда у них ничего толком не работает, им будет некомфортно. Команда будет запинаться и спотыкаться, показывая "сырую" функциональность. Это неприятно. Но это действует как горькая пилюля.
В следующий раз команда постарается все доделать к сроку! Команду необходимо приучить к мысли, что обзор придется проводить несмотря ни на что. Если обзор выполнено хорошо, то это оказывает положительное влияние.
Ретроспектива - мероприятие, направленное на систематическое инспектирование и адаптацию Scrum к условиям функционирования конкретной команды. На ретроспективе должна собираться вся команда и обсуждать, каким образом сделать следующий спринт более продуктивным по сравнению с прошедшим.
В основе ретроспективы лежит концепция цикла деминга, PDCA (англ. Plan-Do-Check-Act). Цель ретроспективы - к ее окончанию получить практический план эффективных изменений, но это не план окончательных изменений в процессе - это эскиз эксперимента на ближайший период. Цикл деминга состоит из следующих этапов:
Собственно, сама ретроспектива - это Plan.
Целями проведения ретроспективы являются:
Ретроспектива, как каждое Scrum-мероприятие, должна иметь четкую и однозначную цель. Получить план процессного эксперимента - самая подходящая цель для любой команды, однако многие этого не понимают. На ретроспективе команды порой пытаются придумать какие-то глобальные решения своих проблем и сталкиваются с тем, что не получается это сделать разом. В итоге они застревают в промежуточном состоянии полной неудовлетворенности. Если вы столкнулись с такой проблемой, то необходимо понимание того, что двигаться нужно маленькими шагами, пробуя и проверяя разные подходы к решению проблем, впоследствии выбирая лучший из них. В процессе проведения ретроспективы нужно выработать не план окончательных изменений, а план эксперимента на ближайший период, в ходе которого будут проверены принятые решения в совершенствовании Scrum.
Решение проблем в Scrum - это не праздный вопрос. Невозможно сделать так, чтобы организационный руководитель или эксперт пришел, посмотрел и сказал, что команде надо делать, а что в рабочем процессе стоит изменить.
Во-первых, приходить к команде с готовыми решениями чревато отторжением предлагаемых решений. Этот феномен принято называть "not invented here" (не изобретено здесь). Тут срабатывает природная гордость и упертость человеческой натуры. Даже если разработчики понимают, что предлагаемое решение верное, у них нет уверенности в его работоспособности для их команды, плюс отсутствует "собственническое" отношение к нему. Подобные, не "выстраданные" командой решения имеют низкие шансы на реализацию. Члены команды должны набить собственные шишки проблем и определиться с решением, которое будет оптимальным для всех.
Во-вторых, разработка программного обеспечения - сложная дисциплина. Более того, в каждой компании, которая занимается данной активностью, процессы разработки разные или, по крайней мере, имеют уникальные для их окружения детали. Вряд ли найдется консультант, который, не зная условий и факторов организации конкретного процесса, сможет расписать, как должна работать Scrum-команда при решении определенной задачи в конкретной компании. Только проведя несколько рабочих экспериментов и поняв суть операционных проблем, можно понять, хороша или не очень та или иная практика для данной команды.
Ведущий ретроспективу (поначалу эту роль должен выполнять Scrum-мастер) должен привести команду к конкретным рабочим принципам и договоренностям, которые нужно соблюдать и придерживаться их при работе в спринтах.
Идеи о развитии команды и совершенствовании Scrum рождаются в процессе обсуждения недостатков прошедшего спринта. Ведущий должен следить за тем, чтобы ход обсуждения минусов не перерастал в поиск конкретных виновников. Для достижения целей Scrum более важно понимать, как не допустить подобную ситуацию в будущем и что с ней надо сделать, чтобы минимизировать возможные потери. Споры по поводу идей, несмотря на устоявшееся мнение об их необходимости, на данном этапе бесполезны. В план будут включены только те идеи, с которыми согласны все участники митинга.
В результате обсуждения достоинств, недостатков и предлагаемых идей команда должна приступить к составлению плана, куда должны быть включены не просто итоги обсуждения, а конкретные действия, которые должна выполнить команда, или ее отдельные роли:
Однако не стоит пытаться на конкретной встрече решить все проблемы сразу - для эффективной работы в следующем спринте достаточно плана из 3-6 пунктов. Слишком объемный план может в итоге оказаться невыполнимым, демотивирует команду и точно изменится через короткий интервал времени. В процессе проведения ретроспективы могут возникнуть проблемы, связанные как с Scrum, так и с его участниками:
Групповая дискуссия побуждает всех участников высказываться. Это помогает посмотреть на проблему с разных точек зрения и придумать лучшее решение. Часто справиться с этой проблемой помогает ведущий ретроспективы, который будет следить за тем, чтобы каждый из присутствующих обязательно высказал свою точку зрения.
Стоит еще раз отметить, что формат проведения ретроспективы может быть различным. Ретроспективы - это не единичное мероприятие. Они проводятся регулярно, и по результатам каждого такого собрания выполняется основная цель - создается план на ближайшую итерацию. Если отнестись к этой процедуре профессионально, заранее проанализировать наиболее типичные проблемы, возникающие в ходе ретроспективы, можно создать благоприятные условия развития настоящей самоорганизующейся команды.
В этой главе мы обсудили понятие спринта, которое является центральным для методологии Scrum.
Спринт - это временной интервал, в рамках которого перед командой стоит задача реализовать согласованное количество требований, объединенных общей целью. Спринт, в отличие от обычного рабочего графика, подчинен особым принципам и в своем составе имеет ряд мероприятий, каждое из которых направлено на то, чтобы эффективным образом скоординировать процесс работы над разрабатываемыми командой задачами. Состав работ, длительность спринта фиксированы. Он повторяется до тех пор, пока есть необходимость в разработке программного обеспечения для конкретной организации.
Кроме того, в спринте есть специфические активности, которые направлены на повышение качества процесса и развитие членов команды как активных участников Scrum.
В итоге необходимо отметить, что Scrum требует не просто формального соблюдения предписанных принципов, но постоянного участия в процессе менеджеров, которые своими решениями могут повлиять на направление развития команды.
В следующей главе мы приступим к рассмотрению ключевых артефактов, используемых при работе в Scrum.
Для получения официальных документов о завершении программы дополнительного профессионального образования (удостоверения о повышении квалификации, дипломов о профессиональной переподготовке и MBA) необходимо предоставить:
Внимание! Вы можете не заказывать доставку бумажной версии официального документы, а скачать его в электронном виде и распечатать самостоятельно. Информация о выданном документе в течение 1 месяца загружается в Федеральную информационную систему «Федеральный реестр сведений о документах об образовании и (или) о квалификации, документах об обучении» - ФИС ФРДО.
Доступ на новый сайт осуществляется с использованием адреса электронной почты, который был указан вами при регистрации на "старом". Мы постарались перенести все ваши данные с прежнего ресурса, однако не исключена вероятность потери части информации.
При возникновении проблемы со входом, воспользуйтесь функцией сброса пароля
Если вы обнаружите несоответствия, пожалуйста, сообщите нам.