Разбираемся в Scrum и Kanban
Аспирант Нетологии Максим Пименов продолжает рассказ про гибкие методологии создания ПО. На этот раз Максим разбирает Kanban и Scrum — два подхода к работе над проектом, основанных на Agile.
Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile, о которых я писал в предыдущей статье.
Чистый Scrum — более директивная методология — больше предписаний. Kanban — демократичнее, поэтому его проще внедрить.
Обе технологии близки, потому их инструменты можно комбинировать.
Команды в Kanban и Scrum
Основа обеих методологий — Agile, поэтому и в Scrum, и в Kanban работают небольшие автономные команды из 5—9 человек. В командах нет формального руководителя, и никто извне не диктует, как организовывать работу над продуктом.
Поскольку команда автономная и самоорганизующаяся, за успех или неудачу она отвечает как единое целое. Провал не свалить на ленивого разработчика или невнимательного тестировщика.
Обе методологии подразумевают, что команда располагается в едином пространстве. Лучше, если это не кубиклы, а общая комната. Главный принцип — свободное общение между специалистами и общие обсуждения.
А вот дальше в Kanban и Scrum начинаются различия.
Kanban. Над задачей может работать несколько узкопрофильных команд. К примеру, сначала работают аналитики, потом дизайнеры рисуют прототип, а на третьем этапе включаются разработчики.
При этом универсальные команды не запрещены.
В Kanban внутри команды нет ролей.
Scrum. Над проектом работает одна универсальная команда. В ней столько разноплановых специалистов, сколько нужно для решения любой задачи проекта.
Поскольку команда самоорганизуется, у специалистов scrum-команды нет формальной компетенции. Когда необходимо, тестировщик помогает дизайнеру, а аналитик — разработчику.
В scrum-команде помимо собственно специалистов есть две роли.
Scrum-мастер — человек, который организует работу. Это не управленческая должность, и он не раздает указания. Его задачи:
В свободное от этих задач время скрам-мастер работает так же, как другие члены команды.
Владелец продукта — product owner — определяет ход проекта, он может представлять внешнего заказчика. Владелец знает все о рынке и целевой аудитории. Он ставит приоритеты задачам. Результат работы команда представляет владельцу продукта.
Как составляют список задач
Для начала команда берет проект и делит его на десятки, а то и сотни задач поменьше. Это часть философии Agile, поэтому так делают и в Kanban, и в Scrum.
Все задачи проекта, которые предстоит выполнить, складывают в общий список — бэклог. Бэклог — это банк задач проекта. Каждая задача должна быть актуальна. Если потребуется, их можно добавлять в бэклог или удалять из него «на лету».
Каждая задача имеет вес — обычно это время, которое нужно на решение. Команда сама оценивает вес всех задач, поэтому если проект не закончен в срок, виновата команда.
Также у каждой задачи есть приоритет. В Kanban приоритеты расставляет команда, в Scrum — владелец продукта. Приоритеты можно и даже нужно пересматривать по ходу проекта — это один из столпов гибких методологий.
Как работают над проектом
Когда начинается работа, Scrum становится понятно, почему его называют намного более директивной методологией.
Scrum-команда разбивает время работы над проектом на равные отрезки — спринты. Спринт может длиться и день, и месяц, а в последние годы стандартом стал спринт в 2 недели.
Поскольку все спринты одинаковы по длительности, в работе команды появляется ритм. Ритм — важный аспект методологии.
Спринт состоит из четырех последовательных этапов.
В Scrum категорически нельзя добавлять задачи в текущий спринт, поэтому Scrum менее гибок. Даже если появилась срочная и важная задача, она пойдет в работу только со следующего спринта.
В конце спринта недоделанные задачи уходят обратно в бэклог. Нужно ли их доделывать и когда, определяют на этапе планирования следующего спринта.
По сравнению со Scrum-директивами Kanban — это оплот либерализма и хаос.
Спринтов как таковых нет. Проект обычно делят на итерации, но они могут быть любой длины. Ритмичность Kanban не предписывает.
Вспомним этапы scrum-спринта:
В Kanban один этапы не завязаны на другие. Наступают они, когда решит команда. К примеру, релиз — по вторникам, планирование — когда закончились задачи, ретроспективы — каждый последний четверг месяца, а на фоне всего этого непрерывно идет разработка.
Поскольку выраженных спринтов нет, появляются особенности:
Что за доски используют Scrum и Kanban
Доска — это сердце kanban- и scrum-разработки, единственный визуальный атрибут методологий. Доски первым делом вешают на стену, когда хотят показать, что работают по Kanban или Scrum.
Доску используют, чтобы сделать проект прозрачнее, распланировать задачи и поставить ограничения.
Доску расчерчивают на столбцы. Каждый столбец — это состояние задачи («Разработка», «Тестирование», «Релиз»). Количество столбцов зависит от проекта, но чем их меньше, тем лучше.
Карточки — это задачи. На каждой описание, вес и приоритет. Когда задача проходит очередной этап, ее переклеивают в соответствующий столбец. При простом взгляде на доску понятно, как дела с проектом в целом и с каждой задачей.
Доски бывают физические и электронные.
Физическая доска. Часто доска — это действительно доска с клетками из малярного скотча. Задачи — липкие листочки, которые удобно двигать по доске.
Настоящая доска стоит в комнате и каждый в команде видит, как идут дела. Вокруг настоящей доски хорошо собираться во время совещаний.
Электронная доска. Электронная доска под рукой на пляже, на даче, в машине и в метро. Если у вас есть сотрудники, которые работают удаленно, электронная доска — единственный выход.
Я люблю настоящие доски, но без электронных иногда не обойтись.
Baking Boards или секретный ингредиент идеальной Agile кухни
Привет, Хабр! Сегодня мы расскажем о том, как разные команды в JetBrains “готовят” Agile и работают с Agile досками.
За продуктами JetBrains стоит множество команд: продуктовые, команды маркетинга, технической документации, дизайна и многие другие. Каждая команда придерживается собственного процесса, в зависимости от целей, ресурсов и особенности самой команды. На примере нашей компании и продукта YouTrack, мы расскажем о том, насколько гибкие бывают процессы, как найти подходящий для своей команды, и как настроить свою Agile доску.
Как “готовит” Scrum Команда YouTrack
Начнем с описания целей, которые ставит перед собой команда, внедряя тот или иной процесс. В нашем случае, цели можно сформулировать так:
Колонки на доске разбиты по состоянию задач: open, in progress/to be discussed и fixed. Если задача находится в прогрессе более чем три дня, мы разбиваем ее на подзадачи. Мы ввели это правило, чтобы разработчик не “зависал” на задаче и двигался дальше. Ежедневно мы получаем запросы в тех. поддержку. Чтобы мониторить прогресс по тем, которые требуют внимания разработчиков, на доске есть отдельный swimlane для запросов от пользователей.
Планирование задач мы ведем в бэклоге. В YouTrack бэклог — это сохраненный поиск, который можно открыть прямо на доске и приоритизировать задачи вручную. Благодаря тому, что вся команда активно вовлечена в процесс и следит за состоянием задач на доске, нам удается их правильно приоритезировать, оперативно решать проблемы пользователей, чинить важные баги и разрабатывать новую функциональность. Переход на цикл постоянных релизов позволил нам получать фидбэк от внутренних и внешних пользователей на самом раннем этапе (в рамках экспериментальной функциональности) и вносить нужные изменения на этапе разработки, а не после релиза.
Как команда дизайна создает материалы для 23 продуктов
Речь идет о команде дизайна, которая обеспечивает визуальное представление всех наших продуктов на рынке, начиная с сайта, маркетинговых материалов, и заканчивая печатными материалами. UI/UX дизайнеры входят в продуктовые команды и являются частью их процессов.
В основном дизайнеры получают задания от коллег (PMM) из продуктовых команд, которым нужен дизайн чего-то, желательно вчера. При таком процессе важно отслеживать поступление новых задач и равномерно распределять их внутри команды.
Каждый дизайнер работает в рамках своего свимлэйна, а руководитель, окинув взглядом доску, оценивает загруженность каждого сотрудника и равномерно распределяет задачи. Благодаря такому процессу задачи не задерживаются в состоянии open и завершаются в срок, а каждый заказчик может легко отследить место своей задачи в очереди дизайнера.
Как работают продуктовые менеджеры по маркетингу YouTrack и Hub
Маркетологи в JetBrains взаимодействуют с множеством коллег из разных команд. Чтобы следить за исполнением своих задач, необходимо держать около 20 проектов на доске: маркетинг, дизайн, локализация, веб, аналитика, интернет-маркетинг и так далее.
Когда коллеги из других проектов начинают работать над нашей задачей, они меняют ее состояние, задача перемещается по доске и мы следим за ее прогрессом. Если необходима обратная связь или задача выполнена и ждет проверки с нашей стороны, ее переводят в состояние in review. Таким образом работа над задачами становится более продуктивной и мы лишний раз не “дергаем” коллег. Для нас же ключевым моментом является визуализация наших активностей: в каждый момент времени наглядно видно, что сделано, а что осталось для завершения каждой активности. Например, глядя на свимлейн с рекламной кампанией, я сразу могу сказать, что нам не хватает только баннеров для запуска.
Как готовят Kanban Команды CLion и AppCode
Эти команды придерживаются методологии Kanban. Их процессы очень похожи между собой, потому что во многом их задачи пересекаются и работают над ними одни и те же сотрудники.
Чтобы автоматизировать процесс, команды используют набор custom workflow. Например, если разработчик перетащил задачу из бэклога на доску, он автоматически назначается исполнителем задачи. Если задача переходит в колонку QA, то она автоматически назначается на QA-инженера.
Персональная доска продуктового менеджера по маркетингу IntelliJ IDEA
Задачи на доске объединены в свимлейны по проектам. Колонок на доске нет, точнее все состояния задачи объединены в одну колонку. Настроить доску таким образом можно, выбрав шаблон “Персональная доска”.
Андрей также использует расширение для Chrome “YouTrack Tweaks”, которое позволяет добавлять на карточку поля и раскрашивать их в разные цвета. Расширение также позволяет использовать доску в режиме Darcula. Карточки не перемещаются по доске, а просто присутствуют на ней до тех пор, пока задача не выполнена. Выполненные задачи просто пропадают с доски. Такой процесс позволяет сконцентрировать на открытых задачах и отслеживать прогресс по своим задачам в разных проектах.
Итак, каких же правил нужно придерживаться, чтобы наладить процесс в своей команде? Что общего между всеми этими примерами?
Если тема вас заинтересовала, то вы можете прочитать всю серию статей или посмотреть видео с подробной инструкцией по настройке досок в нашем блоге.
Ваша команда YouTrack JetBrains
The Drive to Develop
Как мы познакомились с 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 применять метод освоенного объема в параллели ко всей нашей системе.
Заключение
В заключении хочу повториться, что это не в коем случае не гайд, а лишь опыт одной небольшой фирмы. Надеюсь что после прочтения статьи у вас останутся лишь позитивные мысли и вы вынесете для себя нечто полезное, а может быть и опыт, как делать нельзя.