Постигая Agile Грин Дженнифер
Как же достичь такого чувства командной ответственности, чтобы каждый – от младшего разработчика, старшего технического руководителя, scrum-мастера и до владельца продукта – добровольно взял на себя решение неинтересных задач только потому, что заботится о проекте?
Вы когда-нибудь были волонтером? Содействовали проекту с открытым исходным кодом? Вступали в клуб, любительскую спортивную команду, рок-группу, церковный хор? Подумайте о том случае, когда вы присоединились к группе, не имеющей отношения к вашей работе или семье. Зачем вы это сделали?
Вы присоединились к группе и, вероятно, отдавали ей немало своего времени и сил, потому что вас интересовала главная цель ее существования. Если это был штаб избирательной кампании, то вас беспокоила явка людей на выборы. Если футбольная команда – то вас волновала победа (и качественная игра). Так почему же на работе должно быть по-другому?
Все мы стремимся к цели. По меньшей мере, работаем за деньги. Если работа перестает приносить доход, мы прекращаем ею заниматься. У нас есть счета, которые нужно оплачивать, и семьи, которые требуется кормить. Так что, когда нам платят и предоставляют комфортную, безопасную обстановку, в которой мы должны отработать положенные часы, предлагают другие элементарные блага, составляющие рабочую среду, – этого бывает достаточно, чтобы мы приходили в офис и выполняли свои служебные обязанности.
Но достаточно ли этого, чтобы нас по-настоящему волновало создание работающего программного обеспечения?
Если вам довелось работать в недостаточно мотивированной команде, то вы знаете, что ответ будет отрицательным. Дело в том, что многие из нас никогда не трудились в действительно мотивирующей обстановке. Но если вам с этим повезло, то, скорее всего, вы вспоминаете те времена с ностальгией. Когда каждый заботится о создании отличного программного продукта, все вокруг приносит удовольствие: люди больше общаются, меньше спорят (или делают это продуктивно) и, похоже, легче достигают результата.
Существует много способов мотивировать команду: дать возможность поработать с новой технологией или в области, которая интересна, помочь продвинуться по служебной лестнице, платить премии, предоставлять работу на дому. Возможна и негативная мотивация: руководитель будет злиться, кричать (меньше заплатит, уволит). Эти позитивные и негативные стимулы мотивируют отдельных людей, но неспособны объединить команду.
Действительно сплотить может только вдохновляющая цель. Стив Макконел, эксперт и автор работ на тему управления проектами, в 16-й главе своей книги Beautiful Teams дал такое определение вдохновляющей цели:
Если вы копаете канавы, это вас не очень возвышает и вдохновляет. Но если вы копаете канавы, чтобы защитить свой город от врага, то это вдохновляет гораздо сильнее, хотя вы делаете то же самое. Поэтому задача лидера – представить работу таким образом, чтобы люди могли понять, в чем ее ценность.
Почти все программное обеспечение создано командой, а не отдельными людьми. Чтобы команда работала эффективно, нужно мотивировать всех сотрудников. Лучше всего вдохновляет и объединяет высокая цель, не оставляющая никого равнодушным.
Поставка ценности может быть очень эффективной вдохновляющей целью, мотивирующей всю команду. Когда у нее есть эта цель, она искренне верит в нее и готова самостоятельно решать, как ее достичь (и имеет возможность рисковать), команда будет усердно работать, используя имеющиеся инструменты, чтобы устранить любые препятствия на пути к этой цели.
Вдохновляющие цели направлены на ценность, но термин «ценность» может показаться абстрактным или оторванным от реальности. Для agile-команды ценность имеет вполне конкретный смысл: программное обеспечение ценное, если делает жизнь пользователей лучше. Что произойдет, если старший вице-президент сообщит команде: «Мы увеличили ваш доход в третьем квартале на 0,024 %, потому что вы напряженно работали. Отлично, молодцы!» Это не особенно мотивирует большинство разработчиков, даже если среди них есть те, кто оплатил опционы на акции.
Другое дело, если этот же человек придет и скажет: «Обычно я тратил три часа только на то, чтобы разобраться в этих цифрах. А ваше программное обеспечение настолько просто в использовании и так хорошо работает, что теперь я могу сделать все за десять минут. Спасибо!» Это гораздо сильнее мотивирует большинство разработчиков.
Разработчиков – а таковыми можно считать всех членов agile-команды, даже тех, кто не пишет код, – очень воодушевляет гордость мастера. Мы хотим создавать такое программное обеспечение, которое приносит пользу, нравится потребителям и вызывает у них желание заботиться о нем. Мы хотим, чтобы наше ПО работало эффективно и было создано максимально хорошо, так как тратим слишком много времени на споры о дизайне, архитектуре и технологиях. Все это действительно волнует команду. Сделать жизнь пользователей лучше – вот наиболее прямой путь, которым мы поставляем ценность. А это и есть настоящая, честная, вдохновляющая цель.
Этот принцип находится в верхней части списка принципов Agile-манифеста. Обратите внимание на слова, которые мы выделили.
Наш главный приоритет – удовлетворение заказчика посредством ранней и непрерывной поставки ценного программного обеспечения.
Причина, по которой это считается приоритетной задачей, в том, что поставка ценности пользователям – наиболее эффективный способ мотивации команд и движущая сила хорошего планирования спринта.
Начинать с бэклога – это значит начинать с пользователей
Почему мы планируем поставку специализированных функций в спринте, вместо того чтобы двигаться дальше? Потому что работали как команда, чтобы выяснить, какие функции наши пользователи считают наиболее ценными. Именно поэтому владелец продукта так важен – его задача понять потребности пользователей и своевременно информировать о них команду.
Будьте реалистичны в оценке того, что вы можете поставить заказчику
Многих менеджеров посещает безумная идея, что если не подбадривать разработчиков, то они будут бездельничать, выполнять минимум работы и устанавливать длинные сроки. Однако для большинства команд это неверно. Просто в реальности разработчики слишком большие оптимисты. Именно поэтому мы знаем немало проектов, которые завершились с опозданием, и почти не видели случаев, когда они заканчиваются раньше времени. Не пытайтесь втиснуть в спринт слишком много функций. (В конце концов, пользователи должны всего лишь дождаться следующего спринта, чтобы получить рабочее программное обеспечение, которое включает в себя очередной набор функций.) Хороший scrum-мастер помогает команде оценить работу и понять, чем можно заниматься, а чем нет.
Измените план, если это необходимо
Используйте преимущество ежедневных scrum-митингов, чтобы выяснить, действительно ли команда собирается закончить разработку тех функций, которые были запланированы в спринте. Когда необходимо изменить план, команда делает это. Если становится понятно, что не удастся закончить все работы в бэклоге спринта, то команда должна перенести некоторые из них (начиная с наименее значимых) из бэклога спринта обратно в продуктовый бэклог. Scrum-мастер обязан убедиться в том, что все члены команды понимают суть изменений. Пользователи, привыкшие видеть работающее программное обеспечение, меньше нервничают, не дождавшись во время обзора спринта ожидаемых функций, если владелец продукта предварительно их к этому подготовил.
Заставьте всех говорить о ценности
В успешных scrum-командах, как правило, многие понимают, что на самом деле нужно пользователям и что для них ценно. Единственный верный способ добиться этого – сделать так, чтобы каждый член команды понимал, что именно он будет делать для пользователей. Как это облегчит их жизнь? Что позволит им делать то, что раньше было невозможно? Все это действительно важно для agile-разработчиков. Чем больше вы обсуждаете это, тем лучше будет программный продукт.
Ключевые моментыScrum одновременно инкрементальный и итеративный. Инкрементальный – потому что работа разбита на последовательные этапы, а итеративный – потому что команда адаптирует каждый новый спринт к изменениям, которые происходят во время проекта.
Когда успешные scrum-команды говорят, что они мотивированы поставлять ценность, они имеют в виду, что их важнейшая цель – создание программного обеспечения, которое улучшает жизнь пользователей.
Работа владельца продукта заключается в том, чтобы сохранить в команде мотивацию создавать ценность, помогая им понимать пользователей, разбираться в том, что они делают и для чего нужно ПО.
Описание: команда, разрабатывающая приложение для мобильного телефона в небольшой компанииРоджер – руководитель команды, пытающийся использовать Agile
Ави – владелец продукта
Эрик – scrum-мастер в другой команде
Акт IV. Собака ловит автомобиль
С тех пор как Роджер и Ави принесли Эрику новости о том, что стали называть «встречей со стейкхолдерами из ада», они не могли понять, почему он полон оптимизма. Несколько дней спустя все трое отправились после работы в соседний ресторан, чтобы все обсудить.
Эрик спросил: «Как вы думаете, почему все эти менеджеры по работе с клиентами были расстроены?»
У Роджера и Ави не нашлось ответа. Роджер заговорил о том, как команда старалась стать более гибкой, что в его понимании означало возможность приспосабливаться к потоку запросов на добавление новых функций и создание новой продукции каждый раз, когда это необходимо. Ави чувствовал, что потратил много усилий, чтобы «присоединиться» к команде и передать ей массу великолепных идей, высказанных менеджерами по работе с клиентами. Они оба ощущали, что предоставили заинтересованным сторонам именно то, что те просили. «Посмотри, я получил письма, в которых каждый из них просит именно то, что мы им предоставили, – сказал Ави. – Что же их могло огорчить?»
Эрик объяснил, почему он как agile-тренер доволен увиденным, хотя проект столкнулся с неприятностями. Он сказал, что раньше они были похожи на гигантское круизное судно, которому нужно проплыть много миль, чтобы сделать поворот. Теперь же они больше напоминают флот, состоящий из тесно взаимодействующих между собой быстроходных катеров. Пришлось больше общаться, но зато они могут разворачиваться на месте. А еще Ави избежал потрясений и появления некоторого антагонизма между ним и командой, он смог стать ее настоящим членом и успешным связующим звеном между командой и ее пользователями.
Помогая команде в организации эффективных ежедневных scrum-митингов, Роджер уполномочил ее самостоятельно организовывать свою работу согласно меняющимся приоритетам. Но появилась новая проблема, и Эрик объяснил, что это случается со многими командами, преодолевшими первый этап на пути к самоорганизации. Такая команда теперь имеет право эффективно менять направление деятельности. А входящий в состав команды владелец продукта может определять это направление.
Эрик предложил хорошую аналогию: «Вы когда-нибудь видели пожарную команду, которая учится тушить пожар при помощи пожарного шланга? Вам со стороны кажется, будто они просто целятся в огонь. Но они потратили недели или месяцы, пока не научились эффективно двигаться и общаться друг с другом, чтобы действовать согласованно. Раньше ваша команда была как садовый шланг, а теперь как пожарный.
Как мне поступить с зависимостями между задачами в моем плане проекта?
Точно так же, как и сейчас, – вы говорите об этом команде и выясняете ее мнение.
Для командно-административного менеджера проекта, использующего планирование в стиле «вначале детальные требования» и создающего большие диаграммы Ганта, это очень часто возникающий вопрос.
Идея самоорганизующейся команды, где каждый участник решает вопрос о своей следующей задаче перед началом работы, звучит нереально. Часто это происходит потому, что менеджер проекта тратит много усилий на выявление всех зависимостей между задачами. Учебники на тему «Управление проектами» (в том числе те, которые написали мы!) содержат разделы, объясняющие различные типы зависимостей (финиш-старт, старт-старт и т. д.) и то, как их определить и записать при планировании проекта. Так что нет смысла спрашивать, как именно анализ зависимостей проявляется в самоорганизующихся командах.
Почему руководителям проектов необходимы эти зависимости в начале проекта? Потому что они нужны для определения проектной деятельности, разделения задач на части, распределения их последовательности, выбора ресурсов и построения графика проекта. Упорядочить все это можно только одним способом: определив зависимости между отдельными задачами.
Предположим, что, пока член команды работает над задачей в общих чертах, он обнаруживает, что она зависит от другой задачи. Какой ужас! Теперь следующие задачи в плане будут сдвинуты назад, потому что принятая ранее последовательность задач не учитывала эту скрытую зависимость. Это приводит к каскадным задержкам – одной из самых распространенных причин изменения проектных планов. Еще хуже, если команда имеет фиксированный срок. Тогда руководитель проекта должен сделать трудный выбор и провести сложные переговоры о сокращении масштабов в конце проекта. Неудивительно, что менеджеры проектов зацикливаются на зависимостях! Этот сценарий до поры неизвестных зависимостей – распространенное явление, он превращает хорошо продуманные планы в хаос. Казалось бы, полный анализ может дать руководителю ложное чувство безопасности благодаря уверенности, что команда берет на себя просчитанные риски, – и привести к задержкам, которые, как обычно, случаются в самый неподходящий момент. Команда также испытывает ложное чувство безопасности, потому что тратит много времени на размышления о зависимостях, после того как план рассмотрен и распределен по командам.
Самоорганизующиеся команды также выявляют эти связи, но делают это гораздо лучше. Разница в том, что они имеют дело с зависимостями в последний ответственный момент, когда у них гораздо больше информации о задачах и они способны выполнять более полный анализ.
Все это хорошо в теории, но будет ли это работать на практике?
Вспомните пример из предыдущей главы, когда командно-административный руководитель проекта проводил неэффективные ежедневные scrum-митинги и ежедневно назначал задачи каждому члену команды. Идя на собрание, руководитель проекта должен знать все зависимости задач, чтобы распределить задания между сотрудниками. Сравните это с самоорганизующейся командой. Когда один ее участник назначает себе задачу, вся команда активно ищет зависимости во время летучки, а также на всех предыдущих и последующих встречах. Поэтому уже на третьем scrum-митинге любой член команды знает, какие существуют преграды. Каждая из них – это зависимость, которую пытается обнаружить команда. Все ее члены ищут зависимости ежедневно и поэтому находят. В результате они предотвращают многие каскадные задержки, с которыми сталкивается командно-административный проект.
Почему это удается сделать? Когда командно-административный менеджер проекта выполняет анализ зависимостей для проекта на этапе его планирования, один из его наиболее важных инструментов – экспертное заключение. Это беседа руководителя проекта с членами команды, на чьи знания он готов положиться, чтобы помочь избавиться от зависимостей. Когда самоорганизующаяся команда ежедневно контролирует свой план во время scrum-митингов, она использует ту же экспертную оценку, но имеет гораздо больше информации, потому что участвуют все члены команды. Планирование на протяжении всего проекта дает ей гораздо более широкий обзор и позволяет принимать лучшие решения. Самоорганизующаяся команда имеет больше шансов найти критическую зависимость, потому что ищет ее во время проекта. А командно-административная имеет меньший обзор и более скупую информацию, потому что делает анализ за несколько недель или месяцев до начала работы. Улучшенный обзор и высокое качество анализа зависимостей, проведенного в нужное время, – важный источник производительности успешных scrum-команд.
Мне немного дискомфортно от выражения «в последний ответственный момент». Не лучше ли планировать заранее, даже если план придется изменить?
Руководители проектов любят цитировать президента США Дуайта Эйзенхауэра, который сказал: «В процессе подготовки к сражению я всегда находил, что планы бесполезны, но планирование необходимо». Когда вы садитесь вместе с командой и планируете проект, каждый думает о деталях работы и конкретных проблемах, с которыми придется столкнуться в ходе ее выполнения. Даже если расчеты руководителя проекта и команды неидеальны, после удачного планирования команда знает о проекте больше и все лучше подготовлены к работе. Когда происходят изменения, команда выявляет их и получает опыт, позволяющий ей в будущем избежать любых ситуаций, вызывающих проблемы планирования. Так почему бы не планировать заранее и получить эти преимущества, особенно если есть возможность изменить план, когда это будет нужно?
Команда, которая планирует в последний ответственный момент, получает все эти преимущества и многое другое. Это не значит, что она не планирует заранее. Наоборот! Разница в том, что вы заранее планируете крупные работы: задачи в продуктовом бэклоге. Продуктовый бэклог содержит такие задачи (часто пользовательские истории), которые будут понятны владельцу продукта и другим нетехническим специалистам компании. До начала первого спринта команда и владелец продукта должны сесть и договориться о бэклоге спринта, а это требует от них большого продуктового бэклога с точными оценками историй, то есть чтобы они уже фактически составили продуктовый бэклог заранее. Что ж, команда и впрямь уделяет много внимания предварительному планированию!
Вы можете привести пример того, как работает планирование scrum-спринта?
Конечно! Представьте, что вы член традиционной проектной команды, которая работает над проектом, где нужно разработать несколько новых функций, а также провести тонкую настройку производительности. Если бы вы планировали проект, то какую задачу сделали бы в первую очередь? Большинство команд, как правило, начинает с разработки новых функций, а настройку производительности делает в конце проекта. Если вы разработчик, то разработка новой функции кажется гораздо более интересной, дает возможность развития, а отслеживание и исправление ошибок производительности – это трудно и неинтересно, поэтому неудивительно, что такая работа часто располагается в самом конце плана.
Но что если пользователям действительно известны проблемы с производительностью? Что если эти проблемы становятся препятствием для тех пользователей, которые просто делают свою работу, и именно быстродействующее программное обеспечение, а не новые функции сделает их жизнь намного лучше? Значит, команда должна сделать тонкую настройку производительности своим приоритетом. В этом случае владелец продукта, который еженедельно встречается с командой и обсуждает наиболее ценные функции в бэклоге, имеет больше шансов в первую очередь улучшить производительность.
Напомните мне еще раз – какое это имеет отношение к принятию решений в последний ответственный момент?
Когда команда все планирует заранее, она займется тонкой настройкой прежде, чем новыми функциями, только в том случае, если с первого дня знает, что это необходимо пользователям. А если владелец продукта не привык постоянно говорить команде о том, что ценно для пользователей, и члены команды не привыкли слушать, что может произойти, когда владелец продукта в середине проекта сообщит, что пользователям в первую очередь действительно нужны именно эти настройки производительности? Менеджер проекта и команда, скорее всего, «замнут» эту тему, потому что она потребует серьезных изменений и приведет к неразберихе. Они также, вероятно, пожалуются, что бизнесмены, с которыми приходится работать, постоянно меняют свое мнение и будут мечтать о проекте без таких многочисленных изменений.
Такая команда все равно будет работать над внесением этих изменений. Но на их выполнение потребуется больше усилий, а также, как правило, реорганизация проекта. Реальность такова, что почти каждая группа пользователей имеет дело с проблемами, которые постоянно меняются. Такова жизнь. Не стоит думать, что изменения – это из ряда вон выходящее событие. Именно поэтому agile-команды любят использовать фразу «принять изменения».
Негибкое отношение к «планированию наперед» превращает внесение изменений в проект в переговоры между командой и владельцем продукта. А мы уже знаем, что agile-команды ценят сотрудничество с заказчиком выше, чем переговоры по условиям контракта. В переговорах кто-то выигрывает, кто-то проигрывает, и все идут на компромисс. Это не эффективный способ выполнения проекта, он приводит к потере производительности.
В то же время, когда команда сотрудничает с клиентом, все работают вместе и все в выигрыше – ведь каждый признает трудности, с которыми нужно справляться вместе. Планирование в последний ответственный момент поощряет такое отношение, потому что это помогает команде избежать установления произвольных ограничений, которые необходимо будет обсудить позже. Это позволяет команде оставаться открытой к изменениям и дает возможность (может быть, не всегда легко) изменить порядок работы, чтобы достичь меняющихся целей (в отличие от планирования работы и рабочего плана). Это облегчает задачу владельца продукта, который постоянно вовлекает команду в выполнение этих целей.
Предлагаем несколько вариантов действий, которые вы можете предпринять уже сегодня (самостоятельно или вместе с командой).
Если вы работаете с командой, которая уже проводит ежедневные встречи, то попросите всех ответить на три вопроса, которые задаются во время ежедневных scrum-митингов.
Если вы работаете с командой, которая еще не проводит ежедневные митинги, выясните, можете ли вы провести хотя бы одно такое совещание.
Поговорите с вашей командой о последнем ответственном моменте. Напишите список решений, которые вы и ваша команда сделали. Не исключено, что их придется пересмотреть, потому что они были сделаны слишком рано.
Обсудите с командой задачи, которые могут появиться в продуктовом бэклоге. Какую работу вы еще не делаете? Можете ли вы составить список этих задач?
Ниже перечислены ресурсы, которые помогут вам узнать больше об идеях, описанных в этой главе.
Вы можете узнать больше о самоорганизующихся командах и о том, как управлять scrum-проектами, в книге Кена Швабера Agile Project Management with Scrum (Microsoft Press, 2004).
Вы можете узнать больше о планировании scrum-проекта в книге Майка Кона Agile Estimating and Planning (Addison-Wesley, 2005).
Вы можете узнать больше о scrum-правилах, прочитав The Scrum Guide (Sutherland and Schwaber, 2011). Текст можно скачать на сайте Scrum.org.
Здесь мы предлагаем советы для agile-коучей, помогающих своей команде разрабатывать идеи этой главы.
• Одна из самых сложных задач внедрения Scrum – это поиск владельца продукта. Если вы работаете с командой, которая хочет внедрить Scrum, помогите ей найти человека, готового принимать решения в интересах бизнеса и обладающего полномочиями на это.
• Многие agile-тренеры считают, что их scrum-команды сталкиваются с проблемами, потому что выбрали владельца продукта из числа команды. Помогите им понять, что владелец продукта должен иметь полномочия принимать разработанные функции от имени компании.
• Проводят ли команды ежедневные встречи, именуемые scrum-митингами, которые по сути являются обычными статус-митингами? Помогите команде осознать разницу между командно-административным управлением и самоорганизацией.
• Помогите scrum-мастеру понять, что он не несет ответственности за ежедневную работу каждого члена команды и не должен отслеживать, выполнил ли тот свою работу. Помогите команде понять, что роль scrum-мастера состоит в том, чтобы помогать команде правильно выполнять scrum-правила и устранять любые препятствия, мешающие это делать.
Глава 5. Планирование и коллективные обязательства в Scrum
Каждый разработчик должен чувствовать себя комфортно, отвечая за работу, под которой он подписался. А поскольку команда исповедует принцип «это наше общее дело», комфортно должен чувствовать себя каждый ее участник.
Майк Кон[39]
Вы изучили механизмы Scrum и то, как использовать базовые шаблоны Scrum для совместной работы вашей команды. Но есть существенная разница между теорией Scrum и командной разработкой программного обеспечения в ходе реального проекта. Как вы настраиваете свою scrum-команду на то, чтобы добиться успеха? Как вы убеждаете ее членов стремиться к одинаковым целям? Иными словами, теперь, когда вы понимаете, что Scrum – это самоорганизация и коллективные обязательства, как вы управляете своей командой, чтобы обеспечить все это в реальной жизни?
В этой главе вы узнаете о практиках, которые используют многие scrum-команды для планирования своих спринтов. Вы увидите, как пользовательские истории помогут понять, что именно требуется пользователям от программы, и будете использовать очки историй и показатель скорости команды, чтобы определить объем работ, который команда способна сделать в каждом спринте. Кроме того, вы узнаете, как использовать два полезных инструмента визуализации – график сгорания и доску задач, чтобы все члены команды находились на одном и том же этапе.
Также вы поймете, почему этих практик и основной схемы scrum-проекта недостаточно, чтобы достичь «гиперпроизводительности» или «удивительных результатов». Мы вернемся к ценностям Scrum, и вы узнаете, как определить, соответствуют ли ваша команда и корпоративная культура этим ценностям. И что делать, если не соответствуют.
Рис. 5.1. Владельцам продукта часто чрезвычайно сложно угадывать мысли пользователей
Описание: команда, работающая над приложением для мобильного телефона в небольшой компанииРоджер – лидер команды, пытающийся применять Agile
Ави – владелец продукта
Эрик – scrum-мастер в другой команде
Акт V. Не вполне ожидаемая неожиданность
На следующий день вся группа встретилась, чтобы обсудить, как начать двигаться в унисон и внести в проект больше предсказуемости. Они говорили о коллективной ответственности – что это значит на самом деле. Эрик попросил нескольких членов команды вспомнить известные им случаи, когда большое количество пользователей реально работало с их приложениями.
Все оживились и стали охотно вспоминать подобные случаи – стало ясно, что больше всего их радовало, когда созданная ими программа использовалась клиентами. Затем Эрик поинтересовался ситуациями, когда выяснялось, что никто не применяет их ПО. Оказалось, что в прошлом году команда потратила четыре месяца на разработку системы отслеживания пользователей и управления учетными записями, а потом узнала, что старший вице-президент одобрил покупку подобной программы другого разработчика. После этого два человека уволились, а остальные чувствовали себя подавленными. Один из ведущих разработчиков, напряженно трудившийся над этим проектом, с возмущением сказал: «И ведь ничто не мешает этому повториться!»
Роджер подытожил: «Мы счастливы, когда люди используют созданные нами программы, и ненавидим, когда результаты нашего труда выбрасывают. Поэтому необходим способ убедиться, что мы создаем только такое программное обеспечение, которое будет применяться».
После этого оказалось несложно привлечь команду на свою сторону. Роджер объяснил, как проходит планирование спринта и как Ави, работая с ними и пользователями их ПО, добьется, чтобы в бэклог спринта попадали действительно важные вещи. В ходе встречи Ави, Роджер и Эрик поняли, что почти вся команда готова воспринять идею коллективной ответственности и искренне хочет создать программное обеспечение, которое оценят пользователи.
После встречи Эрик, Роджер и Ави собрались, чтобы подвести итоги. Роджер и Ави поздравили друг друга с тем, что наконец получили команду, умеющую совместно размышлять над проблемами. И опять они были весьма удивлены реакцией Эрика: тот выглядел обеспокоенным.
Он сказал: «У вас команда, умеющая планировать спринты, и это здорово. Но это не решает ключевой проблемы – как обеспечить включение в бэклог спринта самых необходимых функций. Ведь если вы будете включать в него преимущественно второстепенные функции, то окажетесь в той же ситуации, что и сейчас, – пользователи будут продолжать жаловаться на отсутствие важных функций и перегруженность ненужными возможностями».
Роджер и Ави отнеслись к этим опасениям со скепсисом, который рассеялся после следующего обзора спринта, проведенного с пользователями. Ави с гордостью перенес последнюю версию сайта Lolleaderz.com на свой тестовый сервер и начал выполнять новую функцию «создавай и достигай», над которой они работали. Она давала возможность пользователям устанавливать критерии для своих друзей, чтобы зарабатывать «достижения», загружая видео. Он установил достижение, названное им «получи козу», воспользовавшись новым редактором достижений. Ави перетащил слово «коза» из списка ключевых слов, используя новый виджет, позволяющий указать, какой будет награда после 500 просмотров страницы, и украсить ее всплывающей анимацией, которую они для этого нарисовали. В конце демонстрации в комнате стало очень тихо.
«Да, похоже, над этим изрядно потрудились, – сказал один аккаунт-менеджер. – Послушай, для чего ты это сделал?»
Они ожидали совсем не этого! Оказалось, что нужна была простая функция для одобрения видео друзей, чтобы те получали звездочку рядом с именем. Но команда неправильно восприняла это несложное требование и создала полноценный редактор критериев достижений со своим псевдоскриптовым языком и сервисной инфраструктурой. Никто из менеджеров не представлял, как продать клиентам эту функциональность. Команда потратила много сил и времени без всякой пользы, но еще хуже то, что бэклог оказался заполнен множеством важных функций, реализация которых оказалась отложенной.
Это было совсем не то, что ожидалось от разработчиков!
После встречи Роджер и Ави вернулись к Эрику, который совершенно не был удивлен. «Как же нам все исправить?» – спросил Роджер.
Ави заявил, что и так старался изо всех сил, стремясь дать другим менеджерам то, чего они хотели. Он поддерживал бэклог, приоритизируя его по ценности функций и передавая в команду. Что еще он мог сделать? Роджер даже не знал, с чего начать, но понимал: если они не внесут какие-либо изменения, то продолжат получать не совсем нужные результаты. Кроме того, произнеся зажигательную речь, Роджер и Ави заставили команду поверить в Scrum, и теперь ее постигло жестокое разочарование. Ави сообразил, что если не изменить что-то прямо сейчас, то команду можно потерять навсегда.
Эрик сказал: «Нужно научиться читать мысли ваших пользователей. Вы должны узнать, как они будут применять программное обеспечение. Но еще важнее понять в конце спринта, нужно ли клиенту то, что вы создали. Если вам все это удастся, то ваше программное обеспечение всегда будет пользоваться успехом».
Роджер был настроен скептически. Он по опыту знал: пользователи редко понимают, чего хотят, пока они этого не увидят. А Ави снова забеспокоился о своем понимании роли владельца продукта.
Он спросил: «Как нам научиться угадывать их мысли?»
Пользовательские истории, скорость работы команды и общепринятые практики Scrum
Стейкхолдеры и пользователи продукта ненавидят непредсказуемость. Если программное обеспечение, предоставляемое по итогам спринта, не похоже в работе на обещания, сделанные командой в начале, то пользователи и заинтересованные лица будут разочарованы, какое бы ценное ПО ни собирались создать разработчики. Другими словами, недостаточно просто предложить максимально ценное программное обеспечение. Вы также должны убедиться, что людей, для которых вы создаете программное обеспечение, не ждут сюрпризы при получении готового продукта.
Необходимо отметить, что приятные неожиданности могут быть столь же вредны, как и неприятные, поскольку порождают ожидания, что ваша команда всегда будет делать больше, чем обещала. Чтобы избежать таких сюрпризов, необходимо выполнить два условия.
Во-первых, в начале спринта команде следует хорошо поработать над формированием у стейкхолдеров правильных ожиданий. А во-вторых, в ходе выполнения спринта она должна держать всех в курсе изменений, вносимых во время ежедневных scrum-митингов. Вот почему присутствие пользователей и заинтересованных лиц на scrum-митинге ценно (хотя и не обязательно). Важно также, чтобы они наблюдали, но не вмешивались. Ежедневные scrum-митинги существуют для планирования работы на следующий день, а не для ответов на вопросы тех, кто не участвует в команде. Не всегда заинтересованные стороны могут принимать участие в scrum-митингах, иногда их и вовсе не следует приглашать. Это нормально. Хорошо, если заинтересованные стороны находят время, чтобы присутствовать, но это не обязательно. Пока владелец продукта будет держать стейкхолдеров в курсе любых изменений в плане, все будут находиться на одном и том же этапе развития продукта в течение всего спринта.
Но все это перестает иметь значение, если команда создает бесполезное программное обеспечение.
Вспомним цитату из книги Кена Швабера, приведенную в начале главы 4. Если вы не добьетесь коллективной ответственности, то не получите Scrum. Но что такое «коллективная ответственность»? Какие именно обещания вы даете как команда в целом?
Коллективная ответственность означает искреннее стремление сделать продукт более полезным. Чтобы программное обеспечение оказалось полезным, вы должны понимать, что делают пользователи ПО. Надо помочь им выполнять свои задачи, и вам следует заботиться об этом больше, чем о чем-либо другом.
Этот принцип включен в Agile-манифест. Задумайтесь, что означают слова «сделать работающую программу» – какой смысл вкладывается в понятие «работающая»? Совсем несложно сделать программу, способную запускаться. Нетрудно создать программное обеспечение, которое выглядит как работающее, но сводит пользователей с ума, если они пытаются применить его на практике. Но создание действительно работающего ПО означает предоставление инструмента, который реально помогает людям решать стоящие перед ними задачи. Наиболее эффективный способ написать востребованную программу – сотрудничать с клиентами. Это еще одна причина, по которой мы ценим работающее ПО выше исчерпывающей документации, а сотрудничество с заказчиком – больше, чем согласование условий контракта.
Пока Agile не изменил мир разработки программного обеспечения, команды нередко выпускали никому не нужные продукты, чему можно привести немало примеров. Практически в любом учебнике конца 1990-х – начала 2000-х годов по разработке программного обеспечения вы найдете ссылку на доклад Standish Group’s CHAOS. В Standish Group начали готовить такие доклады в середине 1990-х, когда стало известно, что огромное количество проектов завершаются неудачей (лишь около трети были признаны успешными[40]). Ежегодные исследования этой компании неоднократно показывали: команды разработчиков имеют основание считать, что многие функции в написанных ими программах не используются. В исследовании 2002 года[41] этот показатель невероятно высок – 64 % (45 % не применяются вообще, а 19 % – редко).
Это могло оказаться шоком для научного сообщества, но разработчики считали такой результат очевидным. На самом деле то, что в отчетах расценивалось как провал, для большинства команд было обычным явлением при разработке ПО. Созданный продукт перебрасывали клиентам в надежде, что кое-что из сделанного будет работать. Многие обсуждения (споры) с пользователями завершались фразой разработчиков «это не ошибка, а особенность нашей программы». Это означало, что программа работает именно так, как было задумано, а клиент должен принимать ее такой, как есть. Такое отношение к пользователям – дурной тон.
Роджер и Ави попали впросак со своим редактором достижений, потому что создали чрезмерно усложненный инструмент для решения простой задачи. К сожалению, команды разработки нередко выпускают менее полезный для клиента продукт, чем могли бы. Для этого явления придуман специальный термин – золочение. Команды стремятся приукрасить программное обеспечение, то есть добавить никем не востребованные функции, причем делают это с самыми лучшими намерениями. Разработчики хотят помочь клиентам и думают, что создают нечто очень ценное. Вполне естественный порыв для разработчиков, любящих свое дело, но в то же время – одна из главных причин тех самых 64 % неиспользуемого функционала.
Еще один фактор появления большого количества неиспользуемых функций – отсутствие тесного взаимодействия с клиентами. Когда время общения пользователей с командой разработчиков сильно ограничено, они стараются затребовать как можно больше новых функций. В результате стейкхолдеры могут включить в план массу функций, которые не будут применяться на практике.
Эффективные agile-команды практически не имеют подобного опыта. В создаваемых ими продуктах лишь немногие (а вовсе не 64 %) функции остаются неиспользованными. Вот почему в этих командах зачастую воспринимают выводы доклада CHAOS как ошибочные. Нередко активные приверженцы Agile стараются поставить под сомнение результаты этого отчета. Так что же позволяет agile-командам создавать столь полезные и востребованные программы?
Agile-команды начинают с попытки узнать, чего хотят их пользователи. У них есть для этого очень эффективный инструмент. Кажущаяся простота такого инструмента, как пользовательская история, обманчива: это краткое описание того, как именно будет применяться программное обеспечение. Большинство пользовательских историй – не длиннее четырех предложений. Команды в основном придерживаются эмпирической закономерности, согласно которой пользовательская история должна помещаться на лицевой стороне стикера размером 7 12 сантиметров.
Многие команды пишут свои истории пользователей в формате Mad Libs по следующему шаблону:
Я как <роль> хочу <конкретные действия, которые я предпринимаю>, чтобы <цель>.
Вот история, которую команда Lolleaderz.com использовала в качестве отправной точки для разработки функции контроля достижений.
Рис. 5.2. История пользователя, написанная на карточке
Эта пользовательская история эффективна, поскольку делает очевидными три важные особенности:
• Кто наш пользователь: «постоянный посетитель сайта, имеющий длинный список друзей».
• Что хочет сделать пользователь: «номинировать видео одного из своих друзей на достижение».
• Почему пользователь хочет это сделать: «чтобы все наши общие друзья смогли за него проголосовать».
Она также имеет название («Номинировать видео на достижение»), которое дает возможность команде легко сослаться на эту конкретную историю, когда о ней заходит речь.
Здесь представлено много информации, упакованной в одну пользовательскую историю. Она подразумевает, что нужно сделать многое: пользовательские интерфейсы для выдвижения и голосования, способ хранения номинаций и голосов, обновление системы, отображающей видео, чтобы можно было просматривать достижения и показывать звездочки, и т. д.
Не менее важно и то, чего в истории нет. Например, в ней ничего не говорится про какой-либо редактор критериев (добавленных командой без необходимости) или иных ненужных функций. Вот почему истории пользователей – эффективный инструмент для борьбы с золочением. Что происходит, когда команда описывает пользовательские истории, прорабатывает их с владельцем продукта (а также пользователями и другими заинтересованными лицами – всеми, у кого есть мнение о данном функционале) и ориентируется на них в ходе разработки? Если они применяют такую процедуру, то вряд ли «раздуют» программное обеспечение лишними функциями.
Истории пользователей также дают командам простой способ управлять бэклогом. У многих эффективных agile-команд в бэклоге содержатся почти исключительно пользовательские истории.
Поскольку каждая из них написана с точки зрения потребителя, владельцу продукта легко анализировать с пользователями и заинтересованными сторонами эти истории, чтобы выяснить, какие из них наиболее ценные. К тому же эти истории очень короткие, что позволяет легко добавлять новые и в любой момент изменять их порядок в бэклоге. А когда приходит время начать спринт, владелец продукта и команда берут несколько пользовательских историй из бэклога для реализации.
Затем команда может обсудить выбранные истории с владельцем продукта, чтобы убедиться, что она правильно понимает смысл каждой из них и сможет проверить корректность ее реализации. После этого большинство команд разделит истории на задачи и оценит длительность их выполнения. Задачи каждой пользовательской истории перейдут в колонку «сделать» доски задач, где будут ждать, когда кто-нибудь начнет работу над ними. Когда кто-то из команды готов взять новую задачу, он выбирает самую ценную из тех, которые способен выполнить, пишет на карточке свое имя и перемещает ее в столбец «в процессе».
Один из способов убедиться в полезности того, что вы создаете, – умение представить себе конечный результат. Разработчик обычно получает большое удовлетворение, когда видит свою работу завершенной. Критерии удовлетворенности пользователя эффективно помогают разработчикам представить, как будет выглядеть законченный продукт, и на каждом спринте оценить, насколько они далеки от завершения. (Некоторые команды рассматривают критерии удовлетворенности как «критерии приемки».)
Критерии удовлетворенности, как и пользовательские истории, кажутся очень простыми, но выполняют сложную задачу. Большинство команд формулируют их для каждой пользовательской истории, вписывая конкретные операции, которые пользователь должен иметь возможность делать с программой, уже после создания такой истории. Обычно критерии удовлетворенности помещаются на задней части той же самой карточки (размером 7 12 сантиметров), что и пользовательская история. Владелец продукта обычно имеет право формулировать критерии удовлетворенности или высказывать свои замечания, если критерии уже сформулированы.
Критерии удовлетворенности для пользовательской истории «достижения» могут выглядеть следующим образом.
Рис. 5.3. Критерии удовлетворенности, написанные на обратной стороне карточки с пользовательской историей
Эти условия имеют значение для разработчиков, потому что помогают им избежать преждевременного празднования победы. Программистам свойственно создавать различные части объекта, но вплоть до окончания спринта не приступать к его сборке. Например, разработчик может нарисовать страницы для номинаций и изменить код, отображающий видео, чтобы можно было добавить звездочку для достижения. Но пока он не свяжет все это воедино, чтобы каждое звено находилось на своем месте, а весь новый код был полностью интегрирован в существующую базу кода, добавление функциональности не будет завершено. Но гораздо эффективнее сделать все сразу, пока различные фрагменты кода свежи в памяти.
Критерии удовлетворенности дают команде конкретное определение понятия «готово». Они позволяют команде и владельцу продукта понять, что обработка истории и ее реализация завершены. История может считаться готовой, только если выполнена вся работа, необходимая, чтобы ее понять, построить, испытать и развернуть. После этого пользователь может открыть рабочее программное обеспечение и проверить, что все критерии выполнены именно так, как описано в обзоре спринта. Пока член команды не может этого сделать, разработка пользовательской истории не считается завершенной и он продолжает трудиться над ней (помните о сфокусированности как одной из ключевых ценностей Scrum?). Когда работа закончена, история на доске задач перемещается из столбца «сделать» в столбец «готово». Дело сделано!
Во время планирования спринта команда совместно определяет, сколько они смогут сделать в текущем цикле, чтобы создать программное обеспечение для поставки по его итогам. Но как именно команда это делает?
У каждой команды свой способ оценивать, какой объем работы она может сделать в спринте. Один из методов оценки пользовательских историй, подтвердивший на практике свою эффективность, – использование очков историй. Очки историй – это способ понять, сколько усилий вам потребуется, чтобы создать функцию для конкретной истории пользователя. Команда выставляет эти очки, сравнивая текущие пользовательские истории с затратами труда на реализованные ранее.
Нет никаких жестких правил, определяющих, сколько баллов (очков) следует присваивать той или иной истории. Некоторые команды назначают от 1 до 5 баллов за любую пользовательскую историю. Максимальное значение «пять» выбрано произвольно. Другие команды дают своим историям от 1 до 10 баллов или используют другие пределы, не меняющиеся от спринта к спринту. Некоторые команды используют числа из последовательности Фибоначчи либо значения экспоненциальной зависимости. Вы можете выбрать любую из работающих схем, при которой все в команде чувствуют себя комфортно. Одна история, оцененная в 3 очка, должна требовать столько же работы, сколько и другая история, оцененная так же. Когда ваша команда оценивает в очках все истории, над которыми она работает, ее члены начинают понимать, на сколько очков они могут выполнить (или «сжечь») историй в текущем спринте. Если ваша команда завершает за один спринт в среднем историй на 25 очков, то говорят, что ее скорость составляет 25 очков историй за спринт.
Команды, как правило, работают с примерно постоянной скоростью, если оценивать по нескольким спринтам. Поскольку до того, как оманда начнет работать, трудно предсказать, какой будет скорость, вы можете использовать прошлый опыт, чтобы точнее спланировать следующие спринты.
Если вы сталкивались с инвестиционными фондами, то знаете, что прошлые показатели не гарантируют будущих доходов. То же самое применимо и к очкам историй. Даже если ваша команда «сожгла» 32 очка в прошлом спринте и 29 в позапрошлом, нет никакой уверенности, что в очередном спринте эти результаты удастся повторить. В каждом конкретном спринте люди могут неправильно истолковывать отдельные истории, сталкиваться с неожиданными техническими проблемами, кто-то уходит в отпуск, заболевает, увольняется и т. д. Но несмотря на это очки историй и скорость команды с течением времени становятся наиболее надежным ориентиром для большинства scrum-команд, и вы сможете воспользоваться им при планировании спринтов.
Сессия планирования спринта при помощи очков историй может проходить так.
1. Начните с самых ценных историй пользователей из бэклога продукта.
2. Возьмите историю из этого списка – лучше самую маленькую, это удобно для сравнения. Затем найдите историю такого же размера из предыдущего спринта и назначьте первой из них то же самое количество очков, какое было у второй.
3. Обсудите с командой, можно ли считать эту оценку точной: обнаружив дополнительные проблемы, работы или технические вопросы, повысьте оценку, и наоборот, выявив упрощающие факторы, такие как повторное использование существующего кода или уменьшение объема необходимой функциональности, – понизьте ее.
4. Продолжайте переходить от истории к истории, пока не наберете достаточное количество очков, чтобы заполнить спринт.
Не перегружайте бэклог текущего спринта. Полезно оставлять в нем запас и нежелательно увеличивать нагрузку сверх той, что имела место в прошлом. Если средняя скорость команды – 28 очков за спринт и на очередной спринт запланировано новых историй на сумму в 26 очков, то вы можете добавить только одну историю размером в 2 очка или две – в 1 очко. Так как разработчики – оптимисты по натуре (так и должно быть, поскольку мы созидатели), команда захочет добавить еще 3 очка, превысив свой план на один балл. Не поддавайтесь этому соблазну: нет более верного способа разочаровать пользователей при следующем обзоре спринта.
Но что делать, если вы впервые взялись за такое планирование? Вам потребуется время, чтобы наработать архив историй и сформировать у команды понимание того, насколько велика трехочковая история. Что ж, тогда для начала вам придется руководствоваться предположениями. Выберите одну историю, которая, по вашему мнению, находится примерно в середине шкалы трудоемкости, и произвольно назначьте ей 3 очка. Затем найдите самую большую историю и оцените ее в 5 очков. Теперь возьмите самую маленькую и назначьте ей 1 очко. Используйте их все в качестве отправной точки для оценки историй и наполнения своего спринта. К концу второго спринта вы будете иметь целый набор историй для сравнения, а также неплохую оценку средней скорости команды.
Как и сами пользовательские истории, очки историй не так просты, как кажутся. Командам легко начать применять их в работе (хотя есть множество нюансов их использования, которые мы здесь не будем рассматривать). Но почему они так эффективны?
Они просты
Новому члену команды легко объяснить, как их применять. Кроме того, их сумма за проект оказывается не очень большой. Это десятки или сотни, но никак не тысячи, что не забивает головы членам команды огромными числами.
У них нет волшебных свойств
Многие разработчики и менеджеры проектов видели немало неправильных оценок, не подтвердившихся впоследствии, и считают, что разработку программного обеспечения просто невозможно оценить более или менее точно. Присуждение очков историй исходя из реального опыта конкретной команды не делает тайны из того, откуда возникла та или иная оценка.
Команда контролирует их
Когда руководитель говорит вам, что вы должны соответствовать жестко заданным требованиям, это воспринимается как давление и увеличивает нагрузку на команду. Но когда команда самостоятельно принимает решение, как ей измерять свою работу и использовать для планирования только отобранные ею методы, такой подход становится для нее ценным инструментом.
Они побуждают вашу команду оценивать свою работу
Когда разработчик впервые попадает в scrum-команду, он, вероятно, впервые начинает открыто говорить об оценках, во всяком случае, его мнением интересуются. Выставление оценок – это навык, и единственный способ улучшить его – практика, которая в большинстве случаев предполагает обсуждение того, сколько сил понадобится на решение конкретных задач.
Разработчики их не боятся
Уже довольно много разработчиков имеют опыт выставления оценок в процессе работы. Затем эти оценки передаются руководителю проекта, после чего устанавливается жесткий дедлайн плана проекта. Подобное никогда не случится с очками историй, потому что они не превращаются в часы или конкретные сроки. Единственная зафиксированная величина – это дата окончания спринта, а запланированный объем работ может быть изменен во время ежедневного scrum-митинга в ходе цикла «обзор-контроль-адаптация».
Они помогают команде выяснить, в чем заключается смысл истории
Если вам кажется, что перед нами пятибалльная история, а я оцениваю ее в 2 балла, то мы, скорее всего, расходимся в понимании ее смысла. После обсуждения[42] может оказаться, что я полагал, будто для этой истории достаточно создания простого инструмента командной строки, а вы считали необходимым создание инструмента с графическим интерфейсом. Хорошо, что мы выяснили это во время планирования спринта. Иначе нас мог ждать неприятный сюрприз уже во время работы, когда двухбалльная история превратилась бы в пятибалльную!
Они помогают всем членам команды стать по-настоящему вовлеченными
Очки историй и скорость команды дают каждому участнику «точку опоры», от которой он может отталкиваться: например, команда считает, что раз в последнем спринте было «сожжено» 26 очков, то одна из его историй заслуживает более высокой, четырехбалльной оценки. Новички нередко склонны уклоняться от участия в подобном обсуждении, но позже выясняется, что в этом случае решения принимаются без них. Когда вы осознаете, что у вас была информация, которая могла бы помочь команде оценить историю в 3 балла, а не в 1 и тем самым избежать ошибки, вы наконец начнете заботиться о планировании спринта и станете по-настоящему вовлеченным в дело.
Диаграмма сгорания – это способ наглядно показать текущий прогресс спринта в сравнении с ранее достигнутой скоростью команды. Вот как можно построить этот нисходящий график на основе очков историй (этот способ также работает с другими единицами измерения, например часами, но мы будем использовать очки историй).
1. Начните с пустого графика. По оси Х отсчитываются даты, начиная с первого дня спринта и заканчивая последним его днем. По оси Y – очки историй с максимумом примерно на 020 % больше, чем общее количество очков в бэклоге спринта. Поставьте первую точку на графике: количество очков в спринте в день начала работы. Нарисуйте прямую («направляющую») линию от стартовой точки до конца периода – ноль очков должно остаться к моменту завершения спринта.
2. Как только первая пользовательская история завершена и перешла на доске задач в колонку «сделано», нарисуйте следующую точку на графике: количество баллов, оставшихся в спринте на текущий день. По мере завершения вами следующих историй и «сжигания» большего числа очков историй бэклога заполняйте последующие дни в этом нисходящем графике.
Рис. 5.4. Диаграмма сгорания в момент начала спринта. Мы создали этот нисходящий график, используя очки историй, но вы также можете испльзовать часы, дни или иные единицы измерения
Рис. 5.5. «Сгорели» две истории на сумму в 7 баллов
3. Во время ежедневного scrum-митинга вы можете обнаружить, что необходимо увеличить объем работ. Иногда вы будете делать это, так как команда «сжигает» больше баллов, чем она ожидала, и в результате работы будут закончены раньше срока окончания спринта. Или появится новая важная задача поддержки, и при этом команда и владелец продукта согласятся, что она должна быть добавлена в спринт, но объем необходимой работы пока неизвестен. Поэтому команда не знает, сколько работы надо убрать из спринта, чтобы его сбалансировать. При добавлении карточки данной работы на доску задач запланируйте встречу команды, чтобы оценить в баллах (очках историй) каждую задачу и добавить их в диаграмму. Полезно также провести дополнительную линию, которая будет показывать момент, когда новые пункты были добавлены к графику, – не бойтесь оставлять на диаграмме свои заметки!
Рис. 5.6. Владелец продукта добавил пользовательские истории в середине спринта
4. По мере приближения к окончанию спринта «сгорает» все больше очков, что отражается на графике. Следите за интервалом между направляющей и вашим текущим «сгоранием», потому что он может означать, что в спринте осталось слишком много очков историй и какую-то из них нужно убрать.
Рис. 5.7. Интервал между диаграммой сгорания и направляющей означает серьезный риск не успеть закончить все истории к концу спринта
Существует много программных решений для управления бэклогом, историями пользователей и очками историй, которые могут строить диаграммы сгорания автоматически. Однако многие команды предпочитают рисовать диаграммы сгорания вручную и размещать их на той же стене, что и доску задач. Это наглядно демонстрирует всем, как ведет себя проект в ходе спринта. Разработчикам особенно приятно видеть, как график обновляется сразу после завершения ими очередной истории пользователя и перемещения ее карточки в колонку «сделано».
Планирование и выполнение спринта с использованием историй, очков, задач и доски задач
Планирование спринта проводится, чтобы сформулировать развернутые ответы на два вопроса.
• Что команда поставит заказчику в этом спринте?
• Как команда сделает эту работу?
Мы только что продемонстрировали, как можно использовать очки историй и скорость команды для определения, что будет включено в спринт. Это распространенный способ, при помощи которого scrum-команды выполняют первую часть планирования спринта. Но каким образом они определяют ответ на второй вопрос?
Один из самых распространенных для scrum-команды способов спланировать свои действия – это добавить карточки индивидуальных задач разработки. Это могут быть любые задачи, которые выполняет команда: написание кода, создание дизайна и архитектуры, разработка тестов, установка операционных систем, проектирование и создание баз данных, развертывание программного обеспечения на рабочих серверах, проведение юзабилити-тестов и всех прочих действий, которые команды выполняют повседневно в процессе сборки и выпуска программного обеспечения.
Вот примерная последовательность действий команды.
1. Команда проводит вторую сессию по планированию спринта. Scrum-мастер берет первую историю и обсуждает с командой, что они должны сделать, чтобы ее выполнить.
Рис. 5.8. Вторая половина сессии по планированию спринта состоит в разбивке историй на задачи, которые члены команды будут выполнять во время спринта
Команда составляет список индивидуальных задач с таким расчетом, чтобы каждая занимала не больше одного дня. Все задачи при этом выписываются на отдельные карточки. Некоторые команды используют карточки различных цветов для историй и задач, чтобы легче отличать их друг от друга. Карточка пользовательской истории размещается на доске рядом с карточками ее задач. Процедура продолжается, пока не будут спланированы все истории. Если время планирования спринта истекает прежде, чем все истории разбиты на задачи, то каждая незапланированная история получает отдельную карточку с заданием «спланировать историю».
2. Истории и их задачи группируются и добавляются в колонку «сделать» на доске задач.
Рис. 5.9. Карточка каждой пользовательской истории, включенной в спринт, группируется вместе с карточками своих задач и добавляется в колонку «сделать» доски задач.
3. Когда член команды завершает задачу и готов двигаться дальше, он перемещает карточку выполненной задачи в колонку «сделано». Затем он вытягивает следующую карточку из колонки «сделать», пишет на ней свое имя и клеит ее обратно на доску в колонку «в процессе». Если история все еще находится в колонке «сделать», то он также перемещает ее в колонку «в процессе» (но не пишет на ней свое имя, потому что кто-нибудь из коллег по команде может работать над задачами для той же истории).
Рис. 5.10. Каждый член команды одновременно работает только над одной задачей, указав свое имя на ее карточке и перенеся ее в раздел «в процессе» доски задач
4. По мере того как продвигается работа над спринтом, команда переносит задачи из колонки «сделать» в колонку «в процессе» и затем – в «сделано». Нередко члены команды обнаруживают, что им необходимо выполнить дополнительные задания, чтобы закончить историю. Когда такое происходит, новая задача заносится на доску, а член команды сообщает об этом на ежедневном scrum-митинге, чтобы все понимали ситуацию и могли помочь определить потенциальные проблемы.
5. Как только член команды заканчивает последнюю задачу в истории, он снимает карточку задачи с доски, проверяет, выполнены ли все условия, и переносит ее в колонку «сделано» так, чтобы она располагалась рядом со всеми своими задачами. (Но помните: история не считается «сделанной» до тех пор, пока владелец продукта не примет ее для передачи заказчику от имени компании!) Если он обнаружит, что один из критериев удовлетворенности не был выполнен, – он перемещает историю обратно в столбец «сделать» и добавляет задачи, позволяющие завершить эту работу и переместить историю в колонку «сделано».
Рис. 5.11. Когда член команды заканчивает задачу, он перемещает ее в раздел «сделано» доски задач и берет следующую задачу. И если все условия удовлетворенности выполнены, то карточка пользовательской истории тоже перемещается в раздел «сделано»
6. Спринт выполнен, когда его временные рамки исчерпаны. Однако при этом могут оставаться карточки историй и задач, находящиеся в столбцах «сделать» и «в процессе». Эти истории возвращаются назад, в бэклог продукта, и могут быть объявлены приоритетными в следующей сессии по планированию спринта[43]. При этом команда может уменьшить назначенное им количество баллов в зависимости от числа задач этой истории, которые остались невыполненными. История не засчитывается команде как выполненная, пока ее карточка и все карточки ее задач не будут перемещены в столбец «сделано».
В упоминавшейся книге по Scrum Кена Швабера Agile Project Management with Scrum ничего не говорится о пользовательских историях и очках историй. Многие команды узнали о них из других источников, например книги Майка Кона «Пользовательские истории. Гибкая разработка программного обеспечения» (о которой мы говорили в главе 4).
Есть много замечательных практик, которые команды используют, чтобы улучшить свой уровень владения Scrum. Это не должно вызывать удивления. Мы применяем прошлый опыт, чтобы улучшить текущие разработки. Если мы решим ограничиться тем, что один человек написал в своей книге, и откажемся расширять свои горизонты, то нет смысла искать пути совершенствования.
Именно поэтому многие команды используют дополнительные техники и методы, которые Кон назвал общепринятой практикой Scrum (Generally Accepted Scrum Practices – GASPs)[44]. Например, многие команды приходят к выводу, что ежедневные scrum-митинги более эффективны, если проходят в виде standup-совещаний (когда все участники стоят, а не сидят). Этот прием не относится к числу основных scrum-практик, но широко применяется scrum-командами.
Вспомните последний принцип Agile-манифеста:
Команда постоянно ищет способы стать более эффективной путем настройки и коррекции своих действий.
Вы и ваша команда должны помнить об этом, когда проводите ретроспективные обзоры. Попробуйте найти пути для улучшений, не пытаясь изобретать велосипед. Если вы сталкиваетесь с проблемами в Scrum, то наверняка кто-то уже нашел их решение. Хороший наставник (например, такой как Эрик для Роджера и Ави) наверняка поможет найти решение, которое устранит проблему.
Ключевые моментыПользовательская история помогает команде понять желание клиентов, объясняя их специфическую потребность, а также то, как программа будет ее удовлетворять.
Каждая пользовательская история имеет критерии удовлетворенности, которые помогают команде понять, что история реализована.
Команды применяют очки историй и скорость, чтобы оценить, сколько историй они могут включать в каждый спринт.
Публичное размещение диаграммы сгорания работ помогает каждому из участников команды всегда быть в курсе того, что завершено, что требует доработки и укладываются ли они в график.
Описание: команда, работающая над мобильным приложением для телефона в небольшой компанииРоджер – руководитель команды, пытающийся использовать Agile
Ави – владелец продукта
Эрик – scrum-мастер в другой команде
Читать бесплатно другие книги:
