Содержание


Использование скрам-методов с помощью IBM DevOps Services

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

Comments

Эта статья появилась в ответ на многочисленные вопросы о планировании спринтов и скрам-методах и содержит ссылки на другие ресурсы, которые мы создали или нашли, отвечая на эти запросы. Прежде чем углубиться в тему, давайте окинем беглым взглядом те рабочие скрам-элементы, которые предоставлены в DevOps Services. Тем, кто еще никогда не пользовался скрам-методами, это поначалу может показаться пугающим. Ничего, прочтите эту статью и попытайтесь усвоить столько, сколько сможете. Тем же, кто знаком со скрам-методами и гибким программированием, мы советуем пройтись по всему тексту, чтобы попасть в разделы, где объясняется, как работать с DevOps Services.

Вы заметите, что многие ссылки на терминологию из этой статьи ведут на страницы Википедии. Это не потому, что нам нравится Википедия; просто там много хороших статей с полезными ссылками. Когда я искал материалы, не зависящие от конкретных инструментов, Википедия часто оказывалась лучшим выбором.

Прежде чем начать

Если вы еще не зарегистрировались в DevOps Services и IBM Bluemix™, сделайте это сейчас. Вы сможете следить за нашими примерами и попробовать кое-что самостоятельно. При этом можно использовать:

Тем, кто уже применял скрам-процесс с Rational Team Concert, многое в этой статье покажется знакомым.

У вас есть вопрос по Bluemix?

Спросить в Stack OverflowСпросить в dW Answers

В чем разница между Stack Overflow и dW Answers?

Начало работы с DevOps Services

Зарегистрировавшись в DevOps, создайте проект:

  1. Откройте панель управления DevOps Services и нажмите кнопку Create Project. Откроется диалоговое окно нового проекта.
  2. Дайте проекту имя (например, Sample scrum project) - такое, которое будет четко определять его.
  3. Выберите место хранения исходного кода. Для целей настоящей статьи оно не имеет значения, так как мы будем говорить об общих скрам-методах, а не работать с кодом.
  4. Поставьте галочку в поле Add features for scrum development. Если вы чувствуете тягу к приключениям и хотите поиграть с каким-то кодом, а затем развернуть его в Bluemix, поставьте галочку в поле Make this a Bluemix project.
  5. Нажмите кнопку Create в нижней правой части окна, чтобы создать новый скрам-проект.

Теперь, когда вы создали скрам-проект и видите его в браузере, пришло время настроить его.

В будущем, чтобы добавить в этот проект других членов своей группы, нажмите на ссылку Members на левой навигационной панели и щелкните на значке Invite Members.

Сейчас вам нужно только узнать, как использовать DevOps Services в сочетании с некоторыми общими скрам-приемами. Первое, что нужно сделать, – это решить, сколько времени будет продолжаться каждая из ваших итераций. Итерации называются спринтами. Каждый спринт – это период времени, когда группа занимается разработкой и тестированием кода, и в конце спринта должен быть готов исполняемый код приложения. Он может не поддерживать всех заложенных в проект функциональных возможностей, но работать должен.

Большинство скрам-групп выбирает двухнедельные спринты. Чтобы настроить спринт:

  1. Откройте обзорную страницу и нажмите кнопку Track & Plan.
  2. На навигационной панели слева выберите Sprint Planning. На данный момент у вас нет никаких спринтов - так давайте создадим их.
  3. Нажмите кнопку Add Sprints в окне Sprint Planning. Добавьте четыре новых спринта длиной в две недели.

Нажав кнопку Edit Sprints, вы увидите, как добавлять новые спринты, переименовывать их или изменять сроки своих спринтов. При работе с DevOps Services мы рекомендуем называть спринты по дате их окончания. Тогда заказчики, которые могут быть не знакомы с методами гибкого программирования, смогут сразу увидеть, когда будут реализованы их описания функциональности («истории»). На самом деле их не интересуют спринты или гибкая разработка; им лишь нужно знать, когда ожидать результатов.

В чем разница между Stack Overflow и dW Answers?

Определение своей первой работы

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

Тип рабочего элементаДля чего он используется
История (или «пользовательская история»)Пользовательская история (user story) – это описание некоторых необходимых функциональных возможностей с точки зрения конечного пользователя приложения. Некоторые считают это эквивалентом случая применения (use case).
ЗадачаЗадачи – это однопользовательские задачи, которые выполняются для достижения некоторого четко определенного и ограниченного действия. Истории обычно разбиваются на несколько задач, в совокупности выполняющих работу, необходимую для реализации истории.
ЭпосЭпосы – это истории, которые слишком велики, чтобы поместиться в один спринт. Обычно эпос можно разбить на две или несколько историй.
ДефектДефекты – это ошибки, проблемы приложения. Многие скрам-группы рассматривают их так же, как истории, разбивая на задачи по исправлению конкретного дефекта.
ПрепятствиеПрепятствия – это риски, проблемы и факторы внешней среды, которые мешают выполнению работы. К типичным препятствиям относятся такие вещи, как ожидание должным образом подписанного SSL-сертификата, ожидание готовности оборудования, отсутствие доступа к нужному лицу и т.п.
Элемент приемкиЭлементы приемки указывают, когда изменения, внесенные одной группой, должны быть приняты (и интегрированы) другой – например, обновление базы данных до новой версии.
РетроспективаРетроспективы проводятся в конце каждого спринта и позволяют группе осмыслить, что работает хорошо, а что не очень. Они помогают группе сосредоточиться на непрерывном повышении своей эффективности. В рабочих элементах ретроспектив собираются наблюдения и замечания, сделанные группой во время ретроспективного совещания.
Элемент отслеживания сборкиЭлементы отслеживания сборки используются для отслеживания сборок и их связи с функциональностью, которую они призваны обеспечить. Групп, которые их используют, не много.

Приступим к созданию элементов: пользовательских историй, эпосов, препятствий и элементов приемки для всех своих работ.

  1. Нажмите кнопку «+» в поле backlog, чтобы создать свой первый рабочий элемент.
  2. Введите краткий заголовок или общее описание работы. Не беспокойтесь – позднее вы сможете заполнить его более подробно.
  3. Нажимая на значки под текстом, можно изменить тип рабочего элемента, добавить более подробное описание и т.п. При добавлении рабочих элементов они появляются в журнале предстоящих работ.
Рисунок 1. Кнопка редактирования спринтов, текст первого рабочего элемента и значки для изменения атрибутов рабочего элемента
Кнопка редактирования спринтов, текст первого рабочего элемента и значки для изменения атрибутов рабочего элемента
Кнопка редактирования спринтов, текст первого рабочего элемента и значки для изменения атрибутов рабочего элемента

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

Журналы предстоящих работ – важная часть процесса скрам-разработки. Они содержат всю ту работу, которую вашей группе предстоит выполнить, но за которую она еще не бралась. Если работа еще не запланирована и не отнесена к определенному спринту, значит она в журнале предстоящих работ. Зрелые продукты могут иметь журналы предстоящих работ со 100 или более элементами. В следующем разделе мы рассмотрим, как управлять журналом предстоящих работ.

Что касается рабочих элементов, то здесь важно отметить некоторые детали. Они не требуют особого объяснения, но влияют на то, как ваша группа будет выполнять свою работу. Отображаемые списки (например, журнал предстоящих работ) часто начинаются с высокоприоритетных элементов. Поле discussion используется для обсуждения рабочих элементов и указывает состояние рабочего элемента.

Чтобы спросить кого-нибудь о рабочем элементе, нажмите на значок человечка. Откроется диалоговое окно, где можно выбрать конкретного человека. Когда вы сохраните изменения, он получит по электронной почте сообщение с вашим вопросом и ссылкой на рабочий элемент.

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

Управление предстоящей работой

Посмотрим правде в глаза: несмотря на все старания, мы часто сильно ошибаемся при оценке тех или иных вещей - не по глупости, а из-за недостатка информации. При использовании скрам-подхода важно, глядя на каждую историю в журнале предстоящей работы, оценить ее размер и сложность в баллах (story points). Для оценки историй группы используют различные методы (например, покер планирования). Оценить размер истории очень просто: если вы считаете, что пользовательскую историю можно выполнить за короткий срок, дайте ей низкую оценку, а если думаете, что это займет много времени, – высокую. Со временем вы научитесь лучше оценить объем работы. Всю эту работу можно проделать в том же представлении планирования спринта, собирая по ходу дела все свои решения и обсуждения в составе рабочих элементов.

Оценка пользовательских историй – обычно предмет горячих споров. Некоторые думают, что баллы – это мера риска и сложности, другие, – что это мера трудоемкости, а третьи считают это мерой вложенных усилий. Все зависит от того, что лучше работает в вашем случае. Нам нравится краткий обзор Майкла Тана, посвященный этому вопросу, но есть и другие мнения, например, Майка Кона. Потратьте 30 минут и соберите информацию, погуглив на эту тему.

Оценив относительные размеры своих историй, вы сможете привести в порядок журнал. Нажмите на ссылку Backlog, расположенную в левой части навигационной панели, чтобы открыть список всех своих историй.

Рисунок 2. Пример «причесывания» журнала предстоящих работ
Пример «причесывания» журнала предстоящих работ
Пример «причесывания» журнала предстоящих работ

Теперь можно приступать к «причесыванию» журнала предстоящих работ Перетащите самую важную историю в начало списка. Под ней поместите вторую по важности историю. Продолжайте до тех пор, пока не получите упорядоченный список пользовательских историй.

При нажатии на пользовательскую историю открываются ее детали, которые можно использовать при обсуждении. Перетаскивая истории, будьте внимательны. Если поместить пользовательскую историю поверх другой, то первая становится дочерней по отношению ко второй. Иногда так и должно быть, но если нет, то нажмите на значок "+" слева от описания истории, чтобы отобразить ее дочерние истории. Затем нажмите на значок «x» слева от дочерней истории, чтобы удалить ее из числа дочерних историй. Если поместить историю между двумя другими, то она получает промежуточную оценку.

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

Ранжирование журнала предстоящих работ – важная и регулярная операция. Некоторые скрам-группы делают это один раз за спринт, другие – ежемесячно, а третьи пытаются делать постоянно. Помните, что истории в журнале предстоящих работ нужно периодически пересматривать, чтобы гарантировать точную оценку с учетом изменения условий и приоритетности задач.

Планирование спринта

Теперь подошел черед главной части процесса планирования выпуска программного обеспечения: планирования спринта. Щелкните на ссылке Sprint planning на левой навигационной панели браузера DevOps Services. Слева вы увидите свой ранжированный список предстоящих работ, начиная с высокорейтинговых записей. (Я же говорил, что ранжирование журнала предстоящих работ – важная процедура!) Справа находится пустой список, соответствующий вашему первому спринту. Пользовательские истории и рабочие элементы можно перетаскивать из журнала предстоящих работ (слева) в журнал спринта (справа). Перетащите верхнюю пользовательскую историю.

Вы увидите некоторые изменения. Нажмите на ссылку Team Progress в списке справа. История будет запланирована на первый спринт. Обратите внимание, что на шкале хода работ группы указана, сколько баллов присвоено этой истории и что выполнено 0 из x баллов. Также обратите внимание, что список обновился и рейтинг 1 теперь имеет следующий пункт журнала предстоящих работ.

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

Число баллов историй, которые группа обычно выполняет в течение одного спринта, называется производительностью группы. Для первых нескольких спринтов вам придется оценивать объем работы, который ваша группа сможет выполнить, пока вы не накопите достаточный опыт гибкой разработки и не будете знать свою производительность. Тогда вы легко сможете распределять работу на три-четыре спринта вперед.

Есть масса статей и блогов на тему планирования спринтов. По нашему опыту, наиболее эффективный сценарий – когда группа берет обязательство выполнить за спринт около 60% от своей производительности. Это оставляет время на случай всевозможных неожиданностей, ошибок и других проблем. А также позволяет завоевать доверие и выполнять свои обязательства.

Если группа обнаруживает, что в середине своего спринта она уже почти у цели, можно выбрать из журнала предстоящих работ (или даже из будущего спринта) одну или несколько историй подходящего размера, чтобы выполнить их за оставшееся время текущего спринта. Никто никогда не жаловался на слишком раннее получение функциональности.

Разбивка пользовательской истории

Планирование спринта – только половина дела. Перед вами набор пользовательских историй, которые нужно выполнить в течение спринта. Как это сделать? Разбейте эти истории на отдельные задачи при участии всей группы.

  1. Посмотрите на журнал предстоящих работ спринта. Нажмите на значок Open child task breakdown верхней истории. (При наведении курсора на значки появляются подписи к ним.)
    Рисунок 3. Создание задач для пользовательской истории
    Создание задач для пользовательской истории
    Создание задач для пользовательской истории
  2. Откроется область для ввода всех дочерних задач распределяемой истории. Для создания новой задачи создайте дочернюю пользовательскую историю, щелкнув на знаке «плюс».
    Рисунок 4. Начало ввода рабочего элемента – это назначение задачи
    Начало ввода рабочего элемента – это назначение задачи
    Начало ввода рабочего элемента – это назначение задачи
  3. Определите новую задачу. Обратите внимание на значки под текстом. Чтобы задать тип рабочего элемента, нажмите на крайний значок слева. В данном случае сделайте рабочий элемент задачей. К вашему описанию задачи добавляется некоторый дополнительный текст. Попробуйте другие значки, чтобы ознакомиться с атрибутами рабочего элемента, которые можно настраивать.

    Вы должны усвоить действия с рабочими элементами в пределах спринта. Большую историю можно легко разложить на более мелкие, делая их дочерними элементами этой истории. Но не злоупотребляйте отношениями «родительский-дочерние», используйте их там, где это имеет смысл. Удобно, когда во время совещаний по планированию все смотрят на один и тот же экран, так что вся группа в курсе обсуждаемых компромиссов, и у всех есть данные по оценкам и распределению работ.

    Рисунок 5. Использование значков для задания атрибутов рабочего элемента
    Использование значков для задания атрибутов рабочего элемента
    Использование значков для задания атрибутов рабочего элемента
  4. Работая со своей группой, определите все задачи, необходимые для реализации пользовательской истории. Когда вы закончите, все задачи будут перечислены в столбце Open. Щелкните на стрелке в нижней части первой задачи из списка, чтобы увидеть подробные сведения о задаче. Теперь вы со своей группой можете оценить, сколько усилий потребует решение каждой задачи. При необходимости вы также можете уточнить детали.
    Рисунок 6. Добавление оценок задач
    Добавление оценок задач
    Добавление оценок задач
  5. Пройдитесь по всем задачам истории и проделайте вместе со своей группой те же действия над оставшимися историями спринта.

  6. Планирование спринта почти закончено. Вернитесь и рассмотрите проделанную работу, проверив свои оценки по календарю. Вернитесь к первоначальной странице планирования спринта и нажмите на ссылку Team Progress.
    Рисунок 7. Проверка оценок по спринту
    Проверка оценок по спринту
    Проверка оценок по спринту

Вы увидите суммарную оценку задач в часах, а также количество рабочих элементов, назначенных спринту, и количество баллов историй. Все эти данные представлены как второе число (0/n) в индикаторах хода процесса. Убедитесь, что вы не перегрузили спринт в часах (двухнедельный спринт – это 80 рабочих часов на человека) или в баллах историй. Убедитесь также, что вы не недооценили работу, а если да, то найдите в журнале предстоящих работ дополнительные истории, которые можно назначить этому спринту. Оставшаяся часть времени планирования спринта уйдет на корректировки.

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

Когда начинать выполнять работу?

При всех этих усилиях вы еще не написали ни одной строки кода. Тьфу! Так может подумать тот, кому не терпится погрузиться в работу и приступить к макетированию и кодированию. Планирование – важный момент. Оно помогает сосредоточиться на тех вещах, которые принесут пользу заказчикам и вашему бизнесу. Нет ничего хуже, чем продолжительная и трудная работа над тем, что никогда не будет использоваться или не принесет результата.

Ежедневные скрам-совещания

Теперь, когда все спланировано, пора начинать свой первый спринт. Большинство групп гибкой разработки проводит ежедневные утренние совещания. Ежедневное утреннее (или скрам-) совещание позволяет каждому члену группы кратко рассказать о том, что он делает, что планирует сделать и о любых препятствиях на пути к достижению своих целей. Иногда это называют тремя вопросами (the three questions). Это не совещание по состоянию дел; это способ поделиться техническими новостями, и членам группы предоставляется возможность обменяться информацией, которая может помочь другим. Ежедневные утренние совещания можно проводить разными способами, и есть целый ряд ошибок, которые можно допустить при проведении этих совещаний.

Полезно проводить эти ежедневные совещания перед доской скрам-задач. В DevOps Services это можно делать с помощью представления Team Work. Чтобы увидеть работы своего спринта, перейдите к первоначальному представлению планирования спринта и нажмите кнопку Team's Work на панели навигации слева.

Рисунок 8. Доска скрам-задач с выделенными параметрами просмотра
Доска скрам-задач с выделенными параметрами просмотра
Доска скрам-задач с выделенными параметрами просмотра

Чтобы увидеть свои работы в форме списка, таблицы или блок-схемы, щелкните на значке настроек в верхней правой части представления. Опытные скрам-группы предпочтут просмотр в форме блок-схемы. Глядя на свое представление, вы увидите ряд открытых рабочих элементов (которые еще не начаты) и элементы, находящиеся в процессе работы (которые разрабатываются в настоящее время). Если приглядеться, то в нижней части этого представления можно увидеть горизонтальный ползунок. Прокрутив экран вправо, вы увидите также ряд завершенных элементов. Внесите незначительные изменения на доске задач, которые не повлияют на ход совещания. Можно перетащить рабочие элементы между рядами и изменять атрибуты по мере необходимости.

На утреннем совещании члены уведомляют группу о ходе работ, о своих дальнейших планах и сообщают о любых рисках и препятствиях. Это не только заставляет каждого держать отчет перед группой (не скажет же он: «Сегодня я собираюсь перестать фантазировать на тему расположения игроков на футбольном поле и посмотреть в YouTube видеозаписи про котят»!), но и способствует сотрудничеству между членами группы. Они могут помочь друг другу своими предложениями, рассказать, как можно срезать углы, и помочь избежать известных технических проблем. Нужно создать атмосферу коллективной работы, а не формальной отчетности (группы, состоящей из скрам-зомби).

Завершение спринта

Ближе к концу спринта большинство ваших рабочих элементов будут находиться в столбце resolved скрам-доски. На протяжении всего спринта вы видите индикатор хода работ. Спринт заканчивается демонстрацией программного обеспечения с реализованной новой функциональностью. Когда заказчик подписывает эту реализацию, спринт почти завершен.

Соберите группу для ретроспективного анализа спринта. Создайте в своем спринте еще один рабочий элемент. (Делайте это в начале спринта, чтобы не забыть в конце). Выберите тип рабочего элемента Retrospective. На этом этапе группа отражает то, что получилось хорошо, с чем пришлось бороться и что можно улучшить. Введите эту информацию в раздел примечаний рабочего элемента retrospective. Когда ретроспектива готова, скрам-мастер может потребовать создания новых рабочих элементов для того, что группа может сделать в будущих спринтах для повышения общей эффективности.

Часто этот ретроспективный анализ приводит к историям, которые нужны не конечному пользователю, а самим разработчикам. Иногда это называют техническим долгом (technical debt), но есть разногласия по поводу того, как лучше всего охарактеризовать эту работу. Примером историй, ставших результатом ретроспектив, может служить перепроектирование некоторых частей кода, разработка сценариев автоматизированного тестирования, реализация возможностей автоматизации процессов сборки и выпуска и другие подобные вопросы. Часто эти истории «техдолга» берутся из журнала предстоящих работ, когда группа рано завершает запланированный спринт и может в рамках этого спринта выполнить дополнительную работу.

Заключение

Эта статья содержит краткий обзор того, как скрам-группа может использовать DevOps Services для организации и отслеживания хода планирования и исполнения своих спринтов, ранжирования предстоящих работ и прозрачного планирования, так чтобы все заказчики и члены группы имели единое представление о задачах скрам-группы и ходе их решения во время спринта.

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


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Облачные вычисления
ArticleID=1029777
ArticleTitle=Использование скрам-методов с помощью IBM DevOps Services
publish-date=04082016