Story points scrum что это

Story Points

Одна из самых важных сторон методологии Scrum – так называемые Story Points. Эта сторона очень плотно интегрирована в Scrum совместно с технологией Planning Poker.

Самая частая проблема в работе Scrum Team – это неумение правильно оценивать сложность работы и временные затраты на её выполнение. Из статьи про Burndown Chart можно увидеть, как будет строиться график сгорания, если неправильно оценить ту работу, за которую берётся команда.

Для многих действительно тяжело выработать правильную шкалу оценок, и здесь нужен опыт или хитрый подход. Для максимально эффективного и быстрого внедрения Story Points в жизнь команды нужно взять уже отработанные задачи с прошлых проектов и провести их полный анализ. В данный анализ должны входить названия задач, которые выполнялись, и их продолжительность. Дальше всё проще простого: необходимо расположить эти задачи в порядке возрастания, отсортировав по времени. Разделить на группы с одинаковыми или близкими показателями и проставить оценки из вашей колоды карт Scrum Poker.

Рано или поздно использование такого подхода сделает из вас классную и прогрессирующую команду, что и есть единственно верное направление. Постоянно модернизирующаяся команда, всегда будет разгонять свой Velocity и радовать своих заказчиков успехами.

Что же происходит на самом деле при Story Points?

Когда Scrum Team способна оценивать свою работу, ведет график Velocity, следит за «Диаграммой сгорания задач», рано или поздно (или с самого начала работы) абсолютно все оценки будут вестись в Story Points.

Например, по графику Velocity можно увидеть, что динамика команды по среднему разгону за каждый Sprint идет вверх, и среднее значения за последние две итерации составили 23-30 Story Points (зависит от выбранной системы оценок). Глядя на эти показатели Product Owner может видеть, на какие задачи потратить доступные очки, чтобы заполнить Backlog.

Правильная оценка и использование Story Points действительно творят чудеса, ведь они связывают между собой работу всей команды: Development Team ощущает, на что она способна Scrum Master видит, есть ли проблемы у команды и что можно ещё улучшить, а у Product Owner не возникает вопросов, сколько и какие задачи вкладывать в Backlog на текущий Sprint.

Planning Poker

Velocity

Оценка Story Points, а точнее их количество, в глобальном масштабе происходит с помощью Velocity. Та скорость, которую развивает команда по формуле расчитывается в данном графике.

Development Team

Именно команда разработки решает сколько нужно взять в работу задач исходя из количества Story Points выполняемых за спринт. Указывать как работать команде не может никто, однако помогать работе должны все. Такой подход дает маскимальный эффект.

Scrum Master

Product Owner

Владельцу продукту / Product Owner важно знать на что способная команда по Story Points. От этого зависит как лучше распределить задачи, чтобы потом необходимые вошли в Sprint Backlog и не вышли за пределы Story Points.

Product Backlog

Scrum Sprint

Во время спринта и сгорают все заявленные Story Points. По ним рассчитываются различные диаграммы, например это может использоваться в Диаграмме сгорания задач. Успешность Sprint зависит от правильной оценки Story Points.

Понимание относительных оценок в Agile. Даёшь Story Points!

В своей работе со Scrum-командами, я столкнулся с непониманием членов команды, как правильно оценивать задачи или user story. Из этого и родилась потребность в написании статьи, с помощью которой (я надеюсь), я смогу уложить знания в своей голове, лучше объяснять методику командам, а также помочь всем, кто будет ее читать эффективно и быстро оценивать задачи в своих проектах.

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

В старой последовательной «водопадной» методологии разработки программного обеспечения и продуктов, где нельзя начать следующий этап без завершения предыдущего, существовало классическое деление на отделы: отдел разработки, отдел дизайна, отдел аналитики и т.д. Таким образом, техническое задание, пройдя через отдел архитектуры, аналитики, разработки (последовательность и наполнение зависели от организационной структуры и размера конкретной организации), обрастало деталями, дополнительными требованиями, архитектурными изысканиями и тому подобными артефактами. Финально получалась оценка в человеко-днях (или man day — md, терминология использовалась у одного из моих бывших работодателей). Считалось, а где-то до сих пор считается, что данный подход позволяет получить детальный бюджет проекта (смету) с точными абсолютными трудозатратами, на основе чего верстался портфельный бюджет и закладывался весь бюджет организации.

Однако, у данного подхода есть ряд существенных недостатков:

Как итог: у нас нет времени для детальной и точной оценки, но и ценности в этой оценке, по большому счету нет. Наша основная цель: понять сколько задач команда может взять в итерацию (спринт), для этого нам точно подойдет относительная оценка и дальше я расскажу, что же она из себя представляет применительно к гибким методологиям.

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

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

Сможете сходу назвать диаметр такой планеты, как Уран?

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

Кто-то решит, что 22 750

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

Когда мы сравниваем объекты между собой, оценка становится проще и в команде возникает меньше споров и противоречий.

В этом и есть разница и проблема между абсолютной и относительной оценкой.

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

Абсолютная оценка = Часы

Относительная оценка = Story Points

Story Pointы не имеют физических единиц оценки. Но я сталкивался с ситуациями, когда команды пытаются приравнять их ко времени, например, что 1 SP = 1 часу или дню, тем самым мы просто возвращаемся к абсолютной оценке. Важно помнить о том что мы должны оставаться в относительной шкале и задача Scrum мастера донести эту концепцию до команды и Product Ownera. Можно использовать пример с планетами, стаканом фасоли или другими сравнимыми вещами. Также, при продуктовом подходе, стоит помнить, что мы экспериментируем, мы ещё не знаем будет ли успешен наш продукт на рынке и сделаем ли мы удачный инкремент в этом спринте. Scrum Фреймворк предполагает процесс непрерывного улучшения на основе полученного опыта.

Эксперимент важен, он позволяет команде постоянно совершенствоваться и становиться эффективнее и относительная оценка помогает в этом, так как за основу оценки, мы берём задачи, которые команда уже делала. Таким образом оценка со временем становится все лучше, а результат все более прогнозируемым.

Для себя я выделяю 3 основных принципа, при которых оценка будет эффективна для команды и проекта в целом.

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

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

Product Owner рассказывает команде контекст задачи, как он ее видит, после чего все члены команды «вслепую» (исключаем влияние на оценки) дают свои оценки ведущему (Scrum мастеру). Далее, слово предоставляется участнику, давшему самую высокую и самую маленькую оценку задаче. Выслушав их члены команды договариваются готовы ли они повысить или понизить свою оценку на основе услышанного, в итоге команда должна придти к единому мнению.

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

Большое спасибо, что вы дочитали до конца! Я очень надеюсь, что мне удалось донести смысл оценочной системы и привести примеры ее работы. Буду рад и благодарен за любые комментарии или критику в свой адрес.

Оценка задач в Story Points для больших и молодых команд разработки

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

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

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

Мой опыт управления командами разработки

Я в разработке уже более 10 лет, за это время поменял несколько ролей. Работал и без процессов совершенно, работал работником, которому объясняют, как работать, работал в команде, где помогал настраивать процессы, и, наконец, помогал настраивать процессы сразу нескольким десяткам команд. Сегодня я — Android-лид в Кошельке, где продолжаю настраивать процессы.

Очень редко получается, что команда несколько лет подряд успешно работает одинаковым составом по одинаковым процессам. Постоянно что-то меняется: люди, их роли, проекты и так далее.

Новая команда, старые трудности

Команда Кошелька сейчас активно расширяется, стало больше людей и больше задач. Много новеньких пришло за последние 4 месяца. Как следствие, люди плохо знают друг друга и проект. Поэтому задачи, которые изначально кажутся небольшими и лёгкими, выполняются долго. Возникает вопрос, как прогнозировать разработку в таких условиях?

Необходимая теория: Оценка задач и её точность

Самый ценный и расходуемый ресурс во время разработки — время. Точно сказать, сколько уйдет времени на одну задачу, невозможно, пока она не будет выполнена. Поэтому мы оцениваем задачу приблизительно.

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

Таким образом, оценка — это предсказание, сколько будет стоить решение задачи. А нужна она, чтобы сформировать ожидания, когда будет получен результат.

От чего зависит оценка?

От ответов на два главных вопроса:

Что нужно делать?

Как нужно делать?

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

Ответ на второй вопрос сложнее. Он зависит как от проблемы, которую нужно решить, так и от контекста, в котором её нужно решать. Контекст — это текущее состояние проекта. И он меняется с каждым новым изменением в коде проекта.

Решение почти любой задачи можно разбить на такие этапы:

Очевидно, что чем дальше мы продвинулись в решении, тем более точную оценку мы можем дать. Также очевидно, что оценивать сложность выполнения задачи уже во время тестирования бесполезно. Обычно адекватно оценить задачу можно во время начала этапа проектирования.

Оценка по времени

Сначала кажется, что время это очевидная мера оценки, ведь мы тратим на разработку именно часы и дни.

Плюс такого способа в том, что такая оценка всем понятна. Если задачу оценили в 8 часов, то её решение ожидается через 1 рабочий день, а за спринт ожидается решение 10 задач такого размера.

Минус в том, что в этом варианте невозможно учесть увеличение погрешности оценки с увеличением размера задачи. Ожидается, что 10 задач по 8 часов будут сделаны за то же время, что и 1 задача на 80 часов. Но более объемная задача, как правило, имеет больше подводных камней, которые не видны на ранних этапах проектирования.

Также не стоит забывать про разный уровень разработчиков в команде. Например, Senior сможет оценить и сделать задачу за 8 часов, тогда как Junior ту же задачу может оценить и сделать за 40 часов. Как следствие, оценка во времени актуальна, только если задачу будет делать тот, кто оценивал. Это может сработать, если в команде был, есть и будет один разработчик. Если разработчиков хотя бы два, то рассчитать среднюю производительность команды в часах будет трудно.

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

На практике задача, оценённая в часах, крайне редко выполняется вовремя.

Оценка в Story Point

Вместо оценки в часах и днях хорошо подходит оценка объема задач в относительных величинах. Такие величины называются story point. Ниже я расскажу о двух подходах к восприятию story points и оценке в них.

SP с эталонной задачей

Чтобы вся команда одинаково понимала значение единицы SP, можно придумать и описать эталонную задачу в 1 story point. Каждый сравнивает свою задачу с этим эталоном и дает оценку в зависимости от того, насколько она больше или меньше эталона.

Какие проблемы?

Проблем у такого подхода несколько:

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

Кросс-платформенная разработка. Если в команде есть несколько платформ, например, iOS и Android, то каждая платформа выбирает себе свою эталонную задачу. Так оценка перестаёт быть единой для всех, а члены команды, относящиеся одновременно к нескольким платформам (например, QA или аналитики), могут запутаться в понимании значения 1 SP.

Не учитывается погрешность оценки. Эталонная задача не учитывает прогрессию возрастания сложности. Если хотим оценить задачу в 3SP, то это вроде бы значит, что оцениваемая задача в 3 раза объёмнее эталонной. Это то же самое, что сделать 3 задачи по 1SP? На практике — нет. Чем сложнее задача, тем менее вероятно, что мы её оценим правильно.

SP со временем

Чтобы учесть проблемы предыдущих способов оценки, можно использовать story points с оценкой по времени. Важно понимать, что мы используем не просто время, а восприятие времени. То есть оцениваем не сколько часов будет выполняться конкретная задача, а за сколько часов в идеальном мире её можно выполнить.

Чтобы понять, за какое время мы сделаем задачу или сколько SP мы сделаем за спринт, нужно посчитать, сколько в среднем SP-ов мы делали в предыдущих спринтах. Так, если в предыдущих спринтах мы делали по 7SP, а в спринте 10 рабочих дней, то 1 SP — это 1,4 дня, а если по 14 SP, то 1 SP — это 0,7 дня.

Чтобы с чего-то начать, можно использовать такую шкалу:

0.5 SP — менее, чем за день

1 SP — до 2 дней

2 SP — около недели

3 SP — около одного спринта

5 SP — можно сделать за спринт, если всё будет идеально и никто не будет отвлекать

8 SP — 2 спринта

Задачи 5 и 8 SP в спринт брать нельзя, их нужно декомпозировать на более мелкие, чтобы снизить погрешность оценки. Задачи на 2 и 3 SP достаточно большие, их сложно сделать на одном дыхании, их лучше тоже декомпозировать. Но это не всегда оправданно или возможно.

Задачи с оценкой в 0.5 и 1 SP должны занимать основную часть спринта. Это довольно точные оценки, по ним всегда будет, что сказать на стендапе. Задач меньше, чем 0.5 SP, просто не бывает: всегда требуется время на описание задачи, на мерж-реквест, на тестирование и т.д.

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

Какие проблемы?

Минусы такого подхода в том, что при оценке учитывается время. А это значит, что Junior и Senior оценят задачу по-разному, так как им нужно разное время на её выполнение. Эта проблема решается усреднением оценки по команде — например, с помощью покер-планирования.

При оценке в SP с использованием времени важно не учитывать, кто именно будет делать задачу. Иначе возникает соблазн включить в оценку индивидуальные особенности разработчика: его “синьористость”, отпуск, вынужденные выходные. Это повлияет на среднюю ёмкость спринта, а SP превратятся из оценки объёма задачи в оценку работы разработчика.

Текущий курс — стабилизация процесса

Как я уже писал, моя команда в Кошельке — новая, кроссплатформенная и большая. У нас объёмные и сложные задачи, нам нужно их быстро решать.

Уже несколько месяцев мы используем подход с оценкой в SP с привязкой ко времени. А последние несколько спринтов нам удаётся сжигать SP практически в ноль.

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

Оценка задач в Story Points

Практически каждый человек, который сталкивался с разработкой ПО знает что такое оценка задач в Story Points (SP), тем не менее периодически мне доводится рассказывать коллегам из других отделов или новичкам в команде, которые ни разу не сталкивались с таким подходом, зачем мы используем SP и почему это удобно для команды и эффективно для компании.

Цель этого текста – рассказать, что такое SP, как их использовать для оценки задач и почему эта методика получила такое широкое распространение.

Проблема

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

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

Для иллюстрации я приведу в пример вымышленный диалог из книги Роберта Мартина «Идеальный программист».

Майк (Менеджер): Какова вероятность того, что ты справишься за три дня?

Питер (Разработчик): Пожалуй, справлюсь.

Майк: Можешь назвать число?

Питер: Пятьдесят или шестьдесят процентов.

Майк: Значит, есть довольно высокая вероятность, что тебе понадобится четыре дня?

Питер: Да. может понадобиться даже пять или шесть, хотя я в этом сомневаюсь.

Майк: До какой степени сомневаешься?

Питер: О, я не знаю… Я на девяносто пять процентов уверен, что работа будет сделана менее чем за шесть дней.

Майк: То есть может быть и семь?

Питер: Ну, если все пойдет наперекосяк… Черт, если ВСЕ пойдет наперекосяк, может быть десять и даже одиннадцать дней. Но ведь вероятность такого совпадения очень мала, верно?

Я думаю, что диалог выше звучит довольно знакомо для любого разработчика или менеджера проекта.

К сожалению, проблемы с оценками на этом не заканчиваются. Следует так же учитывать и другие подводные камни:

Корреляция оценки и оценивающего

Выставленная оценка справедлива только в том случае, если реализовывать задачу будет автор оценки. Ведь очевидно, что время, затраченное на задачу старшим разработчиком и интерном будет отличаться.

Идеальная оценка в неидеальном мире

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

Далее мы рассмотрим подход к оценке задач в SP и то, каким образом он адресует все описанные выше сложности.

Альтернативные решения

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

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

PERT или Program Evaluation and Review Technique была разработана в 50-е годы XX века в ВМС США.

Для оценки задачи по схеме представляются три числа:

O: предельно оптимистическая оценка. Задача может быть выполнена в эти сроки только если все без исключения пройдет как задумано.

N: номинальная и наиболее вероятная оценка.

P: крайне пессимистическая оценка, в которую заложены все неприятности, которые могут произойти во время выполнения задачи.

По этим трем оценкам ожидаемая продолжительность задачи описывается следующей формулой:

А среднеквадратическое отклонение, фактически являющееся мерой неопределенности задачи вычисляется по формуле:

Таким образом задачу, которую обсуждали Питер и Майк можно оценить в:

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

Story Points

Что же такое Story Points и как они помогают оценивать задачи? Весьма коротко и понятно об этой технике рассказывает в своем видео Майк Кон евангелист Agile и CEO компании Mountain Goat Software.

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

При этом в оценку усилий следует заложить все факторы, которые могут повлиять на нее:

Хочется подчеркнуть два важных аспекта метода Story Points, которые позволяют ему решать проблемы, которые мы обсудили на предыдущей странице:

Относительность оценки

Задачи оцениваются относительно друг друга, таким образом возникает универсальная шкала оценки, не зависящая от опыта оценивающего. Даже если у задачи сменится ответственный — ее оценка останется неизменной, достаточно новые задачи оценивать относительно этой шкалы.

Замена часов на абстрактные баллы

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

Числа Фибоначчи, майки и собаки

Да, да майки и собаки. Для оценки задач можно использовать любую шкалу. Самой распространенной являются числа Фибоначчи, это понятные числовые значения к тому же с приятным бонусом: элементы этой последовательности хорошо отражают рост неопределенности, который возникает с ростом сложности оцениваемой задачи.

Тем не менее некоторые команды используют альтернативную шкалу оценки. Самые распространенные это оценка в майках и собаках, когда сложность задачи указывается в размере майки (S, M, L, XL) или в породе собаки (Чихуахуа, Мопс, Дог). Таким образом команды еще больше абстрагируются от численного представления оценки, которое в некоторых случаях так и подмывает перевести в оценку временную.

Оценка в команде

Чем отличается оценка в команде от индивидуальной оценки?
Почему важно привлекать всю команду к выставлению оценок?

Одна из самых больших ошибок, которые можно допустить при оценке задач — сделать ее самостоятельно и не спросить мнения членов команды. Может быть у них есть свое мнение по этому поводу? Хотите добавить поддержку нового браузера? А что по этому поводу думают QA?

Люди — самый важный ресурс оценки. Они могут увидеть то, что не видите Вы.

Но как проводить оценку командой? Просто выкрикивать оценки не очень эффективно, к тому же услышав вашу оценку другой член команды может передумать и не станет озвучивать свою.

Покер планирования

В 2002 году Джеймс Греннинг описал метод, который впоследствии стал настолько популярным, что теперь Вы даже можете купить настоящие колоды карт для покера планирования. Или воспользоваться одним из онлайн сервисов для проведения сеанса;

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

Если оценки участников согласуются – оценка фиксируется, в противном случае карты возвращаются в руку, а члены команды продолжают обсуждение задачи. Хорошая идея — спросить у выставивших разные оценки: «Какие сложности ты видишь в этой задаче?» или «Почему ты считаешь, что во время реализации не возникнет никаких проблем?».

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

Альтернативы

Как и самого метода оценки, так и у покера планирования есть альтернативы. Я вкратце расскажу о одной из них.

Этот блок можно пропустить и перейти сразу к следующей странице.

Об этом методе я узнал все из той же книги Роберта Мартина «Идеальный программист. Суть метода заключается в том, что все задачи записываются на картах без каких либо оценок. Экспертная группа стоит возле окна или стены, на которой карты распределены случайным образом. Участники не говорят между собой — они просто сортируют карты. Карты задач, требующих больше усилий, перемещаются вниз, требующих меньше усилий смещаются наверх.

Любой участник группы может в любой момент переместить любую карту, даже если она уже была перемещена другим участником. Карты перемещенные несколько раз, откладываются в сторону для обсуждения. Со временем безмолвная сортировка завершается и начинается обсуждение.

На следующем этапе между картами рисуются линии, представляющие усилия, требующиеся для реализации задач.

Стоит отметить, что подход с использованием таких категорий или „корзин“ можно использовать и в классическом покере планирования.

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

Сколько часов в Story Point’e и как мне построить диаграмму Ганта?

Итак, мы оценили наш бэклог задач, но на Story Point’ах план проекта не построишь. Часто у руководителя проекта возникает вопрос: „Как перевести SP в часы?“.

Короткий ответ на этот вопрос: „Никак“.

Конечно, можно с секундомером ходить за разработчиками и записывать время, которое им понадобилось на решение задачи, а затем вывести эту информация в виде графика. Тогда у вас получится классический „колокол“, как на примере в блоке ниже. Как мы видим на первом рисунке – некоторые задачи занимают чуть больше времени, некоторые чуть меньше, но в целом все значение будут соответствовать некоторому нормальному распределению.

То же самое справедливо и для задач в 2 SP и это показано на втором рисунке. Заметили, что „хвосты“ графиков пересекаются? Да, некоторые задачи оцененные в 1 SP могут потребовать больше усилие чем самые простые из оцененных в 2 SP. В конце концов ни одна команда еще не научилась оценивать идеально. Кроме того переводя SP в часы мы возвращаемся к старым граблям, то, сколько времени понадобится разработчику для решения конкретной задачи сильно зависит от самого разработчика.

Но что же делать, мы не можем полностью отказаться от планирования. К счастью, для этого нам не нужно переводить каждый Story Point в часы. Что действительно важно, так это сколько SP команда разработки может „закрыть“ за спринт (итерацию, релиз).

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

Скорость (или Velocity) это мощный инструмент планирования и главная метрика команды разработки. Команда должна работать над постоянным улучшением, чтобы повысить свою скорость. Не стоит так же забывать, что скорость это производная величина от SP и поэтому тоже относительна. Нельзя сравнивать две команды друг с другом, команда соревнуется сама с собой.

Практика

Какие нюансы нужно знать?
Каких ошибок можно избежать?

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

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

У вас новый проект и нет реализованных задач? Попробуйте воспользоваться афинной оценкой, которая описана выше, и распределите задачи по шкале оценок.

Не усредняйте оценки

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

Не меняйте оценки

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

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

Какой бы подход вы выбрали оставайтесь последовательными. Информация об исторический скорости команды не должна пострадать от применения разных подходов к оценке.

Еще один вопрос, который не имеет однозначного ответа. Кто-то считает, что не бывает задач, не требующих усилий. Другие отвечают им, что назначение баллов простейшим задачкам ведет к необоснованному росту графика скорости команды.

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

Переоценка незаконченных задач между итерациями

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

Если вы еще не проводите ретроспективы – пора начать! Это отличный командный инструмент повышения скорости и слаженности команды. Впрочем это отдельная тема.

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

Можно так же достать из истории несколько задач с одинаковыми оценками и обсудить действительно ли все эти истории потребовали одинакового количества усилий.

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

Стори Поинты (Story Points)

Чтобы оценить объем работы над Элементом Бэклога Продукта, Скрам-команды обычно используют Стори Поинты. Это условная величина, позволяющая давать Элементам Бэклога относительные веса. Чаще всего для оценки в Стори Поинтах используются числа Фибоначчи (1, 2, 3, 5, 8, 13, …), что позволяет провести оценку достаточно быстро.

Ниже — перевод статьи Джеффа Сазерленда Story Points: Why are they better than hours? с сайта Scrum Inc.

Чем Стори Поинты лучше человеко-часов?

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

Точность оценок

Последние исследования от Microsoft показывают, что оценка по agile демонстрирует поразительную точность в сравнении с традиционными методами оценки проектов. Подробнее об этом исследовании вы можете почитать здесь:
Scrum + Engineering Practices: Experiences of Three Microsoft Teams

Многим людям, имевшим опыт управления проектами с оценкой в часах, сложно понять, почему стори поинты работают лучше. Им также сложно принять некоторые фундаментальные факты, которые публикуются в профильной литературе уже в течение 60 лет, равно как и последние исследования, которые только подтверждают их правильность.

Успешность проектов

Давайте посмотрим на последние данные по неуспешным проектам. Глобальная финансовая система рушится, и вместе с этим растет процент провальных проектов в IT. Недавно было проведено одно интересное исследование: консалтинговая фирма Standish Group собрала данные об успешности нескольких десятков тысяч проектов, стартовавших за последние десять лет. Аналитика от Standish Group показывает, что процент успешности agile-проектов в три раза превышает успешность проектов, ведущихся традиционным образом. Джим Джонсон рекомендует использование agile-практик на всех без исключения проектах.

Разрыв между оценками сроков и реальностью

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

Дело в том, что для планирования релиза критичным является постоянство пользовательских историй. Три стори поинта сегодня — это те же три стори поинта в следующем году, и для Владельца Продукта эти стори поинты являются измеримой частью релиза продукта. Тогда как количество часов для завершения истории зависит от того, кто ее делает и в какой день. Эти показатели меняются ежедневно. Диаграмма Ганта предполагает фиксированное количество часов на задачу для какого-то гипотетического человека (который зачастую не является фактическим исполнителем задачи) и заведомо известные зависимости (которые на самом деле непрерывно меняются). Исследование восьмидесяти мультимиллионных проектов, проведённое в GSI Commerce (ими сейчас владеет eBay), показало, что лучшие эксперты в компании оказались неспособными правильно оценить время выполнения проекта людьми, которые действительно его реализовывали.

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

Вариабельность оценок

Исследование, проведенное Rand Corporation еще в 1940х годах, очевидно продемонстрировало неспособность людей точно проводить оценку в часах, и практический опыт постоянно подтверждает этот факт. Вместо часов для оценки рекомендуется использовать метод «Дельфи», известный в разработке программного обеспечения как техника Wide Band Delphi. Аналогичная техника используется agile-командами и носит название Покер планирования.

Интересные данные по личной продуктивности разработчиков пришли из Йельского Университета. Лучшему разработчику на проекте требуется один час, чтобы сделать задачу, в то время как худшему требуется 10 часов (в рамках его проекта) или даже 25 (если проект незнакомый). Для команд эта разница еще на порядок больше. Данные, опубликованные Ларри Путнемом (Larry Putnam) показывают, что задача, на которую наиболее продуктивной команде требуется час, может превратиться в 2000 часов для наименее продуктивной команды.

Процесс оценки в стори поинтах дает лучшую точность, чем оценка в часах, за счет меньшей вариативности стори пойнтов. Одна компания 5го уровня CMMI определила, что оценка в стори поинтах сокращает время оценки на 80%, что позволяет оценивать больше фич и отслеживать их, в сравнении с каскадной моделью. Другая компания из телеком индустрии заметила, что оценка с помощью стори поинтов и Покера планирования была не только в 48 раз быстрее, чем практики каскадной оценки, но и дала более точные результаты.

Мера прогресса

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

Число потраченных часов не дает Владельцу Продукта никакой информации о том, сколько фич можно поставить и когда.

Что действительно является важной метрикой, так это количество стори поинтов, которую команда может поставить за календарный период. Число поинтов за спринт — это производительность команды (velocity). И несмотря на то что все оценки происходят в стори поинтах, Владелец Продукта делает план релизов на основании производительности команды и корректирует его, если эта производительность меняется.

Таким образом, стори поинты быстрее, лучше и дешевле часов, и высокоэффективные команды повсеместно отказываются от оценок в часах как от лишней нагрузки, которая замедляет их и тянет вниз.

Jeff Sutherland, 2013

От редактора: обратите внимание на антипаттерн скрам-команд, связанный со стори поинтами и оценкой задач в целом.

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

Информация, которая требуется команде для понимания и выполнения работы над Элементом Бэклога Продукта. Описание критериев готовности Элементов к разработке должно быть таким, чтобы для выполнения работы команде не требовалось дополнительных обсуждений и исследований. Такие Элементы можно принять в работу немедленно (они Immediately Actionable). Например, Элементы можно проверять на соответствие критериям I.N.V.E.S.T.

Критерии Приемки (Acceptance Criteria)

Специфические требования и приемочные тесты, которым должны соответствовать Элементы Бэклога Продукта, чтобы работа по ним считалась завершенной с точки зрения клиента / Владельца Продукта. Определение Критериев Приемки звучит очень похоже на Критерии Готовности, но в действительности эти понятия отличаются: Критерии Приемки касаются требований клиента к конкретному Элементу Бэклога, а Критерии Готовности формируются командой и касаются многих Элементов.

Оценка (Estimation)

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

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

Мы хотим, чтобы компании были крутыми, а люди в них — счастливыми

Мини-справочник и руководство по Scrum

Данная статья – это мини-справочник и руководство по методу Scrum, созданные в результате прочтения книги Сазерленда, статей из интернета и применения на практике.

Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.

Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.

Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе. Состояние счастья приводит людей к превосходным результатам.

Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса

— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

Мини-справочник Scrum

Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.

Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.

Основные обязанности и ответственность Product Owner при управлении Product Backlog:

Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.

Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.

Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.

Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

User – пользователь продукта.

Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.

Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.

User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.

Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.

Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.

Sprint Goal (спринт гоол) – цель спринта.

Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.

Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.

Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.

Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?

Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.

Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.

Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.

Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.

Burndown Chart (бёрдаун чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.

Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.

Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.

Руководство Scrum

Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.

Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.

123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.

User Story

Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?

Формируется Sprint. Sprint Planning Meeting. Scrum Poker

Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.

Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:

Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.

Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.

Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.

Sprint Retrospective Meeting. Ретроспектива.

Проводится в последний день спринта.

Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.

Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?

Почему я не использую story points для планирования спринта

Привет, Хабр! Представляю вашему вниманию перевод статьи «Why I Don’t Use Story Points for Sprint Planning» автора Mike Cohn.

Как описано в «Agile Estimating and Planning», я большой поклонник story points для оценки бэклога продукта. Тем не менее, я также рекомендую оценивать бэклог спринта в часах, а не в story points. Почему это кажущееся противоречие? Ранее я писал о причинах. Я рекомендую использовать разные единицы измерения (points и часы) для различных бэклогов.

Но мне часто задают связанный с этим вопрос, который я хочу задать здесь:

Мне любопытно, почему вы не используете story points для планирования спринта. Я думал, что смысл измерения скорости в story points был, частично, в том, чтобы определять, сколько мы можем взять (или зафиксировать) в спринт. Используете ли вы только story point для долгосрочного планирования (например, планирования релизов)?

Я не использую story points для планирования спринта, потому что story points это полезная долгосрочная мера. Но points не полезны в краткосрочной перспективе.

Было бы уместно, чтобы команда сказала: «У нас средняя скорость 20 story points, и у нас осталось 6 спринтов, поэтому мы закончим около 120 story points в этих шести спринтах».
Было бы неуместным, чтобы команда сказала: «У нас средняя скорость 20 story points, поэтому мы закончим в следующем спринте». Это не работает.

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

Скорость будет изменяться от спринта к спринту.

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

Когда команда заканчивает планировать спринт таким образом, то вполне вероятно, что количество story points, которые они неосознанно преследуют, должно быть близко к их среднему значению, но оно будет меняться.

Также будет верно, что команда будет выполнять примерно одинаковое количество часов от одного спринта до следующего. Я использую термин «capacity», чтобы ссылаться на это количество часов, потому что скорость зарезервирована для того, чтобы ссылаться на измерение объема запланированных или выполненных работ, как указано в единицах, используемых для оценки бэклога продукта (что я рекомендую делать с использованием story points).

Об авторе: Mike Cohn является одним из авторов Scrum-методологии разработки программного обеспечения. Он один из основателей Agile Alliance и Scrum Alliance. Специализируется на помощи компаниям во внедрении и улучшении использования agile процессов и методов создания высокопроизводительных команд.

Список литературы: Agile Estimating and Planning, Mike Cohn, 2005 год.

Scrum и Kanban: как джунам не запутаться в процессах и терминах

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

Не забываем, чтобы работать по Agile, в первую очередь важно придерживаться Agile-манифеста и его ценностей. Не достаточно просто работать в таск-трекерах и применять Kanban и Scrum.

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

Я не буду брать общепринятые термины, которые написаны в книгах по Agile, их вы и без меня можете прочитать. Постараюсь объяснить здесь таким языком, как объясняю это новым специалистам при их онбординге на проекты.

В первую очередь нужно сказать пару слов про Agile.

Есть разные методики управления проектом: Kanban и Scrum.

Главным инструментов в работе Kanban команды является Kanban-доска.

Пример Kanban доски в Jira

Пример простого Workflow (набор статусов и переходов между ними для работы над задачами) Пример более комплексного Workflow

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

Low (задачи на потом, когда будет свободное время и ресурсы).

Medium (запланированные задачи с с подглядывающим в будущем дедлайном).

High (эти задачи как правило еще нужно было сделать вчера).

Blocker (если такие задачи не сделать в первую очередь, то вся остальная работа будет заблокирована. ещё хуже, когда это баги или сбои, которые очень сильно влияют на проект/продукт и его бизнес-ценность).

Пример доски с двумя swimlanes (Business Projects и Internal Projects)

Какие виды досок можно использовать?

Пример физической доски со стикерами в виде задач

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

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

Переходим к обсуждению Scrum

Самые главные определения из Scrum:

Оценка задач по трудозатратам:

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

Например, для новеньких членов команды первые несколько спринтов можно устанавливать лимит в 2 или 3 раза меньше чем для других, это время для онбординга. Также не стоит забывать, что senior и junior могут оценивать одну и ту же задачу по разному, т.к. сложность работы и скорость выполнения для них будет разная.

Критерии для подготовки и завершения задач

понятное название и описание;

написаны критерии приемлемости;

определены зависимости с другими задачами;

поставлена оценка трудоемкости;

задача не является заблокирована другими задачами.

контакты бизнес-владельцев продукта определены и зафиксированы в реестре;

текущее состояние функционала описано;

желаемое состояние функционала описано;

все находки и процесс работы задокументированы;

возможные риски определены и донесены до владельца продукта;

задача для разработчиков поставлена и описана.

Ниже приведен пример пользовательской истории, которая заполняется в Jira. Что здесь есть: acceptance criteria, priority, definition of done, description. Что можно добавить: назначить задачку на конкретного исполнителя, чуть подробней сделать description с ссылками на документацию (зависит конечно от задачи), оценить задачу в story points или другим методом оценки

Пример как может выглядеть задача с DoD и другими полями (не идеал, но все же пример)

Конечно в настоящих задачах и проектах критерии описываются более точно.

Scrum встречи

Пару слов стоит еще сказать про Scrum встречи, которые проходят регулярно каждый спринт.

Обдумывая стори поинты

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

Идея историй (stories) конечно же пришла из XP, а не из Scrum. Неким образом скрам-практики адаптировали эту идею в свою работу. Хотя официальный скрам-гайд говорит лишь об элементах бэклога (backlog items), использовать пользовательские истории в качестве элементов бэклога – очень распространенная в скраме практика.

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

В экстремальном программировании (ХР), истории изначально оценивались во времени: времени, которое потребуется на завершение разработки истории. Мы быстро начали использовать то, что сейчас называется “идеальные дни”, которые неофициально означали “сколько дней потребуется паре до завершения, если их наконец-таки оставят в покое”. Мы перемножали идеальные дни и “фактор нагрузки”, чтобы получить реальное время до завершения разработки. Фактор нагрузки обычно составлял примерно три: три реальных дня тратилось, чтобы завершить работу одного идеального дня.

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

Так что, насколько я помню, мы начали называть наши “идеальные дни” обычными “поинтами”. Таким образом, оценка в три стори поинта означала, что историю завершат примерно за 9 дней. Так или иначе, мы использовали поинты только чтобы понять, какой объем работы мы можем взять в итерацию, поэтому когда мы говорили что это примерно 20 поинтов, никто особо не возражал.

Возможно это я предложил изменить название. Если я действительно сделал это, сейчас мне жаль. Вот некоторые из моих нынешних соображений на эту тему. Я писал их своему коллеге Саймону, который спросил:

Ты действительно сожалеешь, что стори поинты были изобретены, или ты просто осуждаешь их неправильное использование, когда люди не полностью понимают относительные размеры?

Сравнение

В первую очередь, даже если команды “почти одинаковые”, у каждой из них есть собственный набор компетенций и своя рабочая среда. Так что если они посмотрят на две истории, которые выглядят одинаково и одна команда скажет, что это двойка, а другая скажет, что это шестерка – это попросту бесполезная информация. И это точно не самый полезный способ сравнения команд.

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

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

Отслеживание

Для многих менеджеров существование оценки подразумевает существование “реальных трудозатрат”, а значит нужно сравнить оценку и реальные трудозаты и убедиться, что они совпадают. Если не совпадают – значит нужно учиться оценивать лучше.

Для меня важная черта Реального Agile – выбрать несколько вещей в работу, а потом оперативно их сделать. Ключевой вопрос – это как найти самые ценные вещи и как сделать их быстро. Сделать быстро обычно превращается в поставку маленьких кусочков ценности и динамичное итерирование. Оценка стоимости историй не особо в этом помогает, если вообще помогает.

Так что если существование оценки заставляет менеджмент сместить фокус с поставки ценности на улучшение процесса оценки, значит оно забирает внимание с настоящей цели – быстро доставлять реальную ценность.

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

Давление

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

Лучший способ поставлять ценность – это не больше, больше, больше. Лучший способ – это поставлять ценность часто и маленькими партиями. Если вместо оценивания историй мы поделим их на “достаточно маленькие” кусочки, тогда мы сможем прийти к равномерному потоку поставки ценности, доставляя без перерывов.

Фокусировка на “больше” мешает увеличению ценности. Продавливание увеличенных поставок практически без вариантов приводит к плохому результату: команда пытается ускориться и делает это в ущерб качеству кода или тестированию. Вскоре они начинают поставлять больше дефектов, замедляются из-за увеличенного количества переделок чтобы починить дефекты, замедляются еще сильнее из-за того что качество кода стремительно ухудшается. Положение становится хуже и хуже, давление увеличивается и всё превращается в погоню за провальными ситуациями.

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

Я скажу больше: я предпочитаю вовсе отказываться от планирования спринтов или итераций. Мы работаем не для того, чтобы освоить бюджет предстоящих недель: мы работаем, чтобы составить короткий список важных вещей для ближайшей поставки.

Предсказывая готовность

Обычная практика – составить список необходимых фич, обдумать их и решить, что они составят следующий релиз нашего продукта. Конечно же, следующий вопрос – “когда всё это будет готово?”.

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

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

Декомпозиция

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

Я не буду препираться с читателями на тему оценивания в процессе декомпозиции. Если ваша команда в тайне проводит оценку и никому об этом не говорить – тогда проблем с этой оценкой скорее всего не возникнет, в стори поинтах она или во времени. И конечно же, знать разницу между “наверное достаточно маленькая” и “наверное недостаточно маленькая” и знать как различаются “три дня” и “один день” – это совершенно непохожие вещи.

Кроме того, есть одна хитрость. Я упоминал ее в Getting Small Stories и в Slicing, Estimating, Trimming. Я выучил ее у Нила Киллика (Neil Killick): декомпозируйте истории, пока они не станут размером с один приемочный тест. После небольшой тренировки, ваши истории станут самого подходящего размера.

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

Предсказывая будущее

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

Конечно же, если оценки нужно делать, то нужно их делать. То, что я делаю или как я представляю, что вам нужно делать – это всё мои теории. В конце концов – вам решать, как действовать, чтобы достичь успеха в вашей конкретной ситуации. Тем не менее, я думаю, что есть более хороший путь.

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

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

В-третьих, декомпозируйте важные решения на маленькие части и реализуйте их. Наверняка у вас легко получится сделать эти части размером в один день, или меньше. Работайте только над самыми важными частями: не пытайтесь реализовать все решение до упора. Ваша цель – начать думать в ключе “Если мы сделаем вот эту небольшую функцию, то наш Пользователь Джек уже сможет этим пользоваться”. Потом завершите эту функцию и дайте Пользователю Джеку попробовать. Наша цель – максимально приблизиться к непрерывной поставке ценности. И делать это нужно быстро.

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

Подытожим

Что ж, если я и изобрел стори поинты, наверное, мне немного жаль. Но не сильно жаль. Я действительно думаю, что их часто используют неправильно и мы избежим многих проблем, если вообще откажемся от оценок историй. Если в вашей компании стори поинты не несут ценности – я бы предложил от них отказаться, потому что это пустая трата усилий. С другой стороны, если они вам очень нравятся, то, что ж, полный вперёд!

За перевод огромное спасибо Максиму Фролову.

Сторипоинты: как и зачем использовать

Что такое Story Points?

Story Point условная величина, позволяющая оценивать задачи из бэклога. Оценка одних задач относительно других.

Бэклог — это упорядоченный набор задач по проекту.

Как использовать?

Важно понимать:

Справедливо оценить задачу может только тот, кто будет ее выполнять.

1-й вариант:

Выбирается небольшая задача из бэклога, которую команда точно может оценить. Задача берется за условную единицу (Story Point) и остальные задачи оцениваются в этой задаче.

Story Point служит для предварительной оценки проекта.

Пример:

Берем небольшую задачу, например, форма обратной связи.

Мы знаем точное время на эту задачу — 2 часа. Это один Story Point.

Далее все задачи оцениваем в Story Points. 1 SP = 2 часа.

2-й вариант:

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

Факторы, влияющие на оценку усилий:

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

Относительность оценки

Задачи оцениваются относительно друг друга, таким образом возникает универсальная шкала оценки, не зависящая от опыта оценивающего. Даже если у задачи сменится ответственный — ее оценка остается неизменной, достаточно оценивать новые задачи относительно этой шкалы.

Замена часов на абстрактные баллы

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

Оценка в команде

Чем отличается оценка в команде от индивидуальной оценки?

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

Люди — самый важный ресурс оценки. Они могут увидеть то, что не видите вы.

Как проводить оценку командой?

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

Можете провести оценку вручную, если подготовили специальные карточки.

Разработчикам

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

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

Документ №1 — недельный рывок, в этом документе менеджер проекта указывает, какими проектами и сколько часов будет заниматься разработчик на неделе. В документе можно посмотреть на сколько загружен разработчик:

— сильно загружен.

— нормально загружен.

Загрузка разработчика в неделю должна доходить до 30 часов.

Документ №2 — план на день. В этом документе менеджер проекта указывает, наименование проекта и номер задачи, для разработчика.

Работу по одному проекту не должны вестись сразу несколькими разработчиками.

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

Менеджерам

Стендап — ежедневная короткая планерка в Scrum. Члены команды собираются в одно и то же время, в одном и том же месте и отвечают на три вопроса:

Scrum — это гибкая методология разработки ПО, помогающая командам вести совместную работу.

Ретроспектива. WTF?

Ретроспектива — это командный пересмотр последнего этапа работы (спринта).

Цель ретроспективы — улучшить процесс разработки проекта, понять, что пошло не так.

Формат ретроспективы:

Ретроспектива должна проходить в отдельной комнате, чтобы никто не мешал.

Размещаем доску, блокнот, тетрадь горизонтально.

Проговариваем что шло хорошо, что было плохо, что мешало работать быстрее, какие возникали проблемы в процессе.

Продолжительность от 30 минут до часа.

В “+” записываем, что было хорошо, какие позитивные моменты может сказать команда по прошедшему спринту.

В “-” — что было плохо.

Желательно заранее попросить команду обдумать, какие были “+” и “-”.

Как только закончили с минусами и плюсами, фиксируем их и начинаем думать, как решить проблемы.

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

Диаграмма сгорания

Для чего нужна?

Диаграмма сгорания показывает, сколько задач осталось до завершения спринта на временной шкале (и сколько уже сделано). По вертикали — количество задач, по горизонтали — время. Цель команды: «сжечь» все задачи до того, как приблизится дедлайн.

Velocity = Focus Factor х Оценка новых задач.

Velocity — производительность. Позволяет предсказать, сколько задач команда может выполнить на следующем этапе в зависимости от того, сколько она выполнила в предыдущем.

Focus Factor — коэффициент, который показывает, сколько задача должна была занять в идеале, а сколько вышло в итоге. Можно сказать, что это «концентрация» команды над проектом.

Диаграмма производительности

Для чего нужна?

Предназначена для выяснения, насколько выполненное количество задач в спринте соотносится с плановым. Более «глобальная» метрика позволяет оценить, насколько команда справляется с планом в каждом спринте и сделать прогноз на будущее. На горизонтальной оси — время, на вертикальной — количество задач в спринте. Рядом по два столбца: первый — фактически выполненные задачи, второй — план на спринт.

Важно: для того, чтобы оперировать показателем Velocity нужно, чтобы продолжительность спринта и число человек в команде не менялось (как и состав команды).

Why do we use Story Points for Estimating?

The scrum guide tells us that estimates should be provided by people that will be doing the work but it doesn’t tell us how we should provide estimates. It leaves that decision to us. A common tactic used by scrum teams is to estimate using a unit of measurement referred to as the Story Point. But why use Story Points instead of hours or days or any other well-known unit of time? Are we deliberately trying to obfuscate? In this article I look at the pros and cons of using Story Points and come to a surprising conclusion.

What is a Story Point?

Unsure about Story Points?

I did a quick search on Google for the phrase “What are Story Points”. I was hoping to get a clear definition of the term but it proved highly elusive. The list I got back from Google wasn’t overly helpful and some of the higher placed links were, in my view, simply wrong in places. Surprisingly (to me at least) an article I had written, a necessarily terse precis on estimating in Scrum appeared on the first page of the search and I hadn’t tried to define what a Story Point was at all.

Summary: I couldn’t find a clear definition of what a Story Point is on the Internet. So, here’s my attempt:

“A Story Point is a relative unit of measure, decided upon and used by individual Scrum teams, to provide relative estimates of effort for completing requirements“

Why use Story Points?

Story Points are intended to make team estimating easier. Instead of looking at a product backlog item and estimating it in hours, teams consider only how much effort a product backlog item will require, relative to other product backlog items.

Ok, so it makes estimating easier but how is that useful? Story Points are of no value whatever to a business because they can’t be used to predict cost or delivery dates. Even the Scrum team cannot make any predictions as to how many Story Points it can complete in a sprint (velocity) until it’s got a few sprints under it’s belt, some months down the road.

Story Points are confusing

Confused about Story Points?

Story Points themselves are confusing.

Mike Cohn, respected author of the book “Agile Estimating and Planning” recently wrote an article explaining why you should use effort and not complexity in deciding relative sizes of product backlog items. It’s a good article but the comments from readers leaves you in no doubt that here’s a lot of confusion around the topic of Story Points.

What’s wrong with using time as a unit of measure?

For hundreds of years we’ve had standard units of time. Why can’t we use hours or days? Well, in a nutshell, because your hour is not the same as my hour.

If you ask two developers to estimate the same task, you’ll get two different answers. While some of the difference might be explained by gaps in the specification or understanding, the fact is that developers have different knowledge and experiences so it will take more or less time to do the same work.

Ask those same two developers to rate the amount of effort required to complete one product backlog item relative to another product backlog item and you’re far more likely to end up with a consensus.

The real reason for using Story Points

So, up until now, you may have been unconvinced about the need to use Story Points. Ok, they show the relative effort to complete work on different product backlog items but how does that help anything? Until we understand what the team’s velocity is, we still can’t predict when product backlog items are likely to be completed. Worse, if the membership of the team changes, the velocity will change and we won’t know what that new velocity is until some time down the road.

All these problems have led many to try and make a correlation between Story Points and time but as Mike Cohn points out in his article on relating story points to hours, it’s not trivial.

But to try and match Story Points to hours is missing the point. What’s important is how many Story Points a team can complete in a sprint, known as the velocity. When you know this, you can make some predictions and you know what, they’re likely to be good. Very good.

Delighted about Story Points!

The real reason for using Story Points is that they’re accurate.

Who says so? Jeff Sutherland, the co-author of the Scrum Guide. In his article on why Story Points are better than hours he puts it like this: Story points are therefore faster, better, and cheaper than hours and the highest performing teams completely abandon any hourly estimation as they view it as waste that just slows them down.

It’s nice to get clarity on these things.

Story Points | Стори поинты. Топ-7 вопросов

Story Points (стори поинты) — одна из самых противоречивых тем в Agile сообществе. В интернете вы можете найти довольно много статей, в которых раскрывается суть этой относительной оценки. Тем не менее у команд, применяющих стори поинты, не становится меньше вопросов. Мы решили ответить на самые часто задаваемые из них. В этой статье приводим топ-7 вопросов о стори поинтах.

1. Как перевести стори поинты в часы?

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

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

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

Если вы попробуете связать стори поинты и часы, то поймёте, что время — это неоднозначный показатель для сравнительной оценки. Такая конвертация не принесёт пользу ни Команде, ни Владельцу Продукта.

2. Зачем использовать для оценки задачи число?

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

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

3. Нужно ли переоценивать задачу, если она переходит в следующий спринт?

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

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

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

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

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

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

4. Равны ли друг другу стори поинты двух команд?

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

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

5. Можно ли оценивать эффективность команды с помощью стори поинтов?

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

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

Как вы поняли, стори поинты — относительная оценка и попытки измерения эффективности с их помощью может привести к подгону результатов.

Со временем команда начинает все быстрее приносить ценность. Но измерять эффективность команды в стори поинтах довольно неэффективно.

Почитать о том как измерять эффективность можно здесь

6. Можно ли использовать стори поинты не только в скрам командах?

С этим вопросом сталкиваются множество команд, которые, например, не используют итерации. Кажется, что процесс уже визуализирован, и есть желание внедрять улучшения. В таком случае команды пытаются начать с процесса оценки и перейти от старых добрых человеко часов к модным и зарекомендовавшим себя стори поинтам. И тут же возникают непредвиденные трудности. Дело в том, что не все учитывают то, что в разных процессах ограничен разный ресурс. Для Скрам-команд главное ограничение — это время. У них есть Спринт, который может длиться максимум 4 недели. С команды это снимает необходимость определять время выполнения каждой задачи, так как они всегда должны стремиться к тому, чтобы задача была сделана в срок Спринта. Для не Скрам-команд вопрос сроков всё ещё остаётся легитимным, и зачастую Команде всё же приходится на них отвечать. В таком случае ответ в стори поинтах не может удовлетворить интересы менеджмента и не поможет в дальнейшем планировании.

Для не Скрам-команд оценка в стори поинтах не может быть чем-то запрещённым. Если им удобно оглядываться на критерии объёма, сложности и рисков, то они могут оценивать так задачи. Но, к сожалению, для таких команд стори поинты — это не лучшая практика. Стори поинты — это максимально полезный инструмент для команд, которые живут в рамках итераций.

7. Нужно ли учитывать при оценке задачи скиллы ее исполнителя?

Отличительной особенностью стори поинтов как раз и является то, что задачи оцениваются относительно друг друга. Совершенно не имеет значения, кто именно возьмётся за работу над задачей — новичок или профи. Представьте, что вам нужно пробежать 1км. Да, каждый человек пробежит его за разное время, но это будет по-прежнему 1км. Оценка в стори поинтах никак не связана с уникальными способностями человека, который работает над задачей. С оценкой должны быть согласны все члены команды.

Если мы оцениваем задачу по способностям её исполнителя, то мы невольно возвращаемся к оценке задач по времени, что не совсем продуктивно, как мы выяснили в первом вопросе.

Авторы статьи: Карамнова Виктория, Кочарян Эмилия

Scrum: Планирование спринта в Story Points и Диаграмма сгорания задач (Burndown Chart)

Что такое Спринт (Sprint) в Скрам (Scrum)

Спринт – это промежуток времени в течение которого идет работа над запланированной работой (обычно от 1 до 4 недель). Величина спринта планируется из того как быстро вы можете завершать проекты в рамках работы вашей команды.

В IT-сфере в идеале в конце каждого спринта выдавать обновленную версию продукта с улучшениями и дополнениями.

Что такое спринт в скрам

Например, весь проект может занимать 5 месяцев, разбитых на 21 недельный спринт по 7 дней.

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

Планирование спринта обычно организует scrum-мастер и на нем product owner садится совместно с командой и решают какую часть продукта выпустить к концу спринта, и какие задачи из бэклога нужно для этого выбрать.

Как оценить силы команды на Spint (показатель Velocity)

Немаловажным вопросом во время планирования спринта является оценка сил команды для выполнения проектов в спринте – для оценки сложности проектов по трудозатратам используются специальные величины Story Points (SP)

Сложность любой задачи оценивается в определенном количестве Story Points (SP).

Чтобы понять лучше, что такое Story Points – вспомните простые элементы в конструкторе – это и есть SP, и из них можно собрать любую фигурку (задачу), или даже целую композицию из фигурок (проект).

Среднее количество Story Points в одном спринте называется Производительность команды за спринт (Sprint velocity) и рассчитывается делением суммы прошлых спринтов на количество выполненных Story Points.

Как оценить среднюю производительность за спринт (Sprint velocity)

Как оценить сложность задачи – играем в Planning Poker.

Сколько story points в индивидуальной задаче обычно каждый сотрудник оценивает сам на основании предыдущего опыта. Если задачи командные, то как правило проводится отдельное совещание, которая называется называется Planning Poker.

Опытные члены команды держат в руках карточки с написанным на них количеством SP (например могут быть номиналы по 1,3,5,10,50,100 SP), Product owner из общего списка задач (бэклога) задачи достает задачи по одной в порядке приоритетности, а участники игры показывают карточки SP, которые они бы дали этой задаче.

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

Story points – это универсальная величина, которой могут измеряться задачи из абсолютно разных сфер деятельности.

Например:
– провести совещание = 5sp, подготовить коммерческое предложение = 15sp, сделать 40 звонков клиентам = 10sp;
– Разработать модуль API – 25sp, сделать форму регистрации 7sp;
– Прочитать 1ю часть книги 10sp, прочитать 1ю главу 2sp;
– Приготовить суп 10sp, сходить в магазин 5sp, пропылесосить в комнате 2sp и т.д.

Планирование спринта в Story Points и Диаграмма сгорания задач (Burndown Chart)

Во время планирования спринта для Product Owner важно сделать 2 вещи:

1.Определить приоритетные цели для спринта

2.Грамотно оценить силы команды в Story Points на основании прошлого опыта, чтобы команда выполняла задачи равномерно по мере спринта.

Для этой цели ежедневно заполняется Диаграмма сгорания задач – график который показывает как уменьшается количество оставшихся Story Points по мере приближения к концу спринта (дедлайну).

График состоит из 2х осей: по вертикали – количество story points, по горизонтали – время

Диограмма сгорания задач (Burndown Chart)

На графике выше мы видим короткий спринт, который состоит из 7 дней. В среднем за такой спринт спринт команда выполняет задач на 50sp. Это значит что в среднем для того чтобы за 7 дней выполнить день нужно выполнять 7sp

Если команда опережает средние темпы, то линия уходит под график, это значит команда недооценила свои силы и поставила слишком легкие задачи.

Если линия сгорания story points уходит вправо от графика, это значит наоборот, команда переоценила свои силы, неправильно оценив объем работы в SP.

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

Совет из практики:
Рекомендуется держать некоторое количество задач наготове на случай, если выполнишь план на неделю быстрее. Список этих задач обычно называется коротким названием Next-up (Следующие) и по окончанию предыдущего спринта, он служит в качестве основы для формирования задач на новый спринт.

В чем польза диаграммы сгорания задач (Burndown chart) для руководителя:

Руководитель проектов / директор компании может смотреть как общую диаграмму сгорания задач (Burndown chart) как по отдельным проектам, так и индивидуально по каждому сотруднику, это позволяет быстро оценить текущее положение дел.

Также может строиться сводная Диаграмма сгорания задач (Burndown chart) по всему портфелю проектов.

Scrum: Почему story point-ы лучше, чем часы

Автор: Джефф Сазерленд

Впервые статья появилась в блоге Джеффа Scrum Log.

[В Scrum] многим менеджерам проектов, планирующим проект на основе часов, трудно понять, почему story point-ы лучше. Они не могут понять некоторые фундаментальные данные, опубликованные за последние 20 лет.

Во-первых, давайте посмотрим на последние данные о провалившихся проектах. [В прошлом году], число провалов IT проектов выросло из-за разрушения глобальной финансовой системы. Обзор Standish group survey показал, что 68% проектов не смогли уложиться в первоначальные оценки. То же самое показывает Forrester Group research:
Традиционные метрики привели IT отделы к краху

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

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

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

Лучшие данные по производительности разработчика представил Йельский Университет (о них я уже говорил в моем блоге).Выполнение одной и той же задачи занимает 1 час у лучшего разработчика в проекте, и 10 часов у худшего (внутри проекта) или 25 часов (если смотреть по всем проектам). Разница в скорости команд на порядок больше. Данные опубликованные Larry Putnam показывают, что один час для наиболее продуктивной команды оборачивается в 2000 часов для наименее продуктивной.

Потраченные часы ничего не говорят Product Owner-у о количестве фич (features), которые он может поставить, а также о том, когда он может их поставить.

Оценка в story point-ах лучше оценки в часах, поскольку она аккуратнее и имеет меньше вариаций. Компания с 5м уровнем CMMI определила, что оценка в story point-ах сокращает время эстимации до 80%, позволяя командам делать больше оценок, чем это происходит в типичной команде с каскадной моделью разработки. Телекоммуникационная компания отметила, что оценка в story point-ах с покером планирования в 48 раз быстрее, чем традиционные практики оценок, и дают настолько же точные или даже более точные результаты.

Таким образом, story point-ы быстрее, лучше и дешевле, чем часы. Высокопроизводительные команды полностью отказываются от оценки в часах, они смотрят на нее как на напрасную трату времени.

Доктор Джефф Сазерленд является одним из создателей Scrum, он также является старшим консультантом в OpenView Venture Partners. Он известен как тренер и спикер, и помогает бизнесу увеличить продуктивность с помощью Scrum. Его блог Scrum Log blog site.

Мини-справочник и руководство по Scrum

Данная статья – это мини-справочник и руководство по Scrum, созданные в результате прочтения книги Сазерленда и статей из интернета.

Надо различать Agile и Scrum. Agile – это методология (наука), а Scrum – это метод достижения цели.

Применяя Scrum важно иметь настоящую команду профессионалов, соблюдать условия прозрачности, открытости и доверия.

Члены команды должны быть довольны своей деятельностью, быть счастливыми в своей работе. Состояние счастья приводит людей к превосходным результатам.

Счастливые люди успешнее на 50%. А значит они на 50% более продуктивные, если счастливы и находят смысл в своей работе. При этом они на 88% более лояльны, потому что понимают, что работают не зря, посвящая половину своего времени развитию этого бизнеса

— доктор Корри Блок, эксперт по стратегии бизнеса в области оценки счастья.

Мини-справочник Scrum

Scrum (скрам) – схватка, гибкий метод управления проектами. Термин пришел из игры рэгби.

Product Owner (продакт оунэр) – владелец продукта, связующее звено между заказчиком и командой разработки. Самая главная ответственность Product Owner – это создание и контроль Product Backlog.

Основные обязанности и ответственность Product Owner при управлении Product Backlog:

Scrum Master (скрам мастер) – арбитр, который организует и проводит совещания, следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.

Scrum Master не дает заданий, а устраняет проблемы, появляющиеся внутри команды.
Кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д.

Development Team (дэвэлопмэнт тим) – команда разработки, кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: программистов, тестировщиков, аналитиков, архитекторов и т.д. Размер команды составляет от 5 до 9 человек (5 оптимально). Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Данная рабочая единица является самодостаточной, самоуправляемой и самоорганизующейся. Это как некий единый организм, состоящий из отдельных элементов.

Stakeholders (стэкхолдэрс) – дословно акционеры, лица, которые инициируют проект (бизнес-заказчики), которым скрам-проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review).

User – пользователь продукта.

Product Backlog (продакт бэклог) – или Backlog требования к продукту, пожелания заказчика по функционалу и дизайну, все «хотелки»; они расставляются по степени важности и ценности для заказчика.

Epic (эпик) – одна из нескольких глобальных функций продукта. В эпике могут содержаться User Story, например, пакет пожеланий одного пользователя или список задач (Task) для реализации Эпика.

User Story (юзер стори) – или Story, cюжет, в которых содержатся пожелания пользователя.

Task (таск) – задача, фрагмент, который необходимо выполнить для реализации цели проекта.

Sprint (спринт) – временной промежуток от 1 до 4 недель, за который команда создает часть продукта, готовую к демонстрации и ценную для заказчика. Оптимальная продолжительность спринта – 1-2 недели. Это делается для того, чтобы информация, полученная в начале первой недели, не забылась к концу второй недели и не требовалось время на восстановление связей.

Sprint Goal (спринт гоол) – цель спринта.

Sprint Planning Meeting (спринт плэнин митин) – планирование Sprint, скрам-собрание, где участвует Scrum Team. Выбираются задания из Бэклога, которые возможно выполнить за спринт.

Scrum Poker (скрам покэ) – быстрый и точный способ сбора оценок при помощи колоды карт с числами Фибоначчи (1,2,3,5,8,13). Можно использовать мобильные приложения для Scrum Poker. Задачи с оценкой 13 необходимо дробить на более мелкие.

Story Points (стори поинтc) – единица оценки сложности выполнения задачи. Story Points имеет смысл применять, если проект состоит из 3-х и более спринтов, так как у команды накапливается статистика и опыт оценивания задач. На проекте из одного-двух спринтов использовать Story Points нет смысла, если только не для получения практики.

Daily Scrum Meeting (дэйли скрам митин) – ежедневное собрание не более 15 минут, проводимое в одно и то же время. Участвует скрам тим, наблюдать могут все. Проводит скрам-мастер. Цель митинга – оперативный обмен информацией, все в курсе происходящего, нет коммуникационных разрывов. Задаются три вопроса: что сделал вчера? что будешь делать сегодня? какие препятствия встают на пути к цели?

Sprint Review (спринт ревью) – обзор спринта, участвуют все, встреча открытая. Команда рассказывает, что было сделано, и демонстрирует те части проекта, которые окончательно готовы.

Sprint Retrospective Meeting (спринт рэтроспэктив митин) – ретроспектива, участвует скрам тим. Собрание за «круглым» столом. Обсуждаются вопросы: что прошло хорошо, а что плохо? что можно было сделать лучше? Главное, никого не обличать! Рассматривается рабочий процесс. Цель – совершенствование рабочего процесса, стать «супер» командой.

Definition of Done (DoD) (дэфэнишин оф дан) – критерий, определяющий степень готовности задачи. Применяется в тех случаях когда окончательно невозможно проверить готовность задачи, например, если элемент функционала находится в другой скрам команде или компании. Описание DoD начинается со строчки «done = », например, done = функционал реализован в тестовой среде, требуется выгрузка и проверка в основной среде.

Velocity (велосити) – скорость команды; для аналитики строится график Velocity, где по оси Х кол-во спринтов, а по оси Y Story Points.На основе этих показателей выстраиваются средние Velocity и Story Points.

Burndown Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика сверху вниз. Предназначен для отслеживания оставшегося объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Первому дню спринта соответствует максимальное кол-во Story Points.

Burnup Chart (бёрнап чарт) – диаграмма сгорания задач. Направление графика снизу вверх. Предназначен для отслеживания объема работ, где по оси Х кол-во дней спринта, а по оси Y кол-во Story Points. Последнему дню спринта соответствует максимальное кол-во Story Points.

Abnormal Termination (Абнормол тёрминэйшн) – остановка спринта, аномальное действие. Остановку инициирует Product Owner. Происходит митинг, на котором обсуждаются причины возникновения Abnormal Termination. Затем Спринт запускается вновь.

Руководство Scrum

Product Backlog
Формируется при общей встрече или индивидуальных интервью со всеми заинтересованными лицами (стэкхолдерами, пользователями). Записываются User Story, требования и пожелания.

Задачи с компонентами типа: 3IIIC, 5VE сложнее и требуют больше времени.

123, ABC – быстрее, потому что мозгу не надо переключаться между разными типами задач.

User Story

Происходит совместно с Development team. Команда должна оценить каждую задачу: выполнима ли она в принципе? достаточно ли информации для выполнения?

Формируется Sprint. Sprint Planning Meeting. Scrum Poker

Продолжительность митинга не более 8 часов. Для 2-x недельного спринта митинг длится 2 часа. Для визуализации исполнения задач в спринте удобно использовать Kanban-доску.

Расставление Story Points (за основу взят ряд Фибоначчи – 1,2,3,5,8,13). Задачи 13 и более поинтов необходимо дробить на более мелкие. Срок выполнения задачи одним разработчиком не более одного дня или 8 часов. Если в проекте всего один спринт, то нет смысла расставлять Story Points, потому что не будет статистики и соответственно не будет точности определения оценок.
Для корректного присвоения Story Points можно вести статистику, как, например, в такой таблице:

Проводится каждый день. Все могут наблюдать. Говорит только Scrum Team. Проводит Scrum Master.

Участвуют все. Знаменуется значительным приростом функционала продукта. Демонстрация работы готового продукта или функционала.

Длительность митинга: по одному часу на каждую неделю спринта (2 часа Sprint Review = 2-х недельному спринту).Подготовка к данной встрече не должна превышать 2-х часов.

Sprint Retrospective Meeting. Ретроспектива.

Проводится в последний день спринта.

Призвана оценить результат команды. Задаются вопросы: что можно улучшить? как? как повысить эффективность команды?
Время на ретроспективу для 2-х недельного спринта не более 2-х часов.
Понятие Кайдзен и счастье. Кайдзен – непрерывное совершенствование. Счастливые люди = высокая производительность команды.

Можно задать вопросы: Что может сделать вас счастливее в следующем спринте? Что сделает вас счастливее вообще?

Сеть оценок для планирования в Scrum

Предлагаемое решение

Решение, которое я называю “оценочной сеткой” — визуальная таблица, по одной строке для каждого размера истории, которым вы пользуетесь. Если вы пользуетесь рядом Фибоначчи для оценок, у вас будут строки для “0.5”, “1”, “2”, “3”, “5” и “8”. Затем для каждого размера (в каждую строку) вы размещаете несколько карточек с историями, примерами в этом размере. Вот иллюстрация как это должно выглядеть:

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

Ещё пара советов как построить сеть

Ещё один трюк, снимающий сложности, которые могут возникнуть у многих членов команды: важно помнить, что значит конкретное значение оценки. Например, «5» — это сколько? Давайте вспомним, как мы проводим оценки. Если команда верит, что размер истории больше «3» и меньше «5» – он становится «5». Так что «5» означает все истории в интервале от 3 до 5. Если вы это помните, становится намного проще поместить две достаточно разные по размеру истории (например, одна чуть больше, чем 3 и другая чуть меньше, чем 5) в один ряд, как одинаковые. Я даже показываю эти интервалы рядом с размером в первой колонке (как вы можете видеть на картинке) чтобы визуально напомнить об этом. И вы пересматриваете и улучшаете эту сеть со временем. Во время ретроспективы каждую итерацию, или раз в несколько итераций, вы проходите по сетке, чтобы проверить все ли присутствующие там истории всё ещё актуальны, и, может быть, стоит добавить новые истории, с которыми вы работали.
Лучше всего если у вас будет 2-5 карточек примеров в каждом размере. Вам нужен какой-то минимум как базис для оценок, и у вас не должно быть слишком много примеров, потому что это только затруднит и замедлит сравнение.
Пара примеров как это может выглядеть в реальной жизни:

Нет смысла помещать в вашу сетку все возможные размеры историй (как 20, 40 или 100). Нужно сфокусироваться только на размерах, которые актуальны для историй достаточно маленьких, что бы зайти в итерацию. Это зависит от вашего выбора размера. Моя рекомендация – всё до 8.
Этот инструмент очень просто внедрить и использовать. Из моего опыта, у него очень низкий уровень сопротивления со стороны команд, то есть его хорошо принимают. Это пример простого процессного эксперимента, который вы можете обсудить со своей командой на следующей ретроспективе и попробовать, не сильно рискуя.
Если у вас есть вопросы, задавайте в комментариях – буду рад помочь.

Оценка требований в Scrum

Я расскажу о оценке работ(estimation) в скрам. Её рекомендуется проводить дважды — сначала в story points, на уровне user stories, а потом — в часах, на уровне заданий в текущей итерации. Так же я попытаюсь объяснить, почему это делается дважды.

У нас в компании решили более серьёзно отнестись к введению Agile принципов, а конкрентей — Scrum. Мне поручили внедрить это дело в небольшой проект, который должен быть готов к сентябрю, с 4 программистами и веб-дизайнером. Задача проекта — миграция html-сайта в Sharepoint 2010, и добавление многих новых функций.

Раньше мы как-то считали, что утренний Scrum митинг — это уже вполне такой нормальный скрам. Но, немного почитав и поковырявшись, оказалось, что в общем-то не совсем.

Итак, первоначальная оценка — guesstimate

Первоначальная оценка проекта производиться на уровне user stories которые находятся в Product Backlog. User stories рекомендуется писать в слегка незграбной, с первого взгляда, манере:
«Как [тип пользователя] я хочу [выполнить действие] чтобы [причина]» (As a [type of user] I want [some goal] so that [some reason]).

Например, вместо привычного «Студент должен иметь возможность выбрать желаемый курс» — «Как студент, я хочу выбрать желаемый курс чтобы получить нужные знания». С одной стороны, звучит очень искусственно, но с другой — и программист, и представитель бизнеса понимают, кто, что и зачем хочет сделать. В коротком предложении есть контекст, роль, действие и цель, всегда в той же самой структуре. Удобно. Хоть и непривычно.

Мой бэклог состоит из 40 историй такого уровня. Это — недостаточно детальные требования, чтоб произвести точные оценки, но кое-что можно сделать — оценить бэк-лог в story points.

Что такое story points? Это относительная оценка каждой истории. Теория предлагает использовать степень двойки для оценки( 2, 4, 8. ) или ряд Фибоначчи (1, 2, 3, 5, 8. ).

Для того, чтобы оценить, надо сначала выбрать систему, и максимальное значение. Мы решили использовать Фибоначчи, с максимальным значением 21.

Дальше, надо выбрать самую простую историю и оценить её как 1. В нашем случае это история — «Как пользователь, я хочу просмотреть информацию о тренерах, чтобы знать их компетенцию». После этого выбираем самую сложную историю, и оцениваем её как максимум, в нашем случае — 21. Это история «Как подписчик, я хочу заказать курс, чтобы я мог его посетить».

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

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

Так почему же story points, а не дни?

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

Какой в этом толк?

Во-первых, product owner может пересмотреть свои приоритеты. Раз история А «стоит» 13 очков, а Б всего лишь 2 — давайте сделаем её скорей.
Во-вторых, это помогает планированию. Если мы знаем, что в первом спринте мы сделали 50 story points, во втором — 55, то в третьем наверно тоже сделаем каких 55.
В-третьих, это проще. «А» сложнее «Б», поэтому 21.

А что дальше? Где нормальные цифры?

Обычные человеко-часы начинаются позже.
Первый спринт самый сложный, особенно у нас — с новой командой, новой технологией и новой методологией. Вместе с product owner мы опредилили 9 историй для первой итерации.
Для точной оценки мы сели с самым опытным программистом, и учитывая отсутствие опыта у остальных, провели оценку. По-нормальному и тут надо было в покер играть, но ситуация не та.
Чтобы получить точные оценки, каждую историю надо разбить на задания. Каждое задание должно быть не более 8 часов, чтобы за день было понятно, сделано оно или нет. Мы разбили наши истории на 2-10 заданий, примерно такого рода «Построить UI для страницы тренеров», «Подготовить список тренеров» и т.д. Оценили каждую в часах, и получилось… Что нам надо раза в 3 больше времени! Пришлось уменьшить бэклог итерации.

В итоге мы получили, что в первой итерации мы можем закончить 67 story points. Это — 105 часов работы. То есть, сейчас скорость нашей команды — 67 story points за итерацию. По мере того, как команда ознакомится с новой технолонией, скорость вырастет, и в следующем спринте мы сможем разработать больше story points. Используя оценку в часах, это было бы невозможно, или надо было бы выдумывать какие-то формулы, типа там, «в каждой последующей итерации мы спланируем на 10% больше чем в прошлой».

Myth: Story Points are required in Scrum

If you prefer, you can also listen to us reading this post.

Today we address the idea that work on the Product Backlog must be estimated in Story Points. The majority of the teams that we work with do this, and there really is nothing inherently wrong with it. The myth begins where people misunderstand the purpose of estimation in Scrum and Story Points become an end in themselves.

For those unfamiliar with Story Points; teams that use this technique estimate effort with relative estimates instead of time-based estimates (e.g. hours, days). This is usually done with a simplified version of the Fibonacci sequence (0, 1, 2, 3, 5, 8, 13, 20, etc). The numbers have no meaning in themselves, but only in relation to other items. So an item of 5 points takes roughly twice as much effort from the team as an item of 3 points, and so on. Several methods exist to estimate Story Points, including Planning Poker and Magic Estimation.

Although the use of Story Points is the most widely spread technique, we could easily generalize this post to include estimates in hours, ideal days or t-shirt sizes for that matter.

Busting the Myth

As with previous posts, let’s start with what the Scrum Guide says on estimation. Although it states that “work may be of varying size, or estimated effort”, it does not prescribe how this estimation should be done. Although Scrum Teams should apply some sort of ‘estimation’, there is no mention of Story Points, hours, ideal days, gut feeling, t-shirt sizes or any other unit for that matter. The Scrum Guide does remind us to use an approach that respects the complexity of software development and to not let estimation replace the importance of empiricism itself.

So we can easily bust this myth with the Scrum Guide alone. But a more thorough explanation helps to better understand why.

The purpose of estimation in Scrum

In plan-based approaches, estimates are used to arrive at budgets and to determine delivery dates. Supposing that the estimates are accurate, they provide us with a means to manage (financial) risks of spending either too much money or spending money on the wrong things.

The primary purpose of estimates in Scrum is to give Development Teams a rough sense of the amount of work they can pull into a Sprint. This requires a conversation between members; ‘What is involved?’, ‘How should it work?’ and ‘What work is needed?’. Although the Development Team commits to achieving the Sprint Goal, they do not commit to completing all this work within the Sprint. As even within a single Sprint, unexpected problems and insights are likely to emerge.

This underscores that the role of estimates is quite different in Scrum — and something that people coming from a plan-based perspective often struggle with. Scrum is built on the observation that software development is a very complex endeavor, making it impossible to arrive at accurate estimates. In complex environments, what will happen in the (near) future is largely unknown. New and better insights will emerge and unexpected problems surface as we work together to discover both the problem and the (most suitable) solution. Instead of relying on estimates to forecast and control what happens in the future, we should use the empirical process of Scrum to capitalize on change rather than control against it. As the Scrum Guide observes: “Only what has already happened may be used for forward-looking decision-making”.

“Use the empirical process of Scrum to capitalize on change rather than control against it.”

This provides us with four important insights with regard to estimates:

Instead of spending a lot of time and effort on estimation, we’re better off spending that time on building valuable software and using the empirical process of Scrum to learn. The question now becomes; what method of estimation is ‘just-good-enough’ to help Development Teams select a do-able amount of work for a Sprint and getting a sense of what is needed, while requiring as little time and effort as possible.

Time-based estimates — hours, ideal days — are one option. A major disadvantage is that they tend to uphold the illusion of accuracy and predictability, and are often interpreted as such. Another disadvantage is that their illusion of accuracy often drives teams into ‘analysis paralysis’, where all details need to be discussed in-depth in order to arrive at a detailed estimate.

“Time-based estimates uphold the illusion of accuracy and predictability.”

This is why the use of relative estimation, in particular ‘Story Points’, was popularized by Extreme Programming. Relative estimates are not based on units of time, and avoid all pretense of detail and accuracy. But they can provide Development Teams with a guide on the amount of work they may be able to complete within a Sprint. Take this example:

Suppose a Development Team has been working together for 20 Sprints. The empirical process of Scrum has taught them that they can complete — on average — 35 points of work (their so-called velocity). Based on what has already happened, the Development Team has a rough sense of the amount of the work (about 35 Story Points) that they can pull into their next Sprint. Furthermore, this empirical data (

35 Story Points) can be used by the Product Owner to create a rough forecast for specific features or releases. If a Development Team can take on 35 Story Points of work per Sprint, and there are 350 Story Points of work on the Product Backlog, it would not be unreasonable to anticipate another 10 Sprints to complete the Product Backlog in its current state.

So Story Points are a lightweight approach to get a rough idea of how much work can be completed in a Sprint. It remains a rough indicator, however. But at least it is based on what has already happened and not on what we hope will happen. Estimation in hours or ideal days is certainly still an option, but teams need to be aware of their disadvantages.

Other ways to estimate, if you really want to

Despite the initial attractiveness of Story Points, they are easily abused. For example, they are often used to compare Scrum Teams on their performance. Or organizations enforce bureaucratic and administrative requirements for estimating each and every item on the Product Backlog with Story Points. So we often recommend teams to use even simpler approaches:

Although these approaches may complicate forecasting based on historical results compared to Story Points or time-based estimates, they are viable alternatives that fit well within the Scrum Framework and its purpose for estimation.

Why estimate at all?

If estimation is largely waste, it makes sense to ask: “Why even bother?”. This point is raised by the #NoEstimates-movement. They encourage to build small chunks of value incrementally, leading as rapidly as possible to a desired shippable product, without spending endless hours on trying to predict the future. In other words, they shift the focus to optimizing the flow of work during a Sprint. Using Kanban within Scrum is an excellent example of this, and something we highly recommend.

Some form of estimation may still be helpful though. In many situations, it does help focus the conversation within a Development Team on what is needed for a particular item. Having to arrive at some kind of estimate, often helps to trigger the right kind of discussions: “What is needed?”, “Can we find a simpler solution?”, “Have we considered X?”. Estimation is not so much about the estimates, but about the discussions that it triggers. It’s about having a conversation — ideally with the actual customer — and creating a shared understanding.

“Estimating is often helpful, estimates are often not.” — Esther Derby

Closing

In this post, we busted the myth that Scrum requires work to be estimated in Story Points. Although it is a useful technique, and used by many Scrum Teams, it is by no means the only technique. And sadly, we’ve seen it abused so often that we usually recommend simpler techniques. We used this post to describe some alternatives and to explain why Story Points became prevalent. By doing so, we also explained how estimation fulfills a different role in Scrum than compared to plan-based approaches.

Above all, remember the quote by Esther Derby: “Estimating is often helpful, estimates are often not.” The more complex the activity at hand, the more important communication and collaboration gets.

“Respect the complexity of software development, and don’t let estimation replace the importance of empiricism itself.”

What do you think about this myth? Do you agree? What are your lessons learned?

«Образцовый» Scrum-проект: клиент доволен, разработчик — нет

Как обнулить достоинства Scrum для клиента — объясняет директор по развитию Grotem на примере разработки сервиса регистрации онлайн-касс.

Этот кейс — для компаний, которые заказывают ИТ-разработку, и для разработчиков, которые только присматриваются к Scrum (есть такие?). Я расшифрую обязательные термины Scrum и объясню:

Если вы каждый день говорите «нам пора на дейли» — вам будет скучно читать. Хотя кто знает.

Десятки согласований, обоснований, килограммы бумаги и строгие письма в почте: «Просим придерживаться первоначального ТЗ, мы его полгода писали», «Бухгалтерия не одобрила ваше предложение по изменениям, требуется детально прописать, на что именно будет потрачен каждый час». Долго, нервно, некомфортно.

Часто заказчик не готов работать по Scrum. Тогда исполнитель идёт на хитрость: снаружи менеджеры строят декорации, похожие на Waterfall, а внутри команда работает по принципам Scrum. Зачем? Потому что сейчас бессмысленно делать большинство проектов по классике: слишком быстро всё меняется, слишком много неопределённости.

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

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

Клиент — производитель онлайн-касс «АТОЛ». Проект — бесплатный сервис быстрой регистрации касс. Мы были знакомы: за год до этого интегрировали своё «кассовое» приложение с кассами «АТОЛа».

Главная ценность сервиса — одно окно. Предприниматель покупает кассу у партнёра «АТОЛа», партнёр тут же её регистрирует. Предпринимателю нужно знать только ИНН и захватить флешку с электронной подписью. Не надо связываться с ФНС, забивать массу букв и цифр, рискуя ошибиться и потерять фискальный накопитель стоимостью 7000 рублей.

В схему вовлечена налоговая, операторы фискальных данных (ОФД) и сервис Dadata.ru, предоставляющий безошибочные данные предпринимателя для регистрации кассы.

Заказчик решил презентовать сервис с базовыми функциями 15 марта, на конференции партнеров «АТОЛа». К этому сроку нужно было сделать интеграцию с одним ОФД — Яндекс.ОФД. Первый спринт стартовал 10 января.

Спринт — это срок, за который команда разработчиков закрывает несколько «хотелок» на основе бэклога продукта. Например, две недели.

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

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

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

Первые два спринта пристрелочные. Надо понять, какой объем задач реально делать за две недели и планировать так, чтобы команда не сидела без работы и не ночевала в офисе.

Во время спринта владелец продукта не вносит новые хотелки и не меняет приоритеты. Если появились идеи, лучше подождать обсуждения следующего спринта.

Сколько спринтов будет на проекте, сразу сказать нельзя. Могут появиться новые задачи, которые сделают продукт лучше. Или придется от чего-то отказаться, потому что выяснится, что это неактуально. Наш проект длился 12 спринтов, 120 рабочих дней. После презентации 15 марта мы продолжили улучшать продукт — например, интегрировали сервис с другими ОФД.

Если цель спринта достигнута, он считается успешным. Бывает, заказчик говорит: «Давайте этот спринт признаем успешным, там совсем немного осталось доделать, тем более причина не в вас, а в чужом API». Такие предложения принимать нельзя, а владельцу продукта их лучше не озвучивать.

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

Запомнить: заказчику важно научиться формулировать user stories, поставив себя на место пользователя, и определять цель спринта.

Оценка спринтов — самое сложное. В Scrum задачи рассчитываются не в часах, а в относительных единицах. Обычно их называют story points (для простоты — стори-поинты). Стори-поинты включают в себя риски, сложность и внешние факторы: потерю связи с сервером ФНС, проблемы с ОФД и так далее.

Некоторые команды вместо стори-поинтов используют разные размеры футболок (S, M, XL) или породы собак. Одна задача «весит» как такса, другая, посложнее, — доберман, третья — сенбернар. Это весело, когда делаешь внутренний продукт и сам себе заказчик. Когда заказчик внешний, его бухгалтерия вряд ли такое оценит.

В каждом спринте у нас 35-40 стори-поинтов. Если задача «весом» пять стори-поинтов не доделана, заказчик экономит сразу на пять стори-поинтах — засчитывается только стопроцентная готовность.

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

На время проекта команде выделяется отдельная комната. Здесь все равны и каждый отвечает за продукт, а не только за свою часть работы. Учитывайте это, не спрашивайте: «Кто у вас главный?»

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

Да. Грубо говоря, один из десяти спринтов уходит на общение, девять — на разработку.

Сначала было ощущение, что слишком много времени тратится на всякие собрания. Можно же потратить его на разработку продукта.

Новички в Scrum удивляются: как можно четыре-пять часов тратить на разбор двухнедельного спринта. На самом деле такое собрание в конце каждого спринта (ретроспектива) очень важно. Ретроспектива помогает команде стать командой, здесь открыто говорят, что чья-то Metallica в наушниках мешает работать и что кому-то пора перестать опаздывать.

Если спринт признан неуспешным, это главная тема собрания: команда разбирается в причинах и делает выводы, чтобы улучшать результат от спринта к спринту.

Желательно, чтобы на первых двух ретроспективах был владелец продукта (у нас — с помощью Zoom). Это помогает построить доверительные отношения и лучше понять, как работает команда.

— У меня не получается с передачей данных ФНС. Максим, помогай.

— Хорошо, в 16:00 займусь.

Здесь участие владельца продукта не требуется.

Перед ретроспективой, в тот же день, заказчик участвует в обзоре спринта (он же ревью, он же демо). Фактически это приёмка, именно здесь решается, считать спринт успешным или нет.

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

Вот что написал клиент в ответ на просьбу оценить наш общий Scrum-опыт:

Scrum дал нам продукт ожидаемого качества в ожидаемые сроки. На текущий момент продукт готов к использованию.

Мы недовольны, потому что сервиса нет на рынке. Формально он готов, но доступа у клиентов «АТОЛа» к нему нет.

Пока мы ускоренно разрабатывали и улучшали продукт, продвижение буксовало. Надо было уже в январе рассказывать о сервисе, получать обратную связь от рынка. К маю большинство партнёров должны были уметь пользоваться сервисом и предлагать его клиентам.

Так бы не пропустили ажиотаж — ведь предприниматели спешили зарегистрировать кассы к 1 июля, чтобы не иметь проблем с ФНС. Момент упущен, десятки тысяч предпринимателей не получили дополнительную ценность.

Главный вывод для заказчика: работайте по Scrum, это быстрее «классики» с техзаданиями, честнее и часто дешевле. Выпускайте продукт на рынок через пару месяцев, не ждите идеальную версию.

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

Как мы познакомились с Agile & Scrum

Введение

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

Предыстория, с чего все началось, как пришли к тому что нужен Scrum

Я работаю руководителем IT-отдела (менеджером проектов) в одной маленькой/средней томской фирме. Численность работников в IT-отделе на начало деятельности: 5 человек, на данный момент: 24 человека.

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

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

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

Как все было до Scrum

Изначально у нас был развернут старенький Redmine без всяких плагинов и настроек, можно считать его практически чистым, TeamCity (бесплатный) для обеспечения хоть какого-то билдинга, SVN, куда же без репозитория. В Общем все работало.

Задачи ставились в redmine, по мере выполнения проставлялись часы а иногда и проценты выполнения, но зачастую не было ни сроков ни каких-то планов, очень везло, если был хотя бы обговоренный dead-line.

И тут настало мое время. Руководство дало мне добро на применение всего, что душе угодно (принесет больше прибыли). Как я уже писал выше — это лето 2014.

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

Естественно все было перенесено и в электронный вид: по некоторым задачам зафиксировано в redmine в виде feature или epic, по некоторым в старом добром Excel, также поставили важность и приблизительные сроки выполнения задач. Потом мы приступили к декомпозированию и оценке задач с каждым работником, который будет выполнять задачи. Получился набор feature с sub-tasks и оценкой сроков выполнения задач. Получился своеобразный backlog, но с ним дальше нужно как-то работать, сам по себе он не дает результатов.

Диаграммы Гантта

За некоторое время до этого я сталкивался с Диаграммами Гантта (ленточные диаграммы) в фирме, в которой работал программистом. Сделал пару диаграмм по нашим проектам, наброски показал руководству, и эта методика им понравилась. И я приступил к изучению инструментов, которые позволили бы мне в наилучшем виде сделать эти самые диаграммы.

Мной были опробованы:

В итоге, потыкавшись с некоторыми программами и время от времени их меняя, мы несколько месяцев вели проекты с активным использованием диаграмм Гантта. Руководству это все нравилось, они видели четкие и утвержденные планы, и, вроде как, все устраивало, за исключением небольшого НО (большого).

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

Вот тут то и возникла потребность в чем-то ином.

Какие потребности были

Собрав feedback от руководства и главных действующих лиц компании, был сформирован некий список того, что же хотелось увидеть:

Что рассматривал еще

Почему Scrum удовлетворяет потребности

Как донес до всех

Основные концепции разработчики и так понимали из статей, так что с ними проблем практически не возникло, все восприняли с энтузиазмом. Основной проблемой было руководство, но так как оно в процессах практически не участвует, то нам и карты в руки.

Как изучил? Что смотрел? Какие ресурсы? Какие книги?

Общение с профессионалами

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

Чтение статей

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

Чтение книг

Начало внедрения

Документ с основными мероприятиями

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

Карты

Естественно нужно было где-то достать карты для Poker-planning. пересмотрели в интернете ряд магазинов, стоимость колоды для четырех человек варьировалась от 1000 рублей до 2000 рублей. Денег просить у руководства мне особо не хотелось, и поэтому я их сделал сам. Обычная бумага А4, черно-белый принтер, ножницы, — вот что вышло:

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

Интересный факт. Надеюсь я ничего не перепутал. Один из немногих на тот момент магазин по продаже колод карт, который мне мне понравился — planningpoker.ru. Подумал тогда, какие же прикольные карты. Позже, спустя несколько лет на конференции директор фирмы, которая организовала этот магазин, подарил мне одну из таких колод совершенно случайно. (ссылка есть в источниках и ссылках)

Доска

Следующий важный этап, это подготовка Scrum-desk, взял обычные ватманы, пару А3 и А4, маркеры, скотч и др. И получилось довольно таки неплохо:

Что получилось в результате подготовки

Первый опыт, первый sprint

Backlog

Первый backlog мы строили в MS Excel, разбили все, как нужно на колонки:

Естественно, присутствует еще ряд колонок, которые не вошли на рисунок, но это другая история. Подчеркну, у нас получились именно задачи (feature), а не пользовательские желания (user-story), как это принято в Agile. Первый sprint было принято решение сделать двухнедельным. Расставили приоритеты, отсортировали, пометили зеленым, что хотелось бы взять на sprint, расставили story-points. Хм, что такое story-point?!

Как довел до сведения разработчиков. Story-point — день

На систему оценки в story-points — идеальные человеко дни, перейти достаточно сложно и непонятно для разработчиков. Как мы объясняли story-point — это идеальный восьмичасовой рабочий день разработчика, когда у него есть все под рукой, ничто не отвлекает его от работы (уже заметны проблемы, есть все и не мешает хм. ), он находится в изолированном от других помещении, где есть свежий воздух, еда, чай/кофе, туалет и он продуктивно выполняет поставленную задачу, решение которой ему полностью ясно. Некоторые вещи еще добавлялись при объяснении новичкам, но они особо не имеют значение.

Распределение ролей

В нашей компании практически нет cross-разработчиков? есть отдельные тестировщики и мы разрабатываем под различные платформы. Соответственно, мы слабо ложимся на одно из понятий Scrum, как унификация работников. Мы им пренебрегли и в первом sprint’е у нас участвовали разные разработчики в одной команде.

Планирование

Были распечатаны все features из backlog’а, которые должны были пойти в sprint, и мы начали оценку.

Какие действия на планировании sprint’a нами предпринимались:

Составили Scrum-list (в MS Word):

(ссылка есть в источниках и ссылках)

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

Ежедневные планерки

На первую планерку все явились, как по часам, что не радует (в дальнейшем было все не так радужно). Собрались, начали обсуждать поочередно у кого как что идет, вопросов и проблем ни у кого не было. Перешли к Scrum-desk.

Доска задач в бумажном виде

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

Изначально стикеры просто лепились на доску, но со временем стали их закреплять дополнительно на скотч, было пару прецедентов когда все слетало. Позже появилось еще пару столбцов типа: in testing, code review и т.п.

Зачем нужна burn-down?

Burn-down нужна для того чтобы можно было отслеживать прогресс выполнения sprint’а у команды, а также для того чтобы в визуальном виде можно было видеть отклонения от выполняемого плана по времени. Основная цель burn-down: показать команде (так как у нас самоорганизующиеся команды), что нужно принять оперативные меры, если произошло отклонение.

Как строить burn-down?

Множество инструментов позволяют строить burn-down диаграммы в электронном виде, мы воспользовались MS Excel, а также строили на ватмане.

Изначально (позже появлялись дополнительные столбцы) наша таблица содержала:

Как видно по диаграмме — первый sprint прошел практически удачно, небольшие отклонения от идеального исполнения. НО, как гласит правило: Если по окончанию sprint’a есть не сожженные story-points, то sprint провален. На это правило, на тот момент, мы закрыли глаза и радовались успешному завершению sprint’a!

Демонстрация

Пришло время продемонстрировать руководству результаты sprint’a. “Команда” (менеджер) подготовила свою презентацию, в дальнейшем каждый член команды делал свою часть. Изначально не было стандарта презентации. Собралось много зрителей: руководство, часть отдела продаж и маркетинга.

Презентацию делали в MS Powerpoint:

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

Где и как проходила демонстрация

Так как у нас, на тот момент, не было conference-room презентация проходила в кабинете разработчиков, достали проектор и светили на стену.
Изначально выступил менеджер (я) рассказал для чего все тут собрались, рассказал основные цели и задачи sprint’a, и начали выступать по очереди разработчики, завершилось все выступлением менеджера с демонстрацией burn-down диаграммы и вопросами со стороны публики.

Основные задачи менеджера на демо:

Разработчики на первой демо

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

Публика на демо

Со стороны публики было много отвлеченных вопросов, которые косвенно относились к демонстрируемому sprint’у, на которые они очень хотят получить ответ, — это очень затягивает демонстрации и по сей день. Первая демонстрация длилась часа полтора.

Ретроспектива

Первый sprint прошел удачно и для разработчиков. Отзывы были только положительные.

Какие улучшения были обсуждены на первой ретроспективе:

Feedback от руководства

Все понравилось, требуется больше слайдов в презентацие. Руководство захотело привязывать премиальную часть ЗП разработчиков к результатам демонстрации sprint’a: заинтересованные лица проставляют субъективные оценки каждому разработчику с проставлением критериев этой оценки, оценка менеджера — среднее арифметическое из всех оценок. Данная система не особо прижилась, но это уже совсем другой рассказ.

Как все пошло

После первого sprint’a уже много воды утекло, было предпринято множестве действий по оптимизации процессов, некоторые имели какой-то profit, многие нет.

Какие меры предприняли

Объединение команд, почему случилось

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

Да, — это помогло выиграть некоторое время, но, Нет, — это не дало положительных результатов. Такое продлилось четыре sprint’a, но так как у команд был совершенно разный профиль разработки, разработчикам было совершенно незачем работать вместе.

Разделение команд

Со временем работников становилось больше и становилось больше направлений разработки, появлялись то мобилки, то еще что-нибудь. Как я говорил в пункте с объединением команд, людям совсем не за чем работать вместе, если между ними нет прямой связи в разработке проектов. Соответственно, мы разделили команды по разным направлениям. Да, — это дало продуктивный результат для каждой отдельной команды, но каждая команда, сожрала уйму времени менеджера.

Варьирование времени sprint’ов

Попробовали различные вариации:

Перешли на доску с маркерами

Отказались от ватманов, некрасиво смотрится, разработчикам не нравилось это на обоях.

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

Следующий этап: стали писать ежедневные таблицы митингов маркерами на доске:

Таблица содержит: число, столбец сжигания задач не из плана, столбец сжигания задач из плана.

Перешли на облачное решение: google doc

Стали вести burn-down диаграммы в google таблицах. С течением времени стали добавляться еще значения в таблицу:

Так как при длительном sprint’e у нас появилась тенденция: не укладываться в sprint (запасы пробовали брать, ни к чему хорошему не привело), ввели новое значение — off-plan, которое показывает график с учетом сжигания не запланированных задач.

Далее пошли еще дальше, ввели еще три значения: Real, Off-plan (error) и Off-plan (extra):

Перешли в google презентации

Удобное решение, можно работать всем одновременно:

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

Попробовали плагин для Redmine

Поставили плагин для Redmine, его название — Backlog’s. Дает возможность организовывать работу с backlog’ом продукта и sprint’ами через Redmine:

У данного плагина есть электронная доска задач, которая полностью повторяет функционал той, которая у нас была вначале в реальном виде. Все столбцы подхватываются из Redmine, — это значение статуса задачи. Sprint замещает значение и функционал «версии» в Redmine. Достаточно удобный плагин, мы его используем и сейчас.

Ввели регалиеметр

Отражает суммарно сожженные story-points каждого работника за все sprint’ы. Стимулирует работников работать более продуктивно, каждый работник способен брать на sprint определенное количество story-ponts. Видя, что другие ребята работают продуктивнее него, работник предпринимает попытки, чтобы достигнуть более хороших результатов. У нас среднее количество story-points на двухнедельный sprint — это семь.

Какие улучшения дали нововведения

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

Что же происходит сейчас?

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

Дало ли результаты?

Придуманная и внедренная система дает следующие результаты:

Что планируем делать дальше

В данный момент у нас, опять, активно внедряется 1С Битрикс, руководство хочет чтобы все работники были в одной системе. Планируем изучать новый инструментарий и смотреть, как нашу работу можно перенести в CRM. На данный момент есть кое-что на примете: доска для Битрикса — scrumban.ru. (ссылка есть в источниках и ссылках)
Есть планы при помощи MS Project применять метод освоенного объема в параллели ко всей нашей системе.

Заключение

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

Scrum — нюансы применения в распределенной команде

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

Важные книги по Скрам

Важные книги не про Скрам

Скрам не решит всех ваших проблем, полагаясь только на этот метод, можно потерпеть фиаско. Книги, которые помогут в управлении любой командой:

Особенности Скрам

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

Первое, на что следует обратить внимание, есть ли у вас обратная связь с конечными пользователями и вносите ли вы изменения в создаваемый продукт с учетом этой информации. Если нет, то будьте уверены, у вас не Скрам.

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

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

Четвертой особенностью Скрам, является его способность предоставления возможности самореализации членам команды, исключения бесполезной работы, простоев, прожигания жизни.

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

Насколько точно надо придерживаться правил Скрам?

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

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

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

Не забывайте о том, что многое, что является вполне естественным и не требующим объяснения для американского читателя, не является таковым для российского. Многие практики, эффективные на западе, совершенно не работают у нас. Это может быть обусловлено, помимо различий в культуре и законодательстве, например, довольно большой властью американского работодателя над работником. Работодатель в США может очень быстро уволить сотрудника, а увольнение там может означать потерю страховки, способности платить по счетам, потери собственности, даже нищите. У нас же увольнение иногда ничего не меняет, да и уволить иногда не удается. Отсюда и разное отношение к работе, компании, начальнику, конкуренции, саморазвитию, корпоративной культуре. Отсюда возникают разное понимание одного и того же текста, разное применение одних и тех же методов.

Доски со стикерами

Не могу пройти мимо этого явления. Если команда находится в одном офисе, может быть это и неплохое решение, поскольку позволяет общаться всем членам команды лицом к лицу. Кроме того, митинги у доски проходят стоя, что должно помогать избегать длинных собраний. Однако, информация, написанная на стикерах от руки плохо читаема и непонятна новым членам команды. К стикеру нельзя приаттачить файл, добавить описание или ссылку. Непонятно на кого назначена та или иная задача. Да, на стикерах можно указать идентификаторы тикетов Jira, но это не решает проблему. Часто можно заметить, что возле доски собирается более 20 человек, при том, что классическая Скрам команда должна иметь в своем составе не более 9 человек. Во время проведения таких собраний образуются небольшие группы сотрудников по интересам или специализации, которые начинают независимые совещания, мешая друг другу. И такие совещания, как показывает практика, не проходят быстро, несмотря на то, что проводятся на ногах. На доске часто можно увидеть вместо трех — пяти столбцов целый десяток и больше. Но самое неприятное в наличии доски — это отсутствие единого источника правды, т.е. существуют одновременно как доска так и dashboard в Jira. Пора прекратить пользоваться досками. Ниже я приведу описание митинга, который подойдет как для офисной, так и для распределенной команд.

Роли членов команды

Роли членов команды могут быть, например:

Вариант команды в реальных условиях

Предположим, у нас небольшой стартап с ограниченным бюджетом, и мы не можем себе позволить по одному или более человеку на каждую роль. Вакансии опубликованы на upwork, собеседования проводят SM и SA. Для найма членов команды вы можете воспользоваться рекомендациями из моей статьи «Онлайн тестирование — вы серьезно?». Сформированная команда состоит из следующих удаленных сотрудников (взято из реального проекта):

Процесс

Каждый день проводится стендап (короткий митинг на 15 минут не более), на котором присутствуют все члены команды. Каждый из членов команды кратко отвечает на два вопроса “над каким тикетом работаю” и “что меня блокирует”. Все митинги проводятся по возможности через Zoom или другую систему, позволяющую видеоконференции с демонстрацией экрана. Для митингов, тренингов и деловых встреч создаются специальные тикеты. Это мотивирует SM к сокращению длительности митингов. Если митинги длятся дольше чем 15 минут, значит SM что-то делает неправильно.

Колонки в проекте в Jira (вариант):

Предположим, что члены команды живут в разных часовых поясах от Екатеринбурга до Чикаго. Оптимальным временем для митинга может быть, например 15:00. SM запускает трансляцию своего экрана через Zoom, открывает dashboard проекта в Jira. Затем SM включает фильтр тикетов како-го либо из членов команды, при этом становятся видны тикеты только этого члена команды.

Этот сотрудник кратко рассказывает о своих тикетах в колонке In Progress и о трудностях, с которыми он сталкивается, о том, что его блокирует. Далее SM переключает фильтр на другого сотрудника. SM следит за тем, чтобы выступления членов команды были короткими. В моем случае я настоял на отдельном тикете для списания времени, потраченного на митинги, и спустя 2 недели SM сильно сократил длительность митингов, посчитав их стоимость. Если у кого-либо возникают вопросы, требующие дополнительного обсуждения, то они обсуждаются на отдельном митинге, время которого определяет SM. Создание любого митинга сопровождается рассылкой приглашения в персональный календарь каждому из участников. Использование календаря избавляет участников от необходимости пересчета времени проведения митинга в локальное время. Выявив и обсудив все проблемы, возникшие на данный момент, SM принимает меры по их устранению, координируя действия всех членов команды.

Разработка ведется поэтапно спринтами по 1 или 2 недели. Результатом каждого спринта является промежуточная версия системы с некоторым новым функционалом (фичами). SM создает, запускает и закрывает спринты.

SA конфигурирует билд и деплой на тестовый стенд из какой-либо ветки Git, которую можно условно назвать dev. Ветка dev заблокирована для прямых коммитов, возможен только Merge request (MR). Разработчик делает MR, если уверен, что качество и завершенность фичи достаточны для использования конечными пользователями. Недоделанные фичи в dev не попадают, MR не создается.

PO и SM согласуют требования, собирают все необходимые материалы в Confluence, создают спецификацию. Гибкие методы отодвигают документацию на второй план. Я сталкивался как с системами, где нет никакой документации, так и с системами, где ее настолько много, что в этом океане информации ничего невозможно найти. Ситуация с обилием документации усугубляется примитивностью поискового движка Confluence. Оптимальным решением является компактная спецификация. Она представляет собою страницу в Confluence, в которой есть схематичное изображение интерфейса (mockup) с отметками и выносками. Под изображением находится описание функционала и поведения каждого элемента, отмеченного на схеме. В тексте есть ссылки на релизы и тикеты в Jira. В нижней части страницы идет обсуждение в комментариях.

Перед началом спринта SA формирует бэклог, создает новые стори и добавляет их в будущий спринт, назначает разработчиков на каждую стори. Разработчики разбивают стори на подзадачи, определяют Estimate (приблизительное прогнозируемое время разработки) в часах и минутах. Полученное суммарное время подзадач определяет количество Story points из расчета 1 Story point = 6 часов. Далее тимлид распределяет стори по разработчикам исходя из расчета 8-12 Story points на разработчика на спринт. SM запускает спринт.

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

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

Разработчик создает ветку в Git по имени тикета стори, например MVP-123. По завершении каждой подзадачи разработчик записывает в Jira фактическое затраченное время на каждую из подзадач. В качестве TimeSheet рекомендую Tempo. По окончании отчетного периода (2 недели или 1 месяц), разработчик запрашивает утверждение отработанных часов у SM, формирует счет на оплату, отправляет его SM. Когда все задачи в стори готовы, разработчик перемещает все тикеты (стори и подзадачи) в столбец Code review. При этом разработчик создает MR своей ветки в dev, копирует ссылку на него и помещает в комментарии к тикету стори, назначает тикет на ревьювера (сеньора или тимлида). Изменение исполнителя сопровождается его оповещением по электронной почте.

Когда тимлид заметил новые тикеты в Code review он изучает MR и, если находит недостатки, пишет их в комментариях в GitLab, перемещает тикеты назад в столбец In Progress. Разработчик дорабатывает код, добавляет комментарий в GitLab (или в другой системе), нажимает Resolve discussion в комментариях, переносит тикеты в Code review. Особенностью GitLab является невозможность добавления нескольких ревьюверов. Это часто бывает необходимым, если изменения затрагивают, например, как фронт, бек, так и базу данных. В BitBucket такая возможность есть.

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

В некоторых ситуациях, многочисленные MR, даже в случае удачного слияния, приводят к невозможности сборки или невыполнимости части unit тестов. Иногда это становится известно после того, как одна из сред перестала работать, что блокирует, например, QA. То есть тимлид может провести ревью и принять MR, но это не гарантирует успешность сборки или выполнения unit тестов. Для решения этой проблемы, например, в GitLab есть возможность настройки Development Pipeline. По сути это автоматическая сборка и тестирование коммита, который указан в MR. Код ревью выполняется только после успешного выполнения Development Pipeline. Если Development Pipeline “падает” с ошибкой, разработчик, сделавший MR, устраняет ошибку и делает дополнительный коммит.

Тимлид принимает код и принимает MR, при этом происходит автоматическая сборка и деплой на тестовый сервер. Тимлид переносит код в столбец QA.

QA приступает к тестированию новых изменений в соответствии со спецификацией. QA создает программы ручного тестирования. В случае неудачного тестирования, тикет переводится в столбец In Progress — возвращается на доработку, либо создается баг-тикет в Jira, который SM назначает на какого-либо из разработчиков. После того, как тестирование завершено успешно, тикеты переводятся в Demo ready и, впоследствии, фича демонстрируется на еженедельном Demo митинге. Если фича принимается, тикет переводится в Done.

В случае, если задачи не завершены к окончанию спринта, они переносятся на следующий спринт.

PO и SM определяют набор фич (стори), которые попадут в тот или иной релиз, планируют дату релиза. Перед релизом QA осуществляют регрессионное тестирование. В момент релиза создается специальная ветка в Git и замораживается для изменений. Изменения релизов возможны в исключительных случаях и производятся через бэкпорты. Бэкпорт — специальный процесс внесения изменений в релизные ветки. В некоторых компаниях для бэкпортов создаются специальные команды.

По окончании каждого спринта проводится Retrospective митинг, на котором обсуждается все проблемы, накопившиеся за спринт, определяются проблемы и препятствия, которые задерживают процесс разработки, принимаются решения о способах устранения препятствий. Для ретро заводится специальная страница в Confluence, в которой записывается: что мы делаем, что мы начинаем делать и что мы прекращаем делать.

Что необходимо для работы (вариант)

Учет времени

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

Хороший разработчик Self motivated (самомотивирован), стремится сделать больше в единицу времени, опережая estimate сроки, повышать свой авторитет, увеличивать шансы стать сеньором, тимлидом, иногда шансы на получение опциона. Он активен, генерирует идеи, непрерывно изучает новые технологии, дорожит своим временем. Если в команде не отлажены процессы и разработчик простаивает без задач, если разработчик выполняет работу, которая никому не приносит пользы, если работа никак его не развивает, то он начинает ощущать, что тратит драгоценное время своей жизни впустую. Как результат, он уходит на другой проект. Скрам позволяет разработчику избежать прожигания жизни, помогает самореализоваться, ощутить свою причастность к важному делу.

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

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

Иногда бывает, что скорость разработчика оценивается путем сравнения предварительно оцененного времени и фактически затраченного. То есть если разработчик опережает оценки, то его поощряют и наоборот. Считаю, что такая оценка должна использоваться как неточная, ориентировочная, второстепенная. Предварительная оценка времени (estimate) может быть сделана только приблизительно. Более точная оценка может быть сделана только в том случае, если подобные задачи решались многократно, однако повторяющиеся задачи встречаются нечасто. Даже обладая большим опытом и высокой точностью прогнозирования времени выполнения, вы не будете застрахованы от неожиданностей. Например, применение многократно использованной в других проектах библиотеки, оказало непредсказуемое влияние на систему, причем баг проявляется во время выполнения, и логи ни о чем не говорят. Если нет готового решения на StackOverflow, можно превысить Estimate в несколько раз. Надо понимать, что Estimate — это грубая оценка, которая может использоваться как ориентир. Превышение разработчиком Estimate, и если оно не является систематическим, не должно приводить к критике со стороны руководства.

Как правило, фактически затраченное время всегда меньше Estimate. Если задачи сложные и разработчик видит, что для решения потребуется провести небольшое исследование, он может указать Estimate с запасом, но он не должен злоупотреблять этим.

SM или тимлид, или кто-либо еще в команде должен оценивать реалистичность Estimate. Это может сделать только опытный разработчик, обладающий, к тому же, доверием руководства.

Пусть удаленный разработчик оценил задачу в 2 часа, а выполнил ее за 1 ч 33 мин и записал это фактическое затраченное время в Tempo, перевел тикет в Code review и взял в работу следующий. Возникает вопрос, можем ли мы доверять разработчику, ведь он мог сделать эту задачу за 15 минут, а остальное время уделить онлайн играм или даже другим проектам? Ответ — да, можем доверять. Самое главное, на что должен обращать внимание SM, являются ли сотрудник эффективным, являются финансовые затраты на сотрудника приемлемыми в единицу времени. Обеспечивается ли такая скорость команды, которая позволит запустить MVP до окончания взлетной полосы стартапа. Во-первых, точные временные затраты на выполнение той или иной задачи да еще и при заданном уровне качества просто физически невозможно определить. У одного разработчика уйдет на это 2 часа, а у другого 15 минут, поскольку многое зависит от опыта и способностей. Кроме того, в любом проекте есть старожилы и новички. Старожил найдет решение за считанные минуты, в то время как новичок может потратить несколько дней на исследования. Во-вторых, разработчик может искать решение не только в момент написания кода, но и в любое нерабочее время. Идея может посетить человека совершенно неожиданно и в любой момент. Оценивать качество полученной идеи и ее реализации простым учетом времени, потраченного на кодирование, неэффективно. Это одна из причин низкой эффективности применения трекеров времени — разработчик работает не только в момент непосредственного написания кода. Ко всему, трекеры времени вносят элемент недоверия, превращают творческий процесс в каторгу.

Если SM не уверен в правдоподобности фактически списанного на задачу времени, он может заглянуть в GitLab и сопоставить изменения кода, сделанные по этой задаче, со списанным временем. Разработчик не может списать 2 часа за 2 строчки кода. Если SM не разбирается в программировании, он может пригласить эксперта для оценки реалистичности списанного времени, например SA. Как бы тами ни было, адекватный разработчик не будет списывать лишнее время, поскольку понимает, что реалистичность может быть проверена, а испорченную репутацию и доверие потом не восстановить.

Вернемся к разработчику, который выполнил задачу за 1 ч 33 мин и приступил к следующей. При этом, он списал за первую задачу 2 ч как было в Estimate. SM сможет легко определить, что интервал времени между переводом задачи в статус In Progress и Code review существенно меньше, чем списанное время. То есть факт приписки может быть легко установлен, обращать внимание разработчика на этот факт или нет, SM определяет сам. Конечно, разработчик может переводить задачи в те или иные статусы в точном соответствии со списанным временем, несмотря на то, что он не работал так много. Или он может переводить в In Progress сразу несколько тикетов, чтобы время начала работ было как можно более ранним — надо договориться о последовательном переводе тикетов в работу. В любом случае, не стоит беспокоиться! Напомню, для SM намного важнее польза, которую этот человек приносит за потраченные на него деньги в единицу времени. SM в любой момент может исключить любого члена команды из проекта, но это может привести к непредвиденным затратам на поиск и адаптацию нового члена команды, взятого взамен уволенному.

SM также может обратить внимание на то, что затраченное время всегда или почти всегда совпадает с Estimate. Для SM это звоночек, закрывать на это глаза или нет, решать ему в зависимости от ситуации.

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

Финансовые отношения

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

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

Как мы делали SCRUM

Страшный сон команды разработчиков — это когда до начала разработки надо «нырнуть» в неизвестную предметную область и «проэстимейтить» half-baked idea. При этом нужно буквально «подписаться кровью» за результат в назначенный срок за фиксированные деньги.

На деле дать точную оценку неточных требований нереально. Типичный путь в проектном менеджменте — составить подробнейшее ТЗ перед началом разработки. А затем реализовать весь функционал одним большим куском. Но такой «вотерфольный» подход грозит уже другими рисками: запуском проекта в стиле «большого взрыва» — когда ты получаешь первый результат в самом конце проекта. И он может оказаться очень далек от реальных бизнес целей и нужд пользователей.

Зачем так рисковать, если можно пойти совершенно другим путем?

Зачем SCRUM

Когда при ознакомлении с проектом есть понимание «мы знаем, что мы этого не знаем» и даже «мы не знаем, где границы того, чего мы не знаем», выручает SCRUM

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

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

Но есть и плюсы: заказчик на старте не должен детально и скрупулезно описывать все функции и особенности огромной будущей системы. А так же может практически в любой момент изменить приоритеты и подстроиться под внешний конкуретный рынок.

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

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

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

Смотрите, как мы организовали всю работу: важные ключевые решения — какую следующую ценность дать бизнесу — команда принимает перед каждой новой итерацией постоянно, в результате система развивается по критически-оптимальному пути до тех пор, пока не превратится в максимально соответствующую бизнесу. Заказчик здесь является частью команды. За успешность разработки отвечают и исполнитель, и заказчик. Они — по одну сторону баррикад.

Именно так было и у нас, давайте посмотрим?

Мы хотим рассказать о нашем пути адаптации классического SCRUM-фреймворка в работе над автоматизированной системой управления для «Академии современного образования А+» — это современный образовательный центр в Киеве, в который входят школа, детский сад, центр раннего развития, музыкальная, танцевальная и спортивная школы, художественные студии и центр изучения иностранных языков. Всего в Академии занимается более тысячи детей на почти 150 различных курсах.

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

Достоинство SCRUM и, для некоторых, недостаток в том, что это очень легковесный фреймворк. Он не содержит ответы на все вопросы и детальные инструкции для участников команды. Scrum — «умышленно неполный», и за счет этого универсальный.

SCRUM необходимо адаптировать к каждому конкретному проекту

Как заказчику и исполнителю начать работать по SCRUM?

Для работы в незнакомой парадигме иногда заказчику приходится менять привычное мышление. Оказаться в одном контексте с исполнителем. Поэтому перед разработкой системы для Академии мы организовали совместный тренинг с ребятами из Scrum Ukraine. Его главные цели: познакомиться, вникнуть в терминологию, отработать все методики в игровой форме, смоделировать основные активности, понять с чего начать, распределить роли и прописать обязанности.

В ходе трехдневного совместного тренинга мы, используя так называемый helicopter view, сформировали будущую систему крупными мазками и зафиксировали это на временной прямой в виде Project RoadMap.

helicopter view — a general description or opinion of a situation, rather than a detailed one

Глобальный Product RoadMap

Какие мы сделали выводы после этого этапа

Все наши договоренности в виде короткого списка

Шаг №1: Бизнес-анализ и адаптация методологии

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

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

Хотя SCRUM не требует наличия спецификации на разработку, то, что у нас было готово описание предметной области, оказалось большим плюсом. Этот документ лег в основу product backlog — базы для старта SCRUM. Product backlog — список требований, историй, функционалов, которые упорядочены по степени важности. С такого списка все начинается. При этом все требования описаны на понятном для заказчика языке. Элементы этого списка — user story, «пользовательские истории».

User story — это описание простейших пользовательских сценариев использования системы, суть которых можно сформулировать так: «кто, что, для чего делает, каковы особенности и ограничения».

Наш product backlog из 203 истории, для удобства сгруппированных по сегментам

Пример user story

Какие мы сделали выводы после этого этапа

Шаг №2: Планирование спринта. Как мы адаптировали Sprint planning

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

Как это было. Для нас обязательно было получить 2 вещи: сформулированную цель спринта и утвержденный sprint backlog.

Наш product owner всегда начинал планирование спринта с описания того, что в первую очередь нужно сделать, — наиболее значимых историй. После этого команда производила оценку трудозатрат для всех user story, начиная с самой важной. В процессе у команды возникало много вопросов по поводу того, как это должно функционировать.

Sprint planning — это очень важная SCRUM-активность. Все осознают ответственность за правильную оценку, потому что:

Пример sprint backlog

Электронный журнал после первого спринта

Упрощения и допущения для первого спринта. В системе — 2 пользователя: преподаватель и родитель; один класс — 5«А»; настоящий состав класса, внесенный вручную напрямую через SQL запросы; настоящее расписание для 5«А», сформированное также напрямую через запись в таблицы.

User story #1: преподаватель заходит в систему и проставляет оценки по любому предмету из расписания класса за день. Система с одной простой, но уже работающей функцией. Уже на sprint demo преподаватель сказал, чем пользоваться удобно, а чем — нет, чтобы в следующих спринтах команда могла запланировать корректировки и дать обновленный инструмент.

Какую реальную ценность дает: оцифрованная успеваемость реального класса, актуальные оценки, перспектива для автоматической подготовки месячной, семестровой, квартальной отчетности.

User story #2: еженедельный отчет родителям об успеваемости на почту.

Какую ценность добавляет: информирование родителей о текущей успеваемости; комментарии преподавателя к домашнему заданию; минимальную, но реальную аналитику.

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

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

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

Эта версия электронного журнала была получена после 12 спринта и ее можно было показывать родителям

Еще яркий пример итеративного SCRUM-подхода — конструктор расписания

Первый конструктор расписания заказчик получил через 2 месяца после старта проекта. Это был «брутальный редактор» для очень продвинутого пользователя. Но он позволил нам ввести расписание для всех пятых классов и протестировать систему на настоящем живом расписании.

На его доработку до «визуального редактора» ушло три спринта. Фокус разработки несколько раз переключался, но к началу учебного года заказчик получил полнофункциональный конструктор расписания, с помощью которого всего за час ввел расписание с первых (А, Б, В, Г) по восьмые классы.

Проследим маршрут «брутальный редактор для настоящего админа» — «визуальный редактор» — «конструктор расписания»

А как делали расписание до этого?

Расписание составляли на склеенных листах ватмана А1 вручную: рисовали, выделяли цветными маркерами, склеивали. На это у завуча уходили недели и месяцы

Самая первая версия редактора: «Брутальный редактор для админа» — который составил расписание на 2018 год

Вторая, улучшенная версия, с помощью которой было составлено расписание 2018/2019

Конструктор расписания — окончательная версия

Какие мы сделали выводы после этого этапа

Как сделать, чтобы команда оценивала user story реалистично

Команда всегда адекватно оценит user story, если выполнены условия: подробно описано поведение реального пользователя, обозначены границы использования и допущения, перечислены критерии приемки. То есть команда понимает «что» нужно сделать и примерно предполагает «как».

Почему важно формулировать «критерии приемки» и «границы использования» — это дает одинаковое понимание объема работ для историй как со стороны product owner, так и со стороны команды.

Шкала оценки, или SCRUM-poker

В SCRUM оценка историй проходит не в часах или днях, а в story points. Это микс сложности, рисков и усилий, которые команда должна потратить, чтобы выполнить историю. Для каждой команды 1 story point — величина индивидуальная, эмпирическая, но каждый член команды чувствует ее.

Заметьте, последовательность значений на карточках — нелинейная. Вот, например, между 13 и 21 ничего нет. Почему так?

Во-первых, это нужно, чтобы избежать появления ложного чувства точности для больших оценок. Если история оценивается примерно в 17 story points, то нет смысла обсуждать, должна ли она быть 15, или 18, или 21. Все, что нам нужно знать, — историю сложно оценить. Поэтому мы назначаем ей оценку в 21. Ориентировочно.

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

Очень важно: оценку должен выдать каждый участник команды. Почему?

Важно: Во время планирования мы обычно не знаем, кто будет выполнять ту или иную часть. Реализация user story требует участия специалистов для разных типов работ: архитектура, front-end, back-end, тестирование, подготовка реальных данных. Отдельно стоит такая группа работ, как проектирование и дизайн пользовательского интерфейса.

Яркий кейс: Живая лента

В системе управления школой возникает много событий разной степени значимости. Например, ученик получил оценку; произошла замена, и вместо математики будет биология с другим учителем; с учеником произошел досадный инцидент, и родителей надо немедленно информировать; преподаватель написал важный комментарий к ДЗ.

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

Живая лента в финальной реализации

Яркий кейс: Живая лента

Обсуждаем среди разработчиков, во сколько мы оцениваем объем работ по истории «Живая лента».

Каждый высказывается, сколько story points потребуется. Выяснилось, что у нас большие расхождения во взглядах, и обратили внимание на крайние мнения: почему кто-то оценил 50, а его коллега уверен в 5 story points. Так сразу мы обнаружили невыявленные требования, которые заметил более осторожный разработчик. Плюс вскрылись глобальные задачи, связанные с персонализацией. Это прекрасный пример того, как команда может предвосхитить трудности.

Какие выводы мы сделали по методике оценки

Шаг №3: Спринт запущен. Как мы адаптировали sprint execution и ежедневный SCRUM

Ежедневный SCRUM-meeting, или stand-up, да и весь SCRUM — это история про эффективные коммуникации, которые помогают экономить время и усилия команды. Это не просто «встречи» и «разговоры». Они не отнимают время, которое можно было бы потратить на работу, а помогают оптимизировать усилия. Один из принципов SCRUM так и звучит: «Люди и взаимодействие важнее процессов и инструментов».

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

Кроссфункциональность: команда готова выполнять любые задачи по запуску продукта

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

Опыт каждого ценен для поиска самого эффективного решения.

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

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

Майя Сокольская, Scrum Master

Какие выводы мы считаем важными для этапа sprint running

Шаг №4: Как мы проводили демонстрацию результатов. Наша адаптация sprint demo

Разработчики по очереди демонстрируют новый функционал вживую на реальных данных. Фокус — на том, ЧТО мы сделали, а не на том, КАК мы это делали. Вообще мы постоянно стремимся, чтобы наше демо было бизнес-ориентированным, без упоминаний про технические детали.

Как узнать, что решение подходит заказчику

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

Какие выводы мы сделали по методике проведения демонстрации результатов

Шаг №5: Как мы адаптировали и проводили retrospective

Для нас ретроспектива — это важное мероприятие сразу же после sprint demo. Ретроспективы полезны, особенно когда что-то идет не так. Без ретроспектив может оказаться, что команда наступает на одни и те же грабли снова и снова.

Как застраховаться от повторения ошибок

Самые частые грабли — это когда реальная производительность команды сильно отличается от прогнозируемой. Реальная производительность рассчитывается на основании начальной оценки каждой истории. И когда в середине спринта мы понимаем, что история, оцененная в 5 story points, делается столько же, сколько обычно занимает задача на 13story points и далека от завершения, а если это еще и блокирующая история, — другие не могут быть начаты из-за неготовности проблемной. Когда цели спринта под угрозой — ретроспектива неизбежна.

Наши ретроспективы имеют абсолютно четкую структуру и цели: команда собирается вместе. Scrum Master зачитывает sprint backlog, просит высказаться каждого члена команды и оценить с его точки зрения итоги спринта. Каждый член команды высказывает свое мнение, что удалось сделать хорошо, что пошло не так и — главное — почему. Что продолжать делать, а от чего отказаться. При этом его никто не перебивает. Свои выводы, записанные на стикере, он помещает в одну из колонок:

Пример наших улучшений по результатам одной из ретроспектив

«После того как команда закончит мозговой штурм по поводу всех проблемных стикеров, я провожу «точечное голосование»: каждый член команды имеет три голоса (тремя точками маркера на стикерах). Он может отдать все свои голоса сразу одной проблеме, а может распределить иначе. Основываясь на этом командном голосовании, мы выбираем 2-3 улучшения, на которых фокусируемся в следующем спринте. А в начале следующей ретроспективы проверим, что у нас вышло. Так сказать „проверка домашки“ :)»

Одна неделя работы может сэкономить один час планирования

12% — много, но это того стоит, так как в классическом «водопаде» цена использования методологии — это отдельная роль проджект-менеджера. В среднем по нашему сегменту рынка на менеджмент затрачивается около 15% от стоимости разработки.

Какие выводы мы сделали по методике проведения ретроспектив

Шаг №6: Как мы адаптировали product backlog refinement, или Grooming

Многие коллеги, знакомые со спецификой IT, засомневаются: как во время планирования спринта команде может быть все настолько ясно, что она готова давать оценку всем user story.

Да, действительно, без подготовки такой слаженности не выйдет. Для того чтобы это так работало, существует специальная SCRUM-активность: product backlog refinement. Для ее проведения необходимо попросить product owner дать горизонт планирования: очертить, какие истории могут быть кандидатами на ближайший спринт. Если среди них окажутся истории, требующие углубленного изучения или специальных компетенций, которых нет у команды, назначается собрание — grooming/pre-planning.

Результаты grooming

Наш product owner был очень компетентным, поэтому мы всегда имели достаточный горизонт видения, как система будет развиваться, и регулярно проводили refinement. Ведь прозрачность — это один из основополагающих принципов SCRUM.

Так выглядит план проведения grooming

Какие выводы мы сделали по методике проведения refinement

Фэйлы

Да, мы откровенно в восторге от разработки по методологии SCRUM, но это не означает, что все проходило гладко. Вот три момента, где мы бы подстелили соломки, если знали заранее, что пойдет так.

Работа по привычным схемам

На одной из ретроспектив мы детально проанализировали причину аномального отклонения «реальной производительности» команды во всех историях с участием дизайнеров. Реальная производительность обычно рассчитывается по формуле: прогнозируемая производительность /фактическая производительность.

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

Как результат: задачи выполнялись последовательно, разработчики тратили время на последовательное включение на разных этапах с задержками, вызванными необходимостью доводить до конца уже начатые задачи.

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

Лишняя работа над ненужным функционалом

На втором спринте product owner поддался мнению одного из завучей, который считал что «журнал куратора» — крайне важный функционал. Мы взяли эту историю в спринт, потратили на нее усилия.

Почему ошибка: этот инструмент можно было тестировать только на поздних этапах, так как ему требовались накопленные данные, которых на тот момент не было.

Как результат: его не проверяли, не использовали, не развивали. Нужные функции были решены иначе и совсем не так, как думал тот завуч, совсем через другие инструменты. Вывод: берите в работу только то, чем сразу же начнут пользоваться.

Равнение на продвинутых пользователей

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

Вывод: подтверждать историю на regular customers.

Общие выводы

Про гибкость: SCRUM позволяет быть эффективной командой

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

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

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

Про максимально эффективное использование ресурсов

SCRUM — форма организации работы, выгодная заказчику и исполнителю. Чем?
Работа итерациями позволяет уже на ранних стадиях понимать, что идет не так, а значит — вовремя вносить коррективы. Подготовка к каждому спринту и специфика его организации помогают всякий раз делать только то, что нужно заказчику, и не уходить в сторону. И это дает колоссальную ЭФФЕКТИВНОСТЬ затраченных ресурсов, времени и усилий.
Заказчик уже на начальных этапах получает работающий участок системы: после первых спринтов берет сделанный функционал в работу и тестирует его в деле.

SCRUM — когда обе стороны застрахованы от рисков

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

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

Заказчик платит фиксированную сумму за каждый спринт, и делает свой бизнес еще на один шаг эффективнее

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

Каждый спринт повышает уровень компетентности исполнителя, ускоряет его в реализации проекта.

Итого, всего за 7 месяцев мы сделали работающую и полностью устраивающую заказчика систему, проверенную им на практике и отражающую все пожелания, а не выдали систему, теоретически спроектированную по ТЗ, которую еще несколько месяцев нужно будет докручивать, так как практика неизбежно внесет свои коррективы.

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

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

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

Заказчик получил прекрасный продукт: набор инструментов для современной школы, способный быстро трансформировать ее в школу будущего

Методология Scrum

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

Что такое методология Scrum и для чего она применяется

исследовать и выявлять жизнеспособные рынки, технологии и возможности продуктов;

разрабатывать новые и улучшать старые продукты в короткие сроки;

выпускать продукты и обновления, разрабатывать безопасные среды для их использования, подстраиваясь под изменения рынка;

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

Ключевые понятия в Scrum

В методологии Scrum используются следующие ключевые понятия:

спринт — период от 1 до 4 недель. За эти сроки создается фрагмент продукта, ценного для пользователя. Перед запуском проектной командой планируются этапы создания релиза и формулируются требования к нему.

Роли в Scrum-методологии представлены:

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

Артефакты и практики в Scrum

При разработке продукта по методологии Scrum для определения результата используются следующие термины:

В любом Scrum-проекте выделяют следующие артефакты:

В Scrum-управлении проектами используются следующие основные практики:

Более подробно ознакомиться с методологией Scrum и научиться ее применять на практике можно, записавшись на курсы обучения, которые проводит ЦРК БИ (ЦЕНТР РАЗВИТИЯ КОМПЕТЕНЦИЙ В БИЗНЕС-ИНФОРМАТИКЕ) НИУ ВШЭ. Запись проводится на нашем сайте.

Оценка требований в Scrum

Я расскажу о оценке работ(estimation) в скрам. Её рекомендуется проводить дважды — сначала в story points, на уровне user stories, а потом — в часах, на уровне заданий в текущей итерации. Так же я попытаюсь объяснить, почему это делается дважды.

У нас в компании решили более серьёзно отнестись к введению Agile принципов, а конкрентей — Scrum. Мне поручили внедрить это дело в небольшой проект, который должен быть готов к сентябрю, с 4 программистами и веб-дизайнером. Задача проекта — миграция html-сайта в Sharepoint 2010, и добавление многих новых функций.

Раньше мы как-то считали, что утренний Scrum митинг — это уже вполне такой нормальный скрам. Но, немного почитав и поковырявшись, оказалось, что в общем-то не совсем.

Итак, первоначальная оценка — guesstimate

Первоначальная оценка проекта производиться на уровне user stories которые находятся в Product Backlog. User stories рекомендуется писать в слегка незграбной, с первого взгляда, манере:
«Как [тип пользователя] я хочу [выполнить действие] чтобы [причина]» (As a [type of user] I want [some goal] so that [some reason]).

Например, вместо привычного «Студент должен иметь возможность выбрать желаемый курс» — «Как студент, я хочу выбрать желаемый курс чтобы получить нужные знания». С одной стороны, звучит очень искусственно, но с другой — и программист, и представитель бизнеса понимают, кто, что и зачем хочет сделать. В коротком предложении есть контекст, роль, действие и цель, всегда в той же самой структуре. Удобно. Хоть и непривычно.

Мой бэклог состоит из 40 историй такого уровня. Это — недостаточно детальные требования, чтоб произвести точные оценки, но кое-что можно сделать — оценить бэк-лог в story points.

Что такое story points? Это относительная оценка каждой истории. Теория предлагает использовать степень двойки для оценки( 2, 4, 8. ) или ряд Фибоначчи (1, 2, 3, 5, 8. ).

Для того, чтобы оценить, надо сначала выбрать систему, и максимальное значение. Мы решили использовать Фибоначчи, с максимальным значением 21.

Дальше, надо выбрать самую простую историю и оценить её как 1. В нашем случае это история — «Как пользователь, я хочу просмотреть информацию о тренерах, чтобы знать их компетенцию». После этого выбираем самую сложную историю, и оцениваем её как максимум, в нашем случае — 21. Это история «Как подписчик, я хочу заказать курс, чтобы я мог его посетить».

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

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

Так почему же story points, а не дни?

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

Какой в этом толк?

Во-первых, product owner может пересмотреть свои приоритеты. Раз история А «стоит» 13 очков, а Б всего лишь 2 — давайте сделаем её скорей.
Во-вторых, это помогает планированию. Если мы знаем, что в первом спринте мы сделали 50 story points, во втором — 55, то в третьем наверно тоже сделаем каких 55.
В-третьих, это проще. «А» сложнее «Б», поэтому 21.

А что дальше? Где нормальные цифры?

Обычные человеко-часы начинаются позже.
Первый спринт самый сложный, особенно у нас — с новой командой, новой технологией и новой методологией. Вместе с product owner мы опредилили 9 историй для первой итерации.
Для точной оценки мы сели с самым опытным программистом, и учитывая отсутствие опыта у остальных, провели оценку. По-нормальному и тут надо было в покер играть, но ситуация не та.
Чтобы получить точные оценки, каждую историю надо разбить на задания. Каждое задание должно быть не более 8 часов, чтобы за день было понятно, сделано оно или нет. Мы разбили наши истории на 2-10 заданий, примерно такого рода «Построить UI для страницы тренеров», «Подготовить список тренеров» и т.д. Оценили каждую в часах, и получилось… Что нам надо раза в 3 больше времени! Пришлось уменьшить бэклог итерации.

В итоге мы получили, что в первой итерации мы можем закончить 67 story points. Это — 105 часов работы. То есть, сейчас скорость нашей команды — 67 story points за итерацию. По мере того, как команда ознакомится с новой технолонией, скорость вырастет, и в следующем спринте мы сможем разработать больше story points. Используя оценку в часах, это было бы невозможно, или надо было бы выдумывать какие-то формулы, типа там, «в каждой последующей итерации мы спланируем на 10% больше чем в прошлой».

Story Points: The Why and How

Story points are always a source of trouble and discussion. People argue about what they are or represent, what they are useful for and how they are determined.

All the more reason to do an article about them.

You will be surprised at what they have to offer.

In fact, Story points aren’t as trivial as they might seem at first glance. And that’s a reason for many – sometimes strange – discussions that are so common in the communities.

Content of this article

Why Story Points?

Let’s first talk about the why. For what do we use story points?

Story points are a tool to determine the velocity of teams.

Velocity – another funny word. The speed of teams. OK. How fast can a team implement a certain scope? At first, “how fast” is not the problem. We are used to expressing this in time units.

Calculating the Scrum Velocity

But what does scope mean? And how should this be measured objectively – i.e., so that we can compare it?

This is where story points enter the game. But more about that later. We’ll stay with the purpose for a moment, which is to determine the velocity of a team.

Why do we want to determine velocity anyway?

What for and how, those are the key questions here. First of all, let’s talk about the what for.

Everything for the organization

Organizations have a natural interest in keeping track of the economic impact of all their activities. When a project is started – ideally, even before that – an organization would like to know what the project will cost. However, thanks to time-to-market, they usually know fairly well when the project will go live. When it comes to costs and detailed scope, there are usually only a few vague ideas.

Unfortunately, Scrum is always chosen as a methodology when a sufficient specification of the item to be created is not available, but time is short. This can be for multiple reasons such as too complex requirements, time-to-market requirements, etc.

So there is absolutely nothing on which one could build a valid estimate and a nice project controlling with a neat Gantt chart and milestones together with resource planning etc. Organizations don’t like that.

If one doesn’t even know the item, it would at least be helpful to know what processing speed my team has.

Sit back. Relax.
And let SharePoint runScrum!

The first all-in-one scaled agile project management suite for SharePoint

Or in metaphorical terms: If I don’t know the route to my destination, it would at least be helpful to know the speed of the car I’m driving. I still don’t know exactly when I’ll arrive, but I could plan the individual sections of the route that are directly ahead of me. In other words, I’m no longer completely in the dark and the more the overall route becomes brighter, the more accurate my planning gets.

This should occur at the latest after 20 to 30 percent of the duration of the project. You should have about 80 percent certainty much earlier: at the point of no return. But we will discuss that at a different point.

The SAFe authors have even been persuaded by the context described here to demand normalized story points. I will come to this later on. Now we’re going to clarify story points and their application.

Everything for the Teams

Of course, Scrum teams also have a strong interest in knowing if they are getting better as a team or stagnating, so that they can then take appropriate measures in retrospectives.

This is also a circumstance that should not be underestimated and that we need to consider as well. Because I’ve often read that the velocity of strong and experienced teams doesn’t fluctuate anyway. Most recently, with the SAFe authors mentioned above, but also elsewhere.

I don’t know about the reality these people live in, the reality of organizations I advise (Deutsche Bank, Lufthansa, Conrad Electronics, Deutsche Bahn and others) and also the reality of our own development teams. In these realities, there are projects running from 9 months to 3 years, then there will be new projects with new teams.

In these realities, teams do not only consist of experienced senior or lead developers, but include a few seniors with several intermediate and junior developers, and we do all we can to ensure that their velocity does not remain stable.

And in practice, not everything is always in place and ready, instead teams fight for their CI and dev environments, tools and frameworks. In practice, development teams constantly have to deal with new technologies and technical debts, new and sometimes inexperienced PO’s and Scrum Masters, and so on.

Velocity under such conditions is rather fragile than stable and it is a daily struggle to keep it high, but at least stable or ideally increasing slightly. It’s not a concept that you can take for granted.

If all of this were stable – and in no way in danger – most parts of the Scrum methodology would not be needed at all.

So if you think that story points are only there to get a feeling for what fits into a Scrum sprint, and you commit yourself to the same number of story points, you could save yourself the trouble. There is an easier way to do that. As a PO, you could simply ask the DevTeam before or during planning: “Do these three stories fit into the sprint or can I add another one? The answer would be just as accurate.

What are Story Points?

Now that we know what role story points play in Scrum or SAFe, it’s time to get to the definition and description.

And unfortunately, it is complex, even if it does not seem like it at first glance. But the effort will be worth it.

Story points are a way of measuring the complexity of a story. Put them in relation to the implementation effort of this story and you’ll the velocity.

That’s quite simple. But what exactly is the complexity of a story and how do I define it? That makes it a little more difficult – if not more „complex“.

If you google „complexity”, you will get a number of quite different definitions, which I don’t want to quote and discuss here for obvious reasons. Two of them appear short and meaningful for our purposes:

“The number of elements and connections between them within a system”

“The information content of data”

Technically speaking, the latter could also be defined in reverse. Data aggregates into information and does not contain it, but that is a different, rather finicky discussion.

But when teams estimate the complexity of a story, they naturally only consider the effort they need to implement it, due to the lack of other objective criteria. It is easier to determine and also kind of obvious.

Even if the procedure is not completely wrong – as I will show later – the teams will be caught in a bad situation.

Since the effort is individual, this characteristic is automatically transferred to the complexity.

And when we look back at how story points are used – that is, for velocity – the problem immediately comes to light: Time is compared to time, and that of course will lead us nowhere.

Because if velocity is a relation of complexity and effort, I cannot describe complexity with effort. Otherwise I would be putting effort in relation to effort, i.e. comparing time with time.

This would be bad.

Besides, complexity is a feature of the story. Effort, on the other hand, points to a property of the DevTeam.

But that’s not how we make progress. The situation is tricky, because we have no objective criteria for determining complexity. At any rate, none that could be derived from a story in a reasonably practical and manageable way.

The solution is a workaround about the “theory of relativity”. This may sound complicated, but it is simpler. And this is how it works:

How do we calculate Story Points?

We will use the following definition for story points:

Story points represent the complexity of a story in relation to its effort.

Therefore, story points are neither complexity (too difficult to determine), nor effort (we don’t want to compare time with time), but somewhere in between.

How do I calculate story points?

We like to use the adapted Fibonacci sequence, let’s say on a scale up to 20. The definition of ready says that all stories over 20 have to be split, so the numbers up to 20 are fine. This makes things a bit easier for us.

The first story receives 5 story points. Maybe even 8. Why? Because it doesn’t matter. The first story is just a benchmark.

Any other story in this sprint will be compared to the first story. We ask: Is this story more complex to implement or not? Yes, in this phase it’s all about effort. So the second story is much more elaborate, say 13 story points. This gives us a total of 18 story points. Good.

In a second planning phase, we determine the actual implementation effort in time by creating detailed subtasks and estimating them in hours. This is a truly technical workshop in which we create a concrete implementation plan for this sprint. Let’s say for the first story we had 2 days, for the second 5 days. Since both estimates use different scales, the ratio between the first and second story in both estimates is, of course, not linear.

So we have 2 stories with 18 story points and a total of 7 days of effort.

Strictly speaking, it is by no means important if you estimate the actual implementation time in the second part of the planning, or if you do so after the sprint per story. The latter would be even more objective. But you’ll need the estimate for a valid commitment anyway, and you won’t have to track the time spent per story during the sprint. Instead you can focus on the remaining time.

Now we will use these values to start the sprint.

In the next sprint we do the same, comparing every story with the first story of the first sprint. In the next sprint we do the same over and over again. At some point, we get to the 5th, 7th, or 10th sprint. Time has passed. Time that teams used to familiarize themselves with technology, to train juniors, to get to know each other, to have retrospectives, to make improvements in the process, etc.

Now let’s do the same thing again. We take the current story in the 5th, 7th, or 10th sprint and compare it to the first story of the first sprint. But now we ask a different question: “If we had to implement this story in the first sprint – when we were young and beautiful and inexperienced – how long would it have taken us compared to the very first story?

This is where the theory of relativity kicks in, as we have changed over time, but the complexity of the story hasn’t.

The only difference is that we need less time to implement the story today than we did back then. This will be shown in the second phase of planning in which we estimate the exact implementation time. For example, the story also has 5 story points, because back then it would have required the same effort. But today we don’t need 2 days, we only need 1.5. This means that we have become better, our velocity has increased.

The Bottom Line

My God, why all this effort? Well …

Improving teams is a basic principle of Scrum.

Because teams always start under very difficult conditions: New team, no specification, new topic, inexperienced product owner, new technology. There are so many reasons, all of them unpleasant.

The velocity at the beginning of a project is, of course, pretty low. The teams have to catch up as quickly as possible.

Stakeholders must not get nervous too quickly in this early phase and get caught up in micromanagement (a widespread management error).

In other words, becoming better must be institutionalized. And for that we need two things:

A forum, which is the very purpose of the sprint retrospective, the most underestimated of meetings. And a measure that shows us if the velocity is increasing, decreasing or constant, so that we can take appropriate measures in the retrospective and observe the effect: the velocity, generated from the story points and set in relation to the actual implementation effort.

It’s not exactly easy, but it’s the only way to determine where the team is exactly.

Of course, we only do this because there is no objective procedure with good criteria for determining complexity. With such a method, however, teams could immediately be compared to each other.

SAFe wants to do that, hence the demand for normalized story points. Scrum never really did. They both have good and plausible reasons for their position.

Anyone who has ever dealt with agile contracting will certainly understand the SAFe position. But Scrum purists won’t like it, because competition is not a good motivator.

Как мы познакомились с Agile & Scrum

Введение

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

Предыстория, с чего все началось, как пришли к тому что нужен Scrum

Я работаю руководителем IT-отдела (менеджером проектов) в одной маленькой/средней томской фирме. Численность работников в IT-отделе на начало деятельности: 5 человек, на данный момент: 24 человека.

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

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

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

Как все было до Scrum

Изначально у нас был развернут старенький Redmine без всяких плагинов и настроек, можно считать его практически чистым, TeamCity (бесплатный) для обеспечения хоть какого-то билдинга, SVN, куда же без репозитория. В Общем все работало.

Задачи ставились в redmine, по мере выполнения проставлялись часы а иногда и проценты выполнения, но зачастую не было ни сроков ни каких-то планов, очень везло, если был хотя бы обговоренный dead-line.

И тут настало мое время. Руководство дало мне добро на применение всего, что душе угодно (принесет больше прибыли). Как я уже писал выше — это лето 2014.

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

Естественно все было перенесено и в электронный вид: по некоторым задачам зафиксировано в redmine в виде feature или epic, по некоторым в старом добром Excel, также поставили важность и приблизительные сроки выполнения задач. Потом мы приступили к декомпозированию и оценке задач с каждым работником, который будет выполнять задачи. Получился набор feature с sub-tasks и оценкой сроков выполнения задач. Получился своеобразный backlog, но с ним дальше нужно как-то работать, сам по себе он не дает результатов.

Диаграммы Гантта

За некоторое время до этого я сталкивался с Диаграммами Гантта (ленточные диаграммы) в фирме, в которой работал программистом. Сделал пару диаграмм по нашим проектам, наброски показал руководству, и эта методика им понравилась. И я приступил к изучению инструментов, которые позволили бы мне в наилучшем виде сделать эти самые диаграммы.

Мной были опробованы:

В итоге, потыкавшись с некоторыми программами и время от времени их меняя, мы несколько месяцев вели проекты с активным использованием диаграмм Гантта. Руководству это все нравилось, они видели четкие и утвержденные планы, и, вроде как, все устраивало, за исключением небольшого НО (большого).

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

Вот тут то и возникла потребность в чем-то ином.

Какие потребности были

Собрав feedback от руководства и главных действующих лиц компании, был сформирован некий список того, что же хотелось увидеть:

Что рассматривал еще

Почему Scrum удовлетворяет потребности

Как донес до всех

Основные концепции разработчики и так понимали из статей, так что с ними проблем практически не возникло, все восприняли с энтузиазмом. Основной проблемой было руководство, но так как оно в процессах практически не участвует, то нам и карты в руки.

Как изучил? Что смотрел? Какие ресурсы? Какие книги?

Общение с профессионалами

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

Чтение статей

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

Чтение книг

Начало внедрения

Документ с основными мероприятиями

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

Карты

Естественно нужно было где-то достать карты для Poker-planning. пересмотрели в интернете ряд магазинов, стоимость колоды для четырех человек варьировалась от 1000 рублей до 2000 рублей. Денег просить у руководства мне особо не хотелось, и поэтому я их сделал сам. Обычная бумага А4, черно-белый принтер, ножницы, — вот что вышло:

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

Интересный факт. Надеюсь я ничего не перепутал. Один из немногих на тот момент магазин по продаже колод карт, который мне мне понравился — planningpoker.ru. Подумал тогда, какие же прикольные карты. Позже, спустя несколько лет на конференции директор фирмы, которая организовала этот магазин, подарил мне одну из таких колод совершенно случайно. (ссылка есть в источниках и ссылках)

Доска

Следующий важный этап, это подготовка Scrum-desk, взял обычные ватманы, пару А3 и А4, маркеры, скотч и др. И получилось довольно таки неплохо:

Что получилось в результате подготовки

Первый опыт, первый sprint

Backlog

Первый backlog мы строили в MS Excel, разбили все, как нужно на колонки:

Естественно, присутствует еще ряд колонок, которые не вошли на рисунок, но это другая история. Подчеркну, у нас получились именно задачи (feature), а не пользовательские желания (user-story), как это принято в Agile. Первый sprint было принято решение сделать двухнедельным. Расставили приоритеты, отсортировали, пометили зеленым, что хотелось бы взять на sprint, расставили story-points. Хм, что такое story-point?!

Как довел до сведения разработчиков. Story-point — день

На систему оценки в story-points — идеальные человеко дни, перейти достаточно сложно и непонятно для разработчиков. Как мы объясняли story-point — это идеальный восьмичасовой рабочий день разработчика, когда у него есть все под рукой, ничто не отвлекает его от работы (уже заметны проблемы, есть все и не мешает хм. ), он находится в изолированном от других помещении, где есть свежий воздух, еда, чай/кофе, туалет и он продуктивно выполняет поставленную задачу, решение которой ему полностью ясно. Некоторые вещи еще добавлялись при объяснении новичкам, но они особо не имеют значение.

Распределение ролей

В нашей компании практически нет cross-разработчиков? есть отдельные тестировщики и мы разрабатываем под различные платформы. Соответственно, мы слабо ложимся на одно из понятий Scrum, как унификация работников. Мы им пренебрегли и в первом sprint’е у нас участвовали разные разработчики в одной команде.

Планирование

Были распечатаны все features из backlog’а, которые должны были пойти в sprint, и мы начали оценку.

Какие действия на планировании sprint’a нами предпринимались:

Составили Scrum-list (в MS Word):

(ссылка есть в источниках и ссылках)

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

Ежедневные планерки

На первую планерку все явились, как по часам, что не радует (в дальнейшем было все не так радужно). Собрались, начали обсуждать поочередно у кого как что идет, вопросов и проблем ни у кого не было. Перешли к Scrum-desk.

Доска задач в бумажном виде

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

Изначально стикеры просто лепились на доску, но со временем стали их закреплять дополнительно на скотч, было пару прецедентов когда все слетало. Позже появилось еще пару столбцов типа: in testing, code review и т.п.

Зачем нужна burn-down?

Burn-down нужна для того чтобы можно было отслеживать прогресс выполнения sprint’а у команды, а также для того чтобы в визуальном виде можно было видеть отклонения от выполняемого плана по времени. Основная цель burn-down: показать команде (так как у нас самоорганизующиеся команды), что нужно принять оперативные меры, если произошло отклонение.

Как строить burn-down?

Множество инструментов позволяют строить burn-down диаграммы в электронном виде, мы воспользовались MS Excel, а также строили на ватмане.

Изначально (позже появлялись дополнительные столбцы) наша таблица содержала:

Как видно по диаграмме — первый sprint прошел практически удачно, небольшие отклонения от идеального исполнения. НО, как гласит правило: Если по окончанию sprint’a есть не сожженные story-points, то sprint провален. На это правило, на тот момент, мы закрыли глаза и радовались успешному завершению sprint’a!

Демонстрация

Пришло время продемонстрировать руководству результаты sprint’a. “Команда” (менеджер) подготовила свою презентацию, в дальнейшем каждый член команды делал свою часть. Изначально не было стандарта презентации. Собралось много зрителей: руководство, часть отдела продаж и маркетинга.

Презентацию делали в MS Powerpoint:

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

Где и как проходила демонстрация

Так как у нас, на тот момент, не было conference-room презентация проходила в кабинете разработчиков, достали проектор и светили на стену.
Изначально выступил менеджер (я) рассказал для чего все тут собрались, рассказал основные цели и задачи sprint’a, и начали выступать по очереди разработчики, завершилось все выступлением менеджера с демонстрацией burn-down диаграммы и вопросами со стороны публики.

Основные задачи менеджера на демо:

Разработчики на первой демо

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

Публика на демо

Со стороны публики было много отвлеченных вопросов, которые косвенно относились к демонстрируемому sprint’у, на которые они очень хотят получить ответ, — это очень затягивает демонстрации и по сей день. Первая демонстрация длилась часа полтора.

Ретроспектива

Первый sprint прошел удачно и для разработчиков. Отзывы были только положительные.

Какие улучшения были обсуждены на первой ретроспективе:

Feedback от руководства

Все понравилось, требуется больше слайдов в презентацие. Руководство захотело привязывать премиальную часть ЗП разработчиков к результатам демонстрации sprint’a: заинтересованные лица проставляют субъективные оценки каждому разработчику с проставлением критериев этой оценки, оценка менеджера — среднее арифметическое из всех оценок. Данная система не особо прижилась, но это уже совсем другой рассказ.

Как все пошло

После первого sprint’a уже много воды утекло, было предпринято множестве действий по оптимизации процессов, некоторые имели какой-то profit, многие нет.

Какие меры предприняли

Объединение команд, почему случилось

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

Да, — это помогло выиграть некоторое время, но, Нет, — это не дало положительных результатов. Такое продлилось четыре sprint’a, но так как у команд был совершенно разный профиль разработки, разработчикам было совершенно незачем работать вместе.

Разделение команд

Со временем работников становилось больше и становилось больше направлений разработки, появлялись то мобилки, то еще что-нибудь. Как я говорил в пункте с объединением команд, людям совсем не за чем работать вместе, если между ними нет прямой связи в разработке проектов. Соответственно, мы разделили команды по разным направлениям. Да, — это дало продуктивный результат для каждой отдельной команды, но каждая команда, сожрала уйму времени менеджера.

Варьирование времени sprint’ов

Попробовали различные вариации:

Перешли на доску с маркерами

Отказались от ватманов, некрасиво смотрится, разработчикам не нравилось это на обоях.

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

Следующий этап: стали писать ежедневные таблицы митингов маркерами на доске:

Таблица содержит: число, столбец сжигания задач не из плана, столбец сжигания задач из плана.

Перешли на облачное решение: google doc

Стали вести burn-down диаграммы в google таблицах. С течением времени стали добавляться еще значения в таблицу:

Так как при длительном sprint’e у нас появилась тенденция: не укладываться в sprint (запасы пробовали брать, ни к чему хорошему не привело), ввели новое значение — off-plan, которое показывает график с учетом сжигания не запланированных задач.

Далее пошли еще дальше, ввели еще три значения: Real, Off-plan (error) и Off-plan (extra):

Перешли в google презентации

Удобное решение, можно работать всем одновременно:

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

Попробовали плагин для Redmine

Поставили плагин для Redmine, его название — Backlog’s. Дает возможность организовывать работу с backlog’ом продукта и sprint’ами через Redmine:

У данного плагина есть электронная доска задач, которая полностью повторяет функционал той, которая у нас была вначале в реальном виде. Все столбцы подхватываются из Redmine, — это значение статуса задачи. Sprint замещает значение и функционал «версии» в Redmine. Достаточно удобный плагин, мы его используем и сейчас.

Ввели регалиеметр

Отражает суммарно сожженные story-points каждого работника за все sprint’ы. Стимулирует работников работать более продуктивно, каждый работник способен брать на sprint определенное количество story-ponts. Видя, что другие ребята работают продуктивнее него, работник предпринимает попытки, чтобы достигнуть более хороших результатов. У нас среднее количество story-points на двухнедельный sprint — это семь.

Какие улучшения дали нововведения

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

Что же происходит сейчас?

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

Дало ли результаты?

Придуманная и внедренная система дает следующие результаты:

Что планируем делать дальше

В данный момент у нас, опять, активно внедряется 1С Битрикс, руководство хочет чтобы все работники были в одной системе. Планируем изучать новый инструментарий и смотреть, как нашу работу можно перенести в CRM. На данный момент есть кое-что на примете: доска для Битрикса — scrumban.ru. (ссылка есть в источниках и ссылках)
Есть планы при помощи MS Project применять метод освоенного объема в параллели ко всей нашей системе.

Заключение

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

«Scrum. Революционный метод управления проектами». Книга за 15 минут

Недавно мы в MakeRight.ru с удовольствием прочитали книгу «Scrum. Революционный метод управления проектами» Джеффа Сазерленда. О чем она? В двух словах — о том, как организовать слаженную командную работу.
Начав внедрять элементы скрама на практике, мы пришли к выводу, что идеи книги действительно работают.

Революционный ли это метод, как указано в названии? Не знаем. Но, возможно, те, кто не читал книгу и не знаком с методикой, почерпнут для себя ряд полезных идей из нашего саммари (краткого изложения). Итак…

Что такое Scrum. Суть методики

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

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

Методика Scrum, которую разработали Джефф Сазерленд и Кен Швабер, призвана решить все эти проблемы. Scrum — это противоположность классическому поэтапному подходу, применяемому к реализации проектов. Методику Scrum взяли на вооружение многие компании как из технологических отраслей, откуда она сама родом, так и из традиционных и даже некоммерческих. Подход, лежащий в основе методики Scrum, можно применять в разных видах деятельности, в которых требуется коллективная работа.

Важными характеристиками Scrum является ее гибкость и ориентированность на клиента, так как она предполагает его (клиента) непосредственное участие в процессе работы.

Scrum не требует внедрения каких-либо дорогостоящих инструментов. Схему методики Scrum вкратце можно описать следующим образом:

Недостатки традиционного подхода к управлению проектами

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

Каскадная модель предполагает использование диаграмм Ганта — графиков, на которых обозначаются этапы работы и время на их выполнение. Ход проекта детально размечается и отражается каждый шаг работы. Предполагается, что каждая фаза проекта последовательно переходит в другую, — это и есть принцип каскада.

Изображение с сайта www.quickiwiki.com

«С распространением в 1980-е годы персональных компьютеров стало проще создавать разные затейливые диаграммы — и делать их по-настоящему комплексными — они превращались в подлинные художественные произведения. Весь ход проекта детально размечен. Каждый отдельный шаг. Любая стадия. Всякая дата поставки. Действительно, диаграммы Ганта производят глубокое впечатление. Существует лишь единственная проблема: они всегда неправильны — без исключения».

Почему? Как отмечает Джефф Сазерленд, Генри Гант придумал такие диаграммы еще в 1910 году. Они получили широкое распространение в Первой мировой войне. Однако, «каждый, кто изучал историю этой войны, знает, что ни подготовка кадровых ресурсов, ни система организации никогда не были ее сильными сторонами. Мне не дано понять, почему концепт времен Первой мировой войны становится-де-факто аналитическим инструментом проектирования и применяется даже в XXI веке. Мы отказались от принципов позиционной войны, но каким-то образом ее „окопные“ организационные идеи остаются популярными и по сей день».

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

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

Планы рассыпаются в прах. Альтернатива — это Scrum

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

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

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

Изображение с сайта brendanmarsh.com

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

«Каждый спринт планируется предварительно на специальных встречах. Участники оценивают, какой объем работ, на их взгляд, они смогут сделать, скажем, в течение следующих двух недель. Из списка задач, расставленных по приоритетам, они выбирают очередные единицы работы, предназначенные для выполнения, записывают их на стикеры, которые приклеивают на стену. Группа решает, сколько единиц работы они в состоянии выполнить за предстоящий спринт.
На завершающей стадии спринта участники снова собираются вместе и показывают друг другу, чего удалось достичь за время совместной работы. Они смотрят, сколько единиц работы, занесенных на стикеры, действительно доведены до конца. Не все удается выполнить? Значит, для этого спринта было отобрано слишком много задач. Бывает наоборот — недостаточное количество задач. В данном случае важно другое: у группы развивается чувство собственной скорости».

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

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

Как отмечает Джефф Сазерленд, благодаря использованию Scrum, группы учатся добиваться «сверхэффективности», поднимая свою производительность на триста или четыреста процентов.

Философия scrum

В методике Scrum нашло свое отражение увлечение автором книги японскими боевыми искусствами. По его словам, в Японии к «Scrum не относятся как к сиюминутной причуде. Японцы расценивают Scrum как подход к решению вопросов, как образ действий, как способ существования бытия — в общем, как образ жизни. Когда я обучаю людей этой методике, я часто рассказываю о своем многолетнем опыте занятий японским боевым искусством айкидо».

Общее у айкидо и Scrum то, что ими можно овладеть лишь в процессе работы, когда «ваше тело, ваш разум и ваш дух соединяются в единое целое через постоянную практику и стремление к совершенству. Занимаясь айкидо, мы постигаем понятие сюхари (Shu Ha Ri) — это одновременно и концепция боевых искусств, и показатель уровня мастерства».

Суть командной работы в Scrum

Scrum — это, прежде всего, командная работа. Автор выделяет три характеристики лучших коллективов:

Какого размера должна быть команда? Джефф Сазерленд рекомендует малочисленные группы — около семи человек. Он приводит данные, что если группа состоит из более чем девяти человек, то скорость ее работы падает.

Кроме того автор напоминает о «законе Брукса»:

«Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше».

Главный в команде — это скрам-мастер. Его обязанность — обеспечивать короткие собрания, их открытость, помогать группе идти сквозь помехи, которые мешают работе, вести команду по пути постоянного совершенствования «и регулярно искать ответ на вопрос «Как нам делать еще лучше то, что мы уже делаем хорошо?».

Нет мультизадачности

Автор предостерегает от мультизадачности — на самом деле ее нет, наш мозг не может выполнять два действия одновременно, он просто переключается между задачами, а общее время выполнения каждой из них увеличивается по сравнению с тем, если бы мы выполняли их поочередно. Методика Scrum предполагает, что нужно поочередно выполнять все задачи, а не «сбалансированно вести пять проектов одновременно».

«Действуя традиционным методом, то есть пытаясь делать все и сразу, группа завершит свои три проекта до конца июля. Если группа подойдет к делу, вооружась гибкой стратегией, например, Scrum, и будет работать поочередно над каждым проектом, минимизируя затраты времени и сил на переключение контекста, она сможет закончить все к началу мая».

Никаких переработок

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

«Этот феномен окрестили „истощение эго“. Идея заключается в том, что принятие любого решения требует от вас энергетических затрат. Это странный вид истощения — вы не чувствуете физического утомления, но ваша способность принимать взвешенные решения снижается. Что на самом деле меняется, так это наш самоконтроль — наша способность быть дисциплинированными, вдумчивыми и просчитывать последствия».

Вывод: в нерабочее время отдыхайте, полностью отдалитесь от работы, заряжайтесь приятными впечатлениями.

«Методология Scrum подразумевает, что те, кто применяет ее, перестают измерять свою работу только часами. Часы отражают лишь затраты. Измеряйте лучше результат. Кого волнует, сколько кто-то потратил времени на то, чтобы что-то сделать? Единственное, что имеет значение, — как быстро и качественно это было сделано».

Суть работы — поток

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

Как его достичь? За состоянием потока стоит внутренняя дисциплина.

«Не должно быть ни одного движения впустую».

Скрам и счастье

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

В конце каждого спринта участники устраивают ретроспективное собрание, на котором рассказывают о своих работах и перемещают рассмотренные задачи в колонку «Сделано», а потом обсуждают, что хорошо, а что можно улучшить. Они находят основную помеху и думают, как ее устранить в следующем спринте. Это и есть решение проблемы непрерывного совершенствования.

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

Элементы скрам

Спринты

Как уже отмечалось выше, в начале спринта и для обеспечения открытости и наглядности, нужно завести специальную доску и поделить ее на три колонки: «Бэклог»; «В работе»; «Сделано». Перед каждым спринтом члены команды наклеивают в колонку «Бэклог» стикеры с задачами, которые, по их мнению, они могут выполнить за спринт. В течение спринта, любой член команды, взявшись за задачу, переклеивает стикер из раздела «Бэклог» в колонку «В работе». После выполнения задачи — в колонку «Сделано». Таким образом, каждый видит, над чем сейчас работают другие участники.

Изображение с сайта nyaski.ru

Однако есть важное замечание — «ничто не переносится в колонку „Сделано“ до тех пор, пока эта часть проекта не будет опробована клиентом».

«Еще один важнейший аспект спринта: как только команда утверждает список требований, задачи из этого списка „блокируются“. Никто не имеет права их менять или вносить добавления».

Автор рекомендует это из-за того, что любое вмешательство замедлит работу команды.

Ежедневные собрания

Суть в том, чтобы они проводились стоя, каждый день, в одно и то же время, их длительность не превышала пятнадцать минут и на них участники задавали одни и те же три вопроса: «Что ты делал вчера, чтобы помочь команде завершить спринт?», «Что ты будешь делать сегодня, чтобы помочь команде завершить спринт?», «Какие препятствия встают на пути команды?».

Делайте до конца

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

«Израсходованы ресурсы, силы, время, деньги, но полностью функционирующий продукт не получен».

Планирование в Scrum

Как происходит процесс планирования в Scrum? Для начала нужно составить список всех вещей, которые влияют на вашу цель. После этого расставить их по приоритетности. В случае если вы не будете укладываться во временные и финансовые рамки, тогда вы легче сможете исключить последние пункты списка.

Что делать потом? Каждый пункт списка нужно оценить на предмет того, сколько на его выполнение уйдет сил, времени и других ресурсов. Каким образом производить оценку? Автор предлагает шкалу относительных оценок. Например, можно сравнивать задачи «в собаках». Эта проблема — такса или ретривер? А может быть, дог?

Но в любом случае удобнее установить числовые значения. Например, «Такса — единица; дог — тринадцать; лабрадор стал пятеркой, а бульдог — тройкой».

Автор также предлагает использовать интересную методику покер планирования. Ее суть — каждому участнику процесса планирования дается колода карт с числами Фибоначчи — 1, 3, 5, 8, 13 и так далее. Каждый пункт списка, единица работы, которая должна быть оценена, выкладывается на стол. «Затем каждый участник группы берет ту карту, число на которой, по его мнению, соответствует объему необходимых усилий, и кладет ее на стол рубашкой вверх. Затем все одновременно открывают карты. Если расхождение не больше чем на две карты (скажем, пятерка, две восьмерки и тринадцать), команда просто их складывает, берет среднее арифметическое (в данном случае 6,6) и переходит к следующей задаче. Помните, мы говорим об оценках, а не о жестких планах. И оценках небольших фрагментов проекта. Если расхождение получается более чем на три карты, тогда те, кто положил карты с самым большим и самым маленьким значением, объясняют, почему они так считают. Затем проводится еще один раунд покера планирования. В противном случае они лишь усреднят оценки, что сделает результаты слишком приблизительными».

Требования — это истории

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

«Представьте, что вы составляете „пожелание пользователя Amazon.com“. Пробный вариант выглядит так: „Мне как потребителю нужен крупнейший в мире магазин книг, где я могу купить любую книгу в любое время“.

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

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

Как планировать спринт

В Scrum процесс планирования происходит в начале каждого нового спринта и так и называется — «планирование спринта».

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

После этого команда дружно произносит: «Вперед!» — и принимается за работу

Но что такое работа? Рутина, обязаловка? С точки зрения скрам, работа — это история. Что это значит? Это означает, что вам следует представить человека, которому нужно то, что вы делаете; потом то, что это такое, и, наконец, зачем людям это нужно.

Командам нужно хорошо узнать свою динамику — сколько работы она может выполнить за один спринт. Это поможет ей работать разумнее и устранять все помехи на своем пути.

«Динамика x время = результат. Узнав, насколько быстро вы продвигаетесь, вы сможете понять, когда окажетесь на финише».

Открытость во всем

Скрам предполагает прозрачность всех действий и процессов.

Это выражается в доске с тремя колонками, к которой имеют доступ все участники команды.

Расстановка приоритетов

Эту диаграмму нужно иметь в виду каждому предпринимателю. Суть работы заключается в поиске золотой середины — сбалансированной концепции между тремя крайностями:

Бэклог

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

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

Как правильно расставить приоритеты?

«Для этого нужно выяснить, какие пункты списка:

Владелец продукта

В скраме предполагается три роли: скрам-команда — исполнители конкретных проектов; скрам-мастер — это тот, кто следит за ходом проекта и помогает команде решать проблемы, и владелец продукта — тот, кто решает вопросы концепции продукта и составляет бэклог.

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

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

Минимизация рисков в скраме

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

«Методология Scrum полезна бизнесу тем, что быстро отвечает на вопрос: сможем ли мы заработать деньги, если сделаем то или иное?»

Вам не нужно тратить огромные средства перед тем, как понять, что-то не работает.

Как внедрить Scrum прямо сейчас

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

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

О нас

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

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

Гибкая методология Scrum

Scrum представляет собой гибкую методологию управления проектами. Придумали её ещё во второй половине восьмидесятых, но настоящую популярность Scrum обрела в конце двухтысячных. Чем гибкие методики отличаются от остальных, и работает ли это?

Гибкие методологии

Начать стоит с самого происхождения Agile-методологий. Начало им положил «Манифест гибкой методологии разработки программного обеспечения» в 2001-м году. Agile — в переводе с английского «гибкий». Вот основные принципы Манифеста:

В основе таких методологий лежит итеративный подход: когда разработка ведётся циклами (итерациями). После каждого цикла определяются планы по изменению продукта на следующий.

Различные гибкие методики существовали и до выпуска Манифеста. Как следует из его названия, применялись они в разработке ПО, и долгое время никто не пробовал использовать их в других сферах. Некоторые из гибких методологий, которые использовались до 2001-го года:

Srum тоже был разработан во второй половине 80-х годов прошлого века.

История Scrum

Впервые слово «Скрам» не в контексте регби (там этот термин обозначает позицию игроков, борющихся за мяч в плотном скоплении), а в контексте разработки использовали Хиротака Такеучи и Нонака Икуджир в статье в 1986-м году. Там учёные описывали новый гибкий геймификационный подход к разработке коммерческого продукта, позволяющий выполнять работу в быстрые сроки. Команда разработчиков сравнивалась с командой в регби: действует во время «Скрама», как единый организм, для достижения общей цели.

Статью заметил Джефф Сазерленд, бывший военный лётчик США, занимающийся поиском новых подходов к разработке ПО. В это же время Кен Швабер, тоже разработчик, также искал новые подходы для оптимизации своей деятельности. В 1995-м году Сазерленд и Швабер объединяются и создают документ, отражающий основы методологии Scrum. В 2001-м они участвуют в создании Манифеста Agile.

В этом же году создаётся Scrum Alliance. Его миссия: направлять лидеров, компании и людей в целом на создание правильной организации рабочего процесса — «Transform the World of Work». Альянс существует и сегодня и занимается внедрением методологии Scrum.

На чём базируется Scrum

Основные принципы организации рабочего процесса в Scrum во многом являются эталоном и совпадают с другими Agile-методологиями.

Доска и Диаграмма сгорания задач

Отдельно стоит поговорить о методах визуализации работы, используемых в Scrum и некоторых других Agile-методиках. Две главных из них: Burndown Chart и Desk.

Burndown Chart — Диаграмма сгорания задач. Такая диаграмма отображает процесс работы над проектом. По ней легко отследить, насколько команда приблизилась к выполнению задачи. По горизонтали откладывается время: остаток дней до конца стрима. По вертикали — количество подзадач, человеко-часов или Story Points — единиц измерения работы. График Диаграммы сгорания стремится вниз, от первого дня к последнему, от максимального количества подзадач/человеко-часов к их отсутствию. Отдельным цветом изображается идеальный график — прямая: когда за каждый день выполняется одинаковый объём работы, что в итоге приводит к равномерной нагрузке и выполнению цели в срок. Плохим результатом на Диаграмме сгорания будет не только возвышение реального графика над идеальным. Если команда выполнила весь объём работ на несколько дней раньше, значит неправильно был определён размер итерации либо поставлена слишком маленькая или простая задача.

Другой, более простой инструмент: Desk. Диаграмма сгорания визуализирует эффективность команды, а Доска помогает работникам ориентироваться в текущих заданиях. Это таблица, состоящая из трёх или более столбцов: запланировано, выполняется, готово. В некоторых случаях добавляется столбец Stories, где могут отображаться истории пользователей — не только на текущий спринт, но и на следующие. По этим колонкам расклеиваются стикеры, на которых кратко изложена суть подзадачи: нарисовать эскиз, протестировать код, добавить кнопку на сайт. Стикеры постепенно переходят из «запланировано» в «выполняется», а из «выполняется» в «выполнено». Таким образом становится моментально ясно, что уже сделано, а что ещё в процессе, о каких делах сотрудники забывают.

Два этих способа визуализации обязательны в Scrum. Burndown chart и Desk — статистика и мотивация для команды. Однако применять такие инструменты можно и без перехода к гибким методикам: они отлично покажут эффективность любого рабочего коллектива.

Ещё один популярный инструмент: метрика Velocity. На диаграмме за несколько спринтов сравниваются столбцы запланированных подзадач/Story points за стрим со столбцами выполненных. На основе этого определяется эффективность. Метод весьма спорный, так как слишком обобщает результаты, но может использоваться дополнительно.

Где применяется Scrum

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

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

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

Scrum и крупные компании

Герман Греф активно вводит Scrum в IT-сфере «Сбербанка». Там методология используется для поддержки «Сбербанк Онлайн» с 2013-го года. По гибкой методике это же приложение и создавалось. Несколько команд занимаются разработкой других различных проектов, таких как «Советы».

Легко ли внедрять Scrum в большие компании? Гибкая методология требует полного изменения рабочего процесса, а далеко не все сотрудники будут к такому готовы. Как правило, легче всего вводить «Скрам» постепенно, набирая работников, которые заинтересованы в проекте, желают изменить привычный график. Точно не стоит сразу переводить на новый режим работы всю компанию целиком.

Мелкие компании, стратапы подходят для Scrum больше всего. Ведь чем «моложе» организация и чем меньше число сотрудников, тем легче ввести Agile-методологию и соблюдать её основные принципы.

Оценка Scrum

Scrum существует уже достаточно долго и за это время приобрела много сторонников и немало противников.

Преимущества

Недостатки

Дэйв Томас, один из авторов Манифеста, считает, что Agile-методологии так и не получили воплощения. Вместо этого были придуманы наборы жёстких правил (как в Scrum), а слово «Agile» превратилось в бессмысленный маркетинговый термин.

Западные специалисты замечают, что из-за распространения как Scrum, так и Agile появилось большое количество шарлатанов. Они не обладают компетенцией, не могут дать чётких ответов на вопросы по поводу применения методологии, но при этом предлагают недешёвые услуги по внедрению Scrum в компанию.

Обучение Scrum

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

1. «Scrum. Революционный метод управления проектами» Джеффа Сазерленда.

Книгу написал один из создателей методики, поэтому искажения или неверной интерпретации «Скрама» здесь точно не будет.

2. «Софт за 30 дней» Джеффа Сазерленда.

Эта книга также написана Джеффом Сазерлендом совместно с Кеном Швабером — другим создателем Scrum. В книге описывается процесс быстрой разработки программного обеспечения на основе методики, а дополнение Scrum Guide описывает все роли, артефакты, процессы.

3. «Scrum и XP: заметки с передовой», Хенрик Книберг.

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

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

Программы для управления проектами

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

Все что нужно знать про Scrum

Что такое Scrum методология? Как ее применять в разработке и не только? Почему гибкость не всегда хороша?

Учеба продолжается, три раза в неделю я знакомлюсь с новыми знаниями из области разработки и понимания digital продуктов изнутри. Для маркетолога, это новый мир. Ты слышишь про какой-то там Agile, понимаешь, что связано это с разработкой и вполне можешь поддержать беседу в общих красках. Но как только дело доходит до деталей, “поплыл”.

Методология Scrum является самой популярной среди всего гибкого в разработке и не только. Мне стало интересно разобраться, что это такое и в чем практическое применение этого инструмента. Представляю обзор на ваш суд.

Что такое Scrum

Scrum – гибкая методология разработки или гибкий управленческий фреймворк (т.е. структура) с акцентом на качество процессов.

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

Как работает Scrum

Как Scrum устроен на самом деле смотрите ниже.

Пока это выглядит как китайская грамота, поэтому предлагаю посмотреть на отдельные части и разобрать каждый элемент структуры. Очень рекомендую книгу Бориса Вольфсана “Гибкие методологии” именно она легла в основу данного материала (часть картинок оттуда).

Структура Scrum

Давайте посмотрим из каких элементов состоит Scrum.

Скрам митинг – ежедневная планерка, летучка, где разбирается ход работы спринта. Что сделали, есть ли проблемы, что планируется сделать. Не более 15 минут на собрание. Все участники команды должны высказаться. Скрам-мастер следит за таймингом и выступлением каждого.

Артефакты

Процессы

Простите, что прерываю чтение. Присоединяйтесь к моему telegram канал. Свежие анонсы статей, развитие digital продуктов и growth hack, там все. Жду вас! Продолжаем…

Пример Scrum

Представьте себе, что вам необходимо создать сайт/сервис по уборке на своих дачных участках. У вас есть загородный дом, где на участке творится полный швах, а тратить свои выходные на уборку, не представляется возможности, ведь хочется и отдохнуть немного. Поэтому, вуаля, сервис Уберимойдвор!

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

Выбираем, для примера, важную задачу или историю пользователя (user story) в рамках создания сайта: “Регистрация клиента/пользователя”. И раскладываем ее на более мелкие части. Формируем беклог продукта.

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

На практике, историй пользователя (типа “Регистрация пользователя”) гораздо больше. Сервис/продукт может включать множество таких историй, поэтому приоритезация строится сверху вниз, слева направо. В верхней левой части располагаются самые важные user story (Активность) и самые важные задачи.

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

Понятно, что управлять такой “махиной” в реальном времени просто невозможно, поэтому для удобства работы, вся эта стена переезжает в специальный софт/программу (Jira, Trello, Redmine и прочие трекеры управления проектами). Там вы можете назначать ответственных за задачи и исполнителей, изменять статусы задач и прочее.

Стена работает тоже хорошо, так как на этапе создания вся команда увлечена и чувствует свой вклад в общее дело. Но после ее нужно перенести в подходящий инструмент.

Вернемся к уборке двора. Вот мы выбрали спринты с задачами и преступили к работе. Команда каждый день выполняет объем работ, а скрам-мастер организует 15 минутные планерки (скрам митинги), где обновляет статус задач спринта и выясняет трудности в работе, если они возникли.

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

После 2-х недельного спринта скрам-мастер и команда проводит демонстрацию функционала. В нашем примере, мы успели сделать форму регистрации и показываем ее владельцу продукта. Он смотрит и вносит корректировки, если требуется. После принятия работы переходим к следующему спринту.

Ретроспектива: анализ спринта

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

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

Как расставлять приоритеты

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

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

В тоже время необходимо учесть возможности команды. Сколько задач она способна решить за спринт? Какого рода эти задачи? Как планировать общий ход выполнения? Поможет оценка внутри беклога.

Оценка историй пользователей внутри беклога

Мы сформировали беклог, но как оценить истории пользователя с точки зрения сложности? Для этого используется метод эталона. Это относительная оценка, которая позволяет понять потенциал команды и приблизительно оценить ресурсы.

Мы берем одну user story из беклога за образец и присваиваем ей ценность единицу (story point). Дальше оцениваем другие истории пользователя с точки зрения выбранной.

Например, в нашем сервисе есть история пользователя “Регистрация пользователя”. Мы берем ее за образец и даем ценность в один бал или один story point (так его называют в гибких методологиях). Каждый участник команды пишет свою оценку к остальным историям пользователя в списке с учетом задачи, которую взяли за образец и отдает ее скрам-мастеру.

В примере выше “Фото галерея с довольными клиентами” стоит 0,5 story point, то есть по сложности она в 2 раза меньше нашей эталонной истории “Регистрация пользователя”. Все оценки участники команды ставят анонимно, можно на стикерах писать и переворачивать.

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

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

Далее с учетом приоритетов задачи набираются в спринты и начинается работа. По итогам завершенных спринтов становится понятно, сколько story point-ов приблизительно может выполнить команда. А в процессе разбора (ретроспективы) после могут найтись точки роста.

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

Можно ли применять Scrum не только в разработке

И да и нет. До того, как я начал понимать, что означают эти 5 букв (Scrum), часть принципов уже использовал в работе. Планирование, с помощью различных инструментов и выстраивание своего так называемого “спринта задач” уже было.

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

Задачи должны быть типовыми. Как ни крути, разработка, это инженерная практика, то есть задача может быть приведена к некоему стандарту. И сделать это гораздо проще, чем, скажем, в области креатива, маркетинга или управления.

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

Когда применять Scrum

В основном в небольших проектах и старт-апах. Можно и в больших, типа Mail.ru, но там должна быть определенная свобода действий и отдельные функциональные команды со своим владельцем продукта. Не забывайте, что Scrum про гибкость и изменения. Команды не должны быть больше 7±2 человек, иначе невозможно будет эффективно организовать коммуникации.

Нюансы

Если вы решили внедрить Scrum у себя в проектах, то учитываете следующие нюансы:

Завершим

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

• ← Story plotter на пк
• Story progression nraas →