Scrum: история Agile-команды, часть 2






Мы задались вопросом, поскольку до этого момента мы всё ещё не пользовались липкими бумажками для планирования. Мы использовали программное обеспечение для отслеживания историй и багов, но ничего больше мы не пробовали. После обеда наш scrum master показал нам гору разноцветных липких листочков для заметок. После того, как он заполнил десяток из них, он объяснил как с ними работать.

Фото с сайта blog.crisp.se

Пользовательские истории

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

Описание истории может звучать примерно так: «В качестве пользователя мне нужна возможность открыть папку с файлами для общего доступа со своими коллегами».

На этом этапе у нас не было определённого product owner, поэтому наш scrum master составлял описание историй сам. Это приемлемо в самом начале, но я категорически рекомендую вам разделить эти две роли! Иначе как вы себе представляете общение scrum master и product owner при планировании спринтов, если это будет одно и то же лицо?

Вы можете подумать: «Зачем вообще им общаться? Не лучше ли сделать так, чтобы один человек решал что нужно сделать и когда?». Нет, не лучше. Две роли, находящиеся в одном человеке, обязательно будут оказывать влияние одна на другую. А вот два отдельных человека уже будут куда более более объективными, направляя команду по верному пути и эффективно достигая конечного результата.

Итак product owner описывает истории, а scrum master обсуждает их выполнение с одной стороны с командой, с другой — с product owner.

Пользовательские истории определяют новую функциональность, которая требуется в приложении и записываются на листочках жёлтого цвета.

Баги, баги, баги

На доске в том числе мы вывешиваем и баги. Видите те красные листочки? Это баги, которые мы должны исправить к следующему релизу.

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

Я знаю некоторые команды разработчиков, которые накапливают баги в течение трёх спринтов, а каждый четвёртый посвящают только исправлению багов. Другие практикуют разделение спринтов по принципу отношения 25% багов к 75% пользовательских историй. Некоторые команды могут работать с историями до обеда, а с багами — после. Короче, кто на что горазд.

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

Задачи или части истории

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

Один из подходов предлагает разбивку больших историй на задачи. Задачи описываются короткими фразами на языке разработчиков. Например, предыдущую историю о предоставлении общего доступа к папке можно разить на следующие задачи: «Создание UI», «Реализация механизма предоставления доступа», «Реализация функциональности управления доступом», «Добавление чекбоксов в UI управления доступом» и т. д. Ключевой момент состоит в том, что всякий раз, когда разбиваете историю на задачи, вы должны всегда держать в голове именно историю. После того, как вы получите большую историю в виде списка задач, ваша команда получит набор кусочков, с каждым из которых будет легко справиться.

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

Технические задачи

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

В нашей команде мы для себя определили что подобные задачи должны быть отделены от историй, которые привели к возникновению этих задач. Такой подход  позволяет лучше отслеживать такие дополнительные задачи. На снимке нашей доски вы можете увидеть такие задачи на листках зелёного цвета. Там есть одна в колонке «Sprint Backlog» и три в колонке «Testing».

Технический backlog.

Этот backlog предназначен для инфраструктурных задач вроде обновления ПО, подготовки нового сервера и всего, что делает наши девелоперские будни легче. Это вещи, которые должны быть сделаны к определённому моменту и которые не имеют непосредственного отношения к разрабатываемому проекту.

В принципе нет уж такой большой необходимости помещать технические задачи в отдельный backlog. Я знаю команды, которые этого не делают. Наша команда перестала использовать технический backlog несколько месяцев назад, поскольку мы пришли к выводу, что инфраструктурные задачи настолько же важны, как и все остальные. Однако, если ваша команда молодая и опыт использования Agile-техник и Scrum в частности у вас небольшой, то лучше всё-таки выделите для техннических задач отдельный мини-backlog. Я советую вам как минимум хотя бы попробовать. Это может работать у вас, а если вдруг нет, то помещайте технические задачи в общую кучу, только выделяйте их отдельным цветом.

Великое испытание: оценка

В течение совещания по планированию мы решаем какие истории и баги из product backlog (в нашем случае — release backlog) могут быть завершены к окончанию планируемого спринта. Это может показаться простым, но на самом деле это довольно сложное занятие.

Product owner выдвигает список историй, которые необходимо завершить в первую очередь. Как правило, в этом списке больше работы, чем можно успеть сделать за отведённое на спринт время. Scrum master вместе с командой должны договориться с product owner о том, какие истории реально могут быть выполнены к концу спринта. Со временем этот процесс упрощается, поскольку product owner начинает лучше понимать с какой скоростью работает команда. Также и команда может становиться более продуктивной с течением времени, получая возможность выполнять больше работы. Очень замечательно иметь команду, которая желает превзойти ожидаемый от неё результат!

Итак, product owner желает, чтобы мы выполнили больше работы, чем мы можем на данный момент. Наша задача, как команды, выбрать из предоставленных  пользовательских историй те, которые мы сможем осилить в срок. Для решения этой задачи можно пойти несколькими путями.

Story point'ы

Story point'ы — один из самых популярных методов оценки историй, багов и задач. Они не обязательно окажутся лучшим подходом в вашем случае, но для начала вам должно этого хватить.

Итак, что же такое story point? В самом начале команда отыскивает самую простую историю, которую они смогут найти на доске. Неважно, насколько она сложна для реализации технически или сколько её реализация займёт времени. Когда они находят такую историю, ей присваивается один story point. В некоторых проектах такая история может быть очень лёгкой для реализации, вроде исправления ошибки в GUI на 10 минут, но может требовать и пары часов от двух-трёх человек. Теперь, когда у вас есть точка отсчёта, вы можете оценить оставшиеся истории.

На практике это может быть куда сложнее, чем в теории. Существует минимум две распространённых системы story point'ов:

  • числа Фибоначчи — 1, 2, 3, 5, 8 (может быть и 13, но это уже слишком огромная история, на мой взгляд);
  • степени двойки — 1, 2, 4, 8 (может быть, 16, но старайтесь избегать такого значения по той же причине, что и в предыдущем пункте).

Выбирайте то, что вам по душе. Будьте гибкими! возможно вы захотите использовать систему с приращением в две stroy point. На здоровье!

Цвета светофора

Числа хороши и для многих технарей являются удобными. Однако в какой-то момент вы можете заметить, как разработчики начинают связывать story point'ы с часами. Типа: «Это займёт у меня два дня, значит это где-то пять story point'ов». Это неправильно! Оценки из плохих станут ещё хуже, когда вы начнёте так поступать. Stoty point'ы никогда не должны соответствовать времени и наоборот.

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

Обычно каждый цвет имеет следующее значение:

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

Размеры футболок

Числа могут показаться вам слишком уродливым решением, цвета — слишком детским. Самое время рассказать вам о размерах футболок! Эта система также поможет вам избавиться от привычки смешивать время на выполнение и оценку сложности задачи. Всё просто: вместо чисел и цветов используйте размеры S, M, L, XL и XXL, когда  будете оценивать ваши истории.

И ещё

Product owner, инвесторы и менеджеры должны знать, что им ожидать по завершению спринта. Им необходимо  принять решение, должны ли истории, над которыми ведётся работа, попасть в релиз, и им должно быть известно, когда запрошенная функциональность будет готова. Внедрение новой функциональности непосредственно перед завершением цикла разработки — плохая идея. Лучшим решением является реализация наиболее важных функций как можно чаще в течение всего цикла. Инвесторы и менеджеры должны точно знать, что из желаемого можно сделать за короткий срок. А поскольку эта информация поступает от команды, последняя должна уметь как можно точнее оценивать объём работы, который они могут выполнить за спринт.

Измерение скорости разработки

Итак, вам интересно увидеть, насколько хорошо вы справляетесь с задачами на текущий спринт? Частенько используемый метод для этого — burndown-диаграмма:

scrum-story-of-agile-team-BurnDown1

На этой диаграмме вы видите пятидневный спринт с расчётом на выполнение 10 point'ов. Каждая точка на графике соответствует количеству story point'ов, оставшихся на конец дня. Зелёная линия отображает идеальный ход спринта, в котором команда ежедневно выполняет по два story point'а. Красная линия отражает реальное положение вещей, то есть скорость, с которой команда работает на самом деле.

Этого графика нет на представленном выше фото нашей доски. Наша команда использует лист формата А4 с burndown-диаграммой каждого спринта, помещая её над доской. Подводя итоги каждого дня, один из членов команды был ответственным за подсчёт количества выполненных story point'ов за тот день. Это очень простая процедура, если учесть то, что разработчики перемещают свои задачи между колонками. Таким образом легко можно подсчитать, сколько point'ов выполнено, а сколько осталось.

Не бывает наполовину выполненных историй. История либо выполнена, либо нет. Если она не выполнена, то она и не учитывается на графике.

И конечно же, вы ошибётесь с оценками! Особенно это касается тех, кто только начинает работать. И, к сожалению, нет способа этого избежать! Нет способа знать заранее, сколько point'ов вы осилите. Ваш первый график может выглядеть подобным образом:

scrum-story-of-agile-team-BurnDown2

Наш первый график точно был похож на этот. Я думаю, мы не выполнили даже и половины из того, на что подписались. Почему? Ну, наверное, потому что оценка — это сложная штука. Неважно чем вы занимаетесь, не имеет значения насколько вы хороши в этом. Когда кто-то просит вас прикинуть насколько сложно сделать что-то, что вы никогда не делали, вам придётся изрядно попотеть, прежде чем вы сможете давать более-менее адекватные оценки. Только без паники! Старайтесь изо всех сил. Со временем вам это будет даваться всё легче. В какой-то момент на коротких спринтах вы сможете достигать точности до 70%. На длинных спринтах точность ваших оценок вероятней всего будет ниже, поскольку у вас будет больше историй, а также больше переменных, которые могут оказаться не тем, чем вы ожидаете изначально.

Всякий раз, когда вы ошибаетесь, меняйте подход к оценке. На следующий спринт возьмите 4 point'а. Например:

scrum-story-of-agile-team-BurnDown3

Снова плохо. Вы были слишком консервативны и теперь закончили раньше. Это обычная реакция команды при попытке подстроиться после предыдущей неудачной оценки. Да, вы снова ошиблись с оценкой, но уже в другую сторону. В чём сдесь проблема? Что вы будете делать после того, как завершите последнюю историю и у вас останется время? Будете делать другую историю? А как вы поместите её на график? Вы не можете перерисовать его заново.

Работая с burndown-графиками, хорошей практикой будет делать среднюю оценку 3-4 последних графиков, чтобы примерно определить количество story point'ов, которые вы можете взять на будущий спринт. Конечно, в самом начале у вас нет такой возможности, поэтому точность ваших оценок будет не такой высокой, как в будущем. Это нормально.

С течением времени ваши графики будут всё больше и больше походить на первый пример. Скорость работы команды будет всё более и более устойчивой.

Скорость?

Этот термин обозначает то, насколько быстро вы работаете. Иными словами: как много вы можете сделать за спринт. Одна из наиболее  концепций Agile заключается в том, чтобы иметь обеспечить постоянную скорость работы команды. При традиционном управлении проектами скорость уменьшается с возрастом проекта. Растущая его сложность приводит к неминуемому снижению скорости.

Методология Aglie направлена на то, чтобы поддерживать скорость постоянной. выпускать продукт часто сейчас и делать то чаще в будущем. Как они это делают? Scrum — один из элементов паззла. Остальными элементами являются техники, который программисты используют, чтобы улучшить процесс разработки. Например, XP (eXtreme Programming), Pair Programming, TDD (Test Driven Development) и т. п. Всё это, собранное воедино, поможет вашей команде стать лучше в разы.

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

Анализируйте прошлые результаты и улучшайте их

После нескольких первых спринтов наш scrum master собрал всю собрал всю команду и начал задавать вопросы. Мы говорили о положительных и негативных моментах, с которыми столкнулись за последнюю неделю. Это, возможно, не всегда и для всех приятно, но это бесспорно важный момент в работе. Сам процесс обсуждения того, что на ваш взгляд пошло неверным путём даёт больше осознанности происходящего. И конечно же, всегда важно знать, что вы сделали хорошо!

Подобные собрания обычно называются ретроспективами. Их задачей является сфокусировать внимание команды на удачных и неудачных моментах, которые произошли за прошедший период. Вот некоторые примеры негативных моментов из моей личной практики:

  • команда слишком много спорила друг с другом;
  • программисты X и Y не сотрудничали в парном программировании;
  • мы слишком долго возились с мелочами X и Y;
  • мы не всегда практиковали парное программирование;
  • мы не написали юнит-тесты для модуля M/

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

Среди позитивных моментов из моей практики ретроспектив можно отметить:

  • мы успели всё сделать вовремя;
  • мы могли общаться без споров;
  • некоторые участники стали более восприимчивыми к чужим идеям и предложениям;
  • мы писали весь код согласно принципам TDD.

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

Часть 1

Часть 3

Источник: Nettuts+