Как мы познакомились с 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, но с ним дальше нужно как-то работать, сам по себе он не дает результатов.

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

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

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

• Множество десктопных программ, к примеру: гант-планинг и многое другое, которые можно с легкостью найти в интернете, часть из них были отвратительного качества, часть платные. Единственная, которую я могу отметить — Gant Project. Она достаточно удобная, позволяет с легкостью и быстро построить нужные диаграммы. Минусы: из за того что у меня была бесплатная версию, не позволяла выгрузить в нужном формате и отсутствие возможности командной работы над одним проектом.
• 1С Битрикс CRM. На тот момент у нас активно внедряли данную программу на предприятии. Она позволяла строить диаграммы с некоторой ограниченностью по функционалу. Минусы: перегруженность по интерфейсу, отсутствие возможности изменять цвета на диаграмме (мне это очень не нравилось), опять же, на тот момент отсутствовала возможность выгрузки в нужном формате (сейчас она вроде есть). Большой плюс — возможность командной работы, но нам в отделе it работа в этой программе не особо понравилась.
• Redmine. Тут все просто — ставишь задачи со сроками, и диаграммы сами по себе появляются. Минусы: если ты строишь гипотетические планы с привлечением многих разработчиков и хочешь увидеть по планам, что да как, то разработчики это все видят и у них все это начинает захламлять рабочее пространство и опять же, нет возможности делать красивые цвета.
• MS Project. Его я на тот момент по какой-то причине упустил, позже я его активно использовал и мне все понравилось, кроме трудности настраивания командной работы.
• Мегаплан. Старая CRM-система компании. Сразу отмел, было все не удобно.
• MS Excel. Старый добрый, для некоторых планов до сих пор иногда использую.

Вот так выглядели планы:

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

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

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

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

1. Прозрачность разработки. Каждый отдел (в частности руководители) должен был видеть, что же в разработке на данный момент и когда будет следующий результат.
2. Внесение изменений в разработку в любой момент. Директор хотел влиять на ход разработки оперативно.
3. Отчетность о результатах. Руководство хотело видеть мероприятия по отчетности.
4. Пул задач со временем выполнения и приоритетностью

Также был собран feedback от разработчиков:

1. Более подробная оценка срока выполнения задач.
2. Минимизация последствий вмешательства в разработку извне.
3. Повышение осведомленности разработчиков о поступающих задачах заблаговременно.
4. Предоставление полной картины на выполняемые проекты.

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

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

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

1. Гибкость. Практически в любой момент можно пересмотреть приоритеты и внедрить новые features.
2. Прозрачность. Sprint-list у каждого на почте (у главных действующих лиц) и изначально я его вешал в каждом кабинете. Также можно зайти в кабинет со Scrum-desk и посмотреть кто чем занимается в данный момент.
3. Отчетность. Демонстрации по окончанию sprint'a, достаточно хорошая процедура, которая дает понять (в какой-то мере) что же вышло в результате.
4. Подробная картина проекта (зависит от степени декомпозиции backlog’а). Постоянно обновляющийся дает некое видение проекта, как программистам так и руководителям.
5. Безопасность разработчиков. Разработчики в безопасности от вмешательств извне, хотя бы во время sprint'a.
6. Более подробное проектирование/планирование. Задача не берется в sprint пока она полностью не понята разработчиками, либо устраивается мини sprint — аналитики/проектирования.
7. Постоянное, циклическое улучшение процессов. Feedback после демонстрации никто не отменял. Ежедневные планерки (митинги), также дают положительный прирост по улучшению процессов. И ретроспектива: улучшим все, что было плохо!

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

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

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

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

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

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

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

Чтение книг

Книг было пересмотрено не много. Часть из тех, которые советовали мельком поглядывали, но ничего отличающегося не находили и переставали читать. Основной (для себя), я считаю, “Agile и XP заметки с передовой” её я прочел раза три, и всегда, если мне задают вопрос: “Как узнать про Scrum?” -, я называю её. (ссылка есть в источниках и ссылках)

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

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

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

Карты

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

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

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

Доска

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

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

• Команда, которая ознакомилась с основными этапами;
• Подготовленный Redmine, составлен список задач;
• Подготовленный Poker-planning;
• Подготовлена Scrum-desk;
• И куча энтузиазма.

Первый опыт, первый 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 нами предпринимались:

1. Прилепить все листочки на доску.
2. Объявляем цель, к которой нужно прийти выполнив sprint, к сожалению (может быть к счастью) у нас было несколько целей, единой цели не было, так как в планировании участвовали разработчики из разных проектов.
3. Ведущий разработчик всем рассказывает про каждую feature по отдельности.
4. Если возникают вопросы то они тут же решаются.
5. Начинаем декомпозировать каждую feature на subtasks и опять же объяснять почему именно так, а не по иному.
6. Если все задачи декомпозированы и понятны, начинаем оценку при помощи Poker-planning.
7. Называется одна sub-task, и разъясняется еще раз, если кому-то не понятно.
8. Все разработчики, которые компетентны выполнять данную задачу (зачастую, практически все), выкладывают карты рубашкой вверх на стол с цифрой, которая равна story-points на выполнение данной задачи.
9. После того, как все выложили карты, переворачиваем карты.
10. Если есть сильные расхождения, то разработчик, который выложил оценку расходящуюся с остальными, объясняет остальным, почему возникла данная оценка. Если он чего-то не понял, то ему еще раз все объясняют. Далее, переоценка.
11. Если нет сильных расхождений, то оцениваемой sub-task присваивается значение, которое ей присвоили разработчики.
12. Таким образом оцениваются все sub-tasks, из сумм sub-tasks складывается оценка feature.
13. Если оценки features сильно расходятся с предварительной оценкой, нужно позже принять меры.
14. Набираем features на sprint. Для первого sprint'a мы установили, что наши разработчики могут выполнять примерно семь story-points в двухнедельный sprint. Соответственно, если их пять, то можно взять задач на 35 story-points. Мы взяли больше — 39, как позже оказалось это было ошибкой.
15. Вывешиваем взятые features на Scrum-desk.
16. Назначаем время ежедневных планерок (митингов), дату и время демонстрации.
17. Начинаем работу.

Первая планерка прошла удачно, заняла примерно 4 часа при участии 5-6 человек. Естественно (как оказалось для нас), взяли в sprint далеко не все, что изначально планировали. На планерке часть времени присутствовал директор, и ему и команде данное мероприятие очень понравилось, и команда с рвением приступила к выполнению features.

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

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

• Обязательно название sprint’а и команды.
• Обозначенная цель, основная задача команды, выполнить цель.
• Backlog sprint’а — features, которые должны быть выполнены для достижения цели. В скобках оценка в story-points. Те же задачи висят и на Scrum-desk.
• Обозначенные сроки sprint'a, а также время и место ежедневных планерок (митингов) и демонстрации.
• Перечисление членов команды, в скобках процентная занятость в данном sprint’е, если ничего нет, значит 100%.

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

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

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

На первую планерку все явились, как по часам, что не радует (в дальнейшем было все не так радужно). Собрались, начали обсуждать поочередно у кого как что идет, вопросов и проблем ни у кого не было. Перешли к 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’a.
• Второй столбец — Сколько осталось сжечь story-points. Каждый день во время планерки появляется значение.
• Третий столбец — эталон идеального сжигания story-points командой во время sprint’a, Идеально сжигать в день = Количество story-points взятых на sprint/ число дней.

К сожалению в бумажном виде не сохранилась, недавно была глобальная уборка, весь хлам выбросили.
В электронном виде делали при помощи MS Excel:

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

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

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

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

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

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

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

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

• Ввести всех в задачи и цели sprint'a;
• Фиксировать все вопросы и предложения во время выступления разработчиков;
• Отвечать на вопросы, помогая разработчику;
• Фиксировать все недочеты/положительные стороны в выступлении разработчиков;
• Подвести итог sprinta с демонстрацией burn-down;
• Зафиксировать и ответить на все вопросы по окончанию презентации;
• Получить feedback.

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

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

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

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

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

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

• Нужно делать больше слайдов в презентацие;
• Не звать на демонстрацию людей, которые косвенно относятся к проекту;
• Некоторые технические тонкости по улучшению оборудования работников;
• Более подробно обсуждать features на планировании, по ходу sprint’a выяснились некоторые нюансы, которые не были учтены.

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

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

Как все пошло

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

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

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

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

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

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

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

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

• Двухнедельный sprint. Оптимальное соотношение работ по разработке и работ по планированию. Но есть некий минус, — за временной промежуток в две недели появляются дополнительные (smart или срочные задачи от руководства) задачи, которые нам приходится делать, по этой причине не всегда sprint заканчивается удачно.
• Недельный sprint. Соотношение больше в сторону работ по планированию. Но сторонних задач почти нет, все sprint'ы заканчиваются успешно.
• Четырехнедельный sprint. Получаются очень сильные отклонения в результатах sprint'a. Самый неудачный для нас sprint.

В итоге мы остановились на двухнедельных sprint’ах.

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

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

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

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

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

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

Отказались от продуктов MS, перешли в облачное решение google doc. Также был модернизирована Scrum/Sprint -list. Основное отличие от первого варианта листа: задачи разбиты по каждому работнику и они декомпозированы. (ссылка есть в источниках и ссылках)

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

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

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

Графики отражают:

• Ideally. Как и обычно — то как нужно сжигать.
• Plan. То как сжигаются запланированные задачи.
• Off-plan (error). То как сжигаются запланированные задачи и задачи, которые не были учтены в плане, — ошибки при планировании.
• Off-plan (extra). То как сжигаются запланированные задачи и задачи, которые не относятся к задачам sprint’a (smart и пришедшие от руководства).
• Real. То как сжигаются задачи реально = план + ошибки + экстра.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Общедоступность материалов по работе команд.
• Быстрые условия для планирования новых sprint’ов, весь backlog уже содержится в системе и он в реальном времени пересматривается.
• Легко и быстро назначать запланированные задачи на работников, так как они уже в системе и только нужно назначить исполнителя.
• Стимуляция работников к увеличению продуктивности работы (регалиеметр далеко не единственный инструмент).
• Простота работы с документацией, так как все в облаке.
• Простота контроля работ, опять же, все в системе.

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

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

Заключение

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

Источники и ссылки:
Книга: «Scrum и XP: заметки с передовой»
Agile-манифест
Документ с основными мероприятиями
Scrum-list (первый )
Ссылка на магазин, где купить Poker planning
Scrum-list по прошествию времени
Доска для Битрикса

Автор: 1aZzy

Источник