Введение Я ни в коем случае не хочу утверждать, что это руководство по внедрению Scrum — это всего лишь опыт внедрения и адаптации Scrum под нужды одной компании.
Этот опыт может быть интересен/полезен как новичкам: базовые советы, этапы, циклы и т.п.
, так и профессионалам: обсудить, что пошло не так, чего не следовало делать и т.п.
Подчеркну: то, что мы придумали, всего лишь что-то напоминающее Scrum. 
Предыстория, с чего все начиналось, как мы пришли к выводу, что Scrum нужен
Я работаю руководителем IT-отдела (менеджером проектов) в небольшой/средней томской компании.Численность сотрудников ИТ-отдела на начало деятельности: 5 человек, на данный момент: 24 человека.
На начальном этапе я был гейм-дизайнером, но постепенно перешёл в стан менеджеров проектов.
Примерно это произошло летом 2014 года, и это время мы будем считать отправной точкой.
Как и большинство начинающих менеджеров, я бросился изучать материалы: искать в Интернете, смотреть записи конференций, читать книги, общаться со старшими братьями из других компаний, приобрел массу знаний, как мне тогда казалось (это, конечно, было ошибка).
И я, амбициозный и вдохновленный новыми целями и задачами, ринулся в бой.
Я считаю, что основная проблема начинающего руководителя – это отсутствие или некорректность общения с сотрудниками.
Причин этой проблемы может быть много: отсутствие опыта, недоверие со стороны сотрудников, незнание основных технических/бизнес-процессов и т. д. Но мне в этом вопросе повезло.
Изначально я тесно сотрудничал с разработчиками, будучи гейм-дизайнером, а до этого немного работал программистом при полном отсутствии менеджмента, поэтому у меня было определенное видение того, чего не хватает.
Как это было до Scrum
Изначально мы развернули старый Redmine без каких-либо плагинов и настроек, его можно считать практически чистым, TeamCity (бесплатный), чтобы обеспечить хоть какую-то сборку, SVN, куда бы мы были без репозитория.В целом все работало.
Задачи ставились в редмайне, и по мере их выполнения вписывались часы, а иногда и проценты выполнения, но зачастую не было ни сроков, ни каких-либо планов; вам очень повезло, если был хотя бы обговоренный срок.
И вот пришло мое время.
Руководство дало мне добро использовать все, что душе угодно (это принесет больше прибыли).
Как я писал выше, это лето 2014 года.
На тот момент мы еще едва были знакомы с Agile, университетским курсом и парой статей.
Поэтому мыслей о какой-либо гибкости у нас еще не было, и мы начали действовать по старинке (возможно, мысли и возникали, но нехватка опыта и что-то еще мешало им продвинуться дальше).
Изначально мы записывали свои основные задачи на досках, которые висят почти в каждом офисе.
Это выглядело примерно так: 
Естественно, всё было переведено в электронный вид: для некоторых задач они записывались в редмайне в виде фичи или эпоса, для некоторых в старом добром Excel также устанавливалась важность и примерные сроки выполнения задач.
Затем мы приступили к декомпозиции и оценке задач с каждым сотрудником, который будет их выполнять.
Результатом стал набор функций с подзадачами и оценкой времени выполнения задач.
В результате получается своего рода отставание, но потом с ним нужно как-то работать; само по себе оно не дает результатов.
Диаграммы Ганта
За некоторое время до этого я наткнулся на диаграммы Ганта (ленточные диаграммы) в компании, где работал программистом.Я сделал пару схем для наших проектов, показал эскизы руководству, и этот прием им понравился.
И я начал изучать инструменты, которые позволили бы мне сделать эти самые диаграммы в лучшем виде.
Я пытался:
- Множество настольных программ , например: планирование гантов и многое другое, что легко можно найти в Интернете, некоторые из них были отвратительного качества, некоторые были платными.
Единственное, что я могу упомянуть, это Gant Project. Это достаточно удобно и позволяет легко и быстро создавать необходимые диаграммы.
Минусы: из-за того, что у меня была бесплатная версия, она не позволяла загрузить ее в нужном формате и отсутствие возможности работать в команде над одним проектом.
- 1С Битрикс CRM .
В то время мы активно реализовывали эту программу на предприятии.
Это позволило создавать диаграммы с некоторым ограниченным функционалом.
Минусы: перегруженный интерфейс, отсутствие возможности менять цвета на диаграмме (это мне очень не понравилось), опять же на тот момент не было возможности загрузить в нужном формате (сейчас вроде есть).
Большой плюс — возможность работать в команде, но нам в IT-отделе не очень понравилось работать в этой программе.
- Редмине.
Здесь все просто — вы ставите задачи со сроками, а диаграммы появляются сами.
Минусы: если вы строите гипотетические планы с привлечением множества разработчиков и хотите по планам увидеть, что и как, то разработчики все это видят и это все начинает захламлять их рабочее пространство и опять же нет возможности сделать красиво цвета.
- МС Проект .
Почему-то я его тогда пропустил, позже активно пользовался и все понравилось, кроме сложности настройки командной работы.
- Мегаплан .
Старая CRM-система компании.
Я сразу отмахнулся, все было не удобно.
- MS Excel .
Старый добрый, я до сих пор иногда использую его для некоторых планов.
В конце концов Повозившись с некоторыми программами и время от времени меняя их, мы несколько месяцев потратили на запуск проектов с активным использованием диаграмм Ганта.
Руководству все понравилось, оно увидело четкие и утвержденные планы и, казалось бы, все было хорошо, за исключением маленького НО (большого).
Этот НО , Руководство и прочее: маркетологи, отдел продаж и т. д. постоянно впихивают в план какие-то разработки в самые неподходящие моменты.
Это привело к необходимости полностью перестроить план и переложить задачи разработчиков, придумывая новые задачи на время простоя, если таковые появлялись.
Когда в команде было мало людей, особых проблем не было, перемещение пары человек не представляло собой ничего особенно плохого, но когда более двух человек начинали зависеть от выполнения одной задачи, а иногда проталкивание приводило к тому, что задачи пропадали вообще , то перестроить планы стало проблематично.
Вот тут и возникла необходимость в чем-то другом.
Каковы были потребности?
Собрав отзывы руководства и главных героев компании, сформировался определенный список того, что мы хотели увидеть:- Прозрачность развития.
Каждый отдел (в частности менеджеры) должен был видеть, что находится в разработке в данный момент и когда будет следующий результат.
- Изменения в разработке в любое время.
Режиссер хотел оперативно повлиять на ход разработки.
- Отчетность о результатах.
Руководство хотело видеть отчетность.
- Пул задач со временем выполнения и приоритетом
- Более детальная оценка времени выполнения задач.
- Минимизация последствий внешнего вмешательства в развитие.
- Заблаговременное повышение осведомленности разработчиков о поступающих задачах.
- Предоставление полной картины реализуемых проектов.
Что еще вы рассмотрели?
- Введение строго регламентированного «водопада», чтобы процессы не могли быть прерваны.
Но все подобные возможности прерваться были подавлены руководством.
- Канбан, но дальше как-то дело не пошло, точные причины указать не могу.
- Вариант: «Да хранит вас Бог», но он уже всех достал!
Почему Scrum удовлетворяет потребности
- Гибкость.
Практически в любой момент вы можете пересмотреть приоритеты и внедрить новые возможности.
- Прозрачность.
У каждого есть Спринт-лист на почте (у главных героев) и изначально я вешал его в каждом офисе.
Также вы можете зайти в офис со Scrum-деком и посмотреть, кто чем занимается в данный момент.
- Составление отчетов.
Демонстрации в конце спринта — достаточно хорошая процедура, которая дает понять (в некоторой степени), что произошло в результате.
- Подробная картина проекта (в зависимости от степени декомпозиции бэклога).
Постоянное обновление дает определенное видение проекта как программистам, так и менеджерам.
- Безопасность разработчика.
Разработчики защищены от внешнего вмешательства, по крайней мере, во время спринта.
- Более детальное проектирование/планирование.
Задача не берется в спринт, пока она не будет полностью понята разработчиками, или не будет организован мини-спринт — аналитика/проектирование.
- Постоянное, циклическое улучшение процессов.
Отзыв после демонстрации никто не отменял.
Ежедневные планерки (совещания) также дают положительный импульс в совершенствовании процессов.
И ретроспектива: давайте исправим всё, что было плохо!
Как я это всем передал
Разработчики уже поняли основные понятия из статей, поэтому проблем с ними практически не было, все приняли их с энтузиазмом.Основной проблемой было руководство, но поскольку оно практически не участвует в процессах, мы держим карты в своих руках.
Как вы этому научились? Что ты смотрел? Какие ресурсы? Какие книги?
Общение с профессионалами
Мы поговорили с менеджерами других компаний, узнали, что и как они делают. Мы посмотрели, какие отклонения от нормы они допустили, посмотрели, как и что можно применить в нашей стране.Честно говоря, мы особо ничему не научились.
Основной вывод: каждый действует так, как ему заблагорассудится (как ему удобно в Agile).
Чтение статей
Мы рассмотрели кучу статей; никто не может вспомнить, какие из них были включены.Но их было много.
Времени на это было отведено достаточно.
Естественно, все зависит от Agile-манифеста, на него ссылается большинство статей и сайтов, поэтому мы не стали исключением и взяли его за первоисточник.
(ссылка есть в источниках и ссылках)
Чтение книг
Не многие книги были рецензированы.Некоторые из советовавших посмотрели бегло, но ничего другого не нашли и бросили читать.
Основной (для себя), я считаю, «Заметки по Agile и XP с передовой», я прочитал ее раза три, и всегда, если мне задают вопрос: «Как узнать о ScrumЭ» -, Я называю ее.
(ссылка есть в источниках и ссылках)
Начало реализации
Документ с указанием основных видов деятельности
Мы обозначили основные направления деятельности и создали небольшой список с описанием действий, который раздали всем сотрудникам для ознакомления.На тот момент он был, естественно, далек от совершенства.
(ссылка есть в источниках и ссылках)
Карты
Естественно, нужно было где-то раздобыть карты для покер-планирования.Посмотрели ряд магазинов в интернете, стоимость колоды на четверых человек варьировалась от 1000 руб до 2000 руб.
Просить деньги у руководства мне не очень хотелось, поэтому я сделал их сам.
Обычная бумага формата А4, черно-белый принтер, ножницы — вот что получилось: 
Я много раз пытался их переделать, цветной принтер, картон и многое другое, но эти старые добрые карты (не в полной силе) служат до сих пор.
Интересен тот факт. Надеюсь, я ничего не перепутал.
Одним из немногих на тот момент магазинов по продаже колод карт, которые мне понравились, был Planningpoker.ru. Потом я подумал, какие классные карты.
Позже, несколько лет спустя, на конференции директор компании, организовавшей этот магазин, совершенно случайно подарил мне одну из этих колод. (ссылка есть в источниках и ссылках)
Доска
Следующий важный этап — подготовка Scrum-стола, я взял обычный ватман, парочку А3 и А4, маркеры, скотч и т. д. И получилось довольно неплохо:
Что произошло в результате подготовки
- Команда, ознакомившаяся с основными этапами;
- Подготовлено Redmine, составлен список задач;
- Подготовлено Покер-планированием;
- Подготовлено Scrum-desk;
- И много энтузиазма.
Первый опыт, первый спринт
Отставание
Первый бэклог мы построили в MS Excel, разбив все по нужным столбцам:
Естественно, есть ряд столбцов, которые не включены в рисунок, но это уже другая история.
Подчеркну, мы получили именно задачи (feature), а не желания пользователя (user-story), как это принято в Agile. Было решено сделать первый спринт двухнедельным.
Мы расставили приоритеты, отсортировали их, отметили зелёным то, что хотелось бы взять в спринт, и расставили стори-пойнты.
Хм, а что такое сюжетная точка?!
На что обратили внимание разработчики.
Сюжетная точка - день Разработчикам довольно сложно и непонятно перейти на систему оценки стори-пойнтов — идеальных человеко-дней.
Как мы объяснили, стори-пойнт — это идеальный восьмичасовой рабочий день разработчика, когда у него все под рукой, ничего не отвлекает от работы (уже заметны проблемы, у него все есть и не мешает хм.
.
), он изолирует от других комнату, где есть свежий воздух, еда, чай/кофе, туалет, и продуктивно выполняет поставленную задачу, решение которой ему совершенно ясно.
Некоторые вещи также были добавлены при объяснении новичкам, но они не имеют особого значения.
Распределение ролей
В нашей компании практически нет кросс-разработчиков? Есть отдельные тестеры и мы разрабатываем под разные платформы.Соответственно, мы слабо полагаемся на одну из концепций Scrum, например, на объединение работников.
Мы этим пренебрегли и в первом спринте у нас в одной команде участвовали разные разработчики.
Планирование
Все фичи из бэклога, которые должны были пойти в спринт, были распечатаны, и мы приступили к оценке.
Какие действия мы предприняли во время планирования спринта:
- Наклейте все листья на доску.
- Мы объявляем цель, которую нам необходимо достичь, завершив спринт. К сожалению (а может и к счастью) у нас было несколько целей, единой цели не было, так как в планировании участвовали разработчики из разных проектов.
- Ведущий разработчик рассказывает всем о каждой функции отдельно.
- Если возникают вопросы, они решаются сразу.
- Начинаем каждую фичу разлагать на подзадачи и еще раз объясняем, почему так, а не иначе.
- Если все задачи декомпозированы и понятны, начинаем оценку с помощью Покер-планирования.
- Называется одна подзадача, и она объясняется еще раз, если кто-то не понял.
- Все разработчики, способные выполнить данное задание (часто почти все), кладут на стол карточки рубашкой вниз с числом, равным сюжетным очкам за выполнение этого задания.
- После того как все разложили карты, переворачиваем карты.
- Если есть сильные расхождения, то разработчик, выставивший оценку, отличающуюся от остальных, объясняет остальным, почему возник этот рейтинг.
Если он чего-то не понимает, то ему все объясняют еще раз.
Далее переоценка.
- Если сильных расхождений нет, то оцениваемой подзадаче присваивается то значение, которое задали ей разработчики.
- Таким образом оцениваются все подзадачи, а оценка функции формируется из сумм подзадач.
- Если оценки функций сильно отличаются от предварительной оценки, вам необходимо принять меры позже.
- Введите функции в спринт. Для первого спринта мы определили, что наши разработчики смогут выполнить примерно семь пунктов истории за двухнедельный спринт. Соответственно, если их пять, то можно брать задания на 35 стори-пойнтов.
Мы взяли больше – 39, что позже оказалось ошибкой.
- Выбранные фичи размещаем на Scrum-desk.
- Назначаем время ежедневных планерок (совещаний), дату и время проведения демонстрации.
- Давайте приступим к работе.
Естественно (как у нас получилось), мы не взяли в спринт все, что планировали изначально.
Директор часть времени присутствовал на планерке, и ему и команде это мероприятие очень понравилось, и команда с энтузиазмом приступила к реализации фич.
Мы составили Scrum-лист (в MS Word):
(ссылка есть в источниках и ссылках)- Укажите название спринта и команды.
- Обозначенная цель, главная задача команды – выполнение поставленной цели.
- Бэклог спринта — функции, которые необходимо выполнить для достижения цели.
В скобках указан рейтинг в стори-поинтах.
Те же задачи висят на столе Scrum.
- Назначены даты проведения спринта, а также время и место ежедневных планировок (совещаний) и демонстраций.
- Список участников команды, в скобках процент занятости в этом спринте, если ничего нет, то 100%.
Но позже оказалось, что это просто пустая трата бумаги и она никому особо не нужна, достаточно было одного листа (позже больше, когда ИТ-офисов стало больше) в офисе разработчиков.
Зачем нужен лист? Для того, чтобы другие команды и люди, участвующие в проекте, представляли, какие задачи в данный момент выполняет та или иная команда.
А также для того, чтобы посмотреть, какой будет результат через определенный промежуток времени.
Ежедневные планерки
На первую планерку все пришли как по маслу, что не радует (далее все было не так радужно).Мы собрались и начали по одному обсуждать, как идут дела, ни у кого не возникло вопросов и проблем.
Мы перешли к столу Scrum.
Бумажная доска задач
Начали передвигать наклейки и тут столкнулись с проблемой, так как наклейки были приклеены к ватману скотчем, отклеить их и переклеить было небольшой проблемой.Мы справились с этим с большим трудом (позже мы приобрели навык и это не было проблемой).
Стали отмечать сожженные стори-поинты, и тут возник определенный вопрос: ни у кого из разработчиков не было проблем или вопросов, а стори-поинты сгорели недостаточно.
Причина, как обычно, банальна: кто-то просто потратил какое-то время на сборку и просто все время не выполнял свою задачу, кто-то проводил подготовительную работу, никак не входящую в спринт, и в том же духе.
В результате у нас получилось нечто похожее: 
Изначально наклейки просто приклеивались на доску, но со временем их стали дополнительно закреплять скотчем; было пару прецедентов, когда все отваливалось.
Позже появилась ещё пара рубрик типа: в тестировании, код-ревью и т.д.
Зачем нужно выгорание?
Burn-down нужен для того, чтобы можно было отслеживать ход спринта команды, а также для того, чтобы наглядно видеть отклонения от выполненного плана с течением времени.Основная цель Burndown: показать команде (поскольку команды у нас самоорганизующиеся), что в случае отклонения необходимо принимать оперативные меры.
Как построить выгорание?
Многие инструменты позволяют строить диаграммы сгорания в электронном виде; мы использовали MS Excel, а также строили их на ватмане.Изначально (позже появились дополнительные столбцы) наша таблица содержала:
- Первый столбец — это даты от первого рабочего дня до последнего рабочего дня спринта.
- Второй столбец — сколько сюжетных очков осталось сжечь.
Каждый день во время планерки имеет смысл.
- Третий столбец представляет собой стандарт идеального сжигания сюжетных очков командой во время спринта.
В идеале сжигается за день = количество очков истории, полученных за спринт / количество дней.
Это было сделано в электронном виде с использованием MS Excel: 
Как видно из диаграммы, первый спринт прошел практически успешно, с небольшими отклонениями от идеального исполнения.
НО , как гласит правило: Если в конце спринта остаются несгоревшие стори-пойнты, то спринт провален.
В тот момент мы закрыли глаза на это правило и порадовались успешному завершению спринта!
Демонстрация
Пришло время продемонстрировать руководству результаты спринта.«Команда» (менеджер) готовила свою презентацию, а затем каждый член команды выполнял свою часть работы.
Изначально не было стандарта представления.
Зрителей собралось много: руководство, часть отдела продаж и маркетинга.
Презентация сделана в MS Powerpoint: 
В первой презентации было всего четыре слайда, по этой причине разработчикам было сложно демонстрировать, так как не было слайдов, о которых можно было бы говорить, но позже мы улучшили.
Где и как проходила демонстрация
Поскольку конференц-зала у нас на тот момент не было, презентация проходила в офисе разработчиков, они достали проектор и просветили его на стену.Вначале выступил менеджер (я), рассказал, почему все здесь собрались, рассказал основные цели и задачи спринта, и разработчики начали говорить по очереди, и все закончилось выступлением менеджера с демонстрацией работы спринта.
диаграмма вниз и вопросы общественности.
Основные задачи демо-менеджера:
- Познакомить всех с задачами и целями спринта;
- Зафиксируйте все вопросы и предложения во время презентации разработчиков;
- Отвечать на вопросы, помогая разработчику;
- Зафиксируйте все недостатки/положительные моменты в презентации разработчиков;
- Подведите итоги спринта с помощью демо-версии;
- Запишите и ответьте на все вопросы в конце презентации;
- Получать отзывы.
Разработчики на первой демоверсии
При первой демонстрации, как и в других десяти спринтах, разработчики сказали себе: использование сложной терминологии, углубление в предметную область, демонстрация результатов не для обычных людей.На начальных спринтах, иногда даже сейчас, приходилось перефразировать и резюмировать демонстрацию разработчиков, чтобы заинтересованные люди могли понять о чем идет речь.
Демо-аудитория
Было много абстрактных вопросов от общественности, косвенно связанных с продемонстрированным спринтом, на которые очень хочется получить ответ - это очень задерживает демонстрации по сей день.Первая демонстрация длилась полтора часа.
Ретроспектива
Первый спринт также оказался успешным для разработчиков.Отзывы были только положительные.
Какие улучшения обсуждались на первой ретроспективе:
- Вам нужно сделать больше слайдов в вашей презентации;
- Не приглашайте на демонстрацию людей, имеющих косвенное отношение к проекту;
- Некоторые технические детали для улучшения экипировки сотрудников;
- Более подробно обсудите особенности во время планирования; в ходе спринта выявились некоторые нюансы, которые не были учтены.
Обратная связь от руководства
Все понравилось, нужно больше слайдов в презентации.Руководство хотело привязать бонусную часть зарплаты разработчиков к результатам демонстрации спринта: заинтересованные стороны дают субъективные оценки каждому разработчику с учетом критериев этой оценки, оценка менеджера — среднее арифметическое всех оценок.
Эта система не прижилась, но это совсем другая история.
Как все прошло
После первого спринта уже много воды утекло, было предпринято много действий по оптимизации процессов, у кого-то была какая-то прибыль, у многих нет. Какие меры были принятыОбъединение команд, почему это произошло
Изначально у нас было две команды с разными профилями разработки, у каждой был свой Scrum с блэкджеком и Scrum-деск.Но так как у нас всегда, да и сейчас бывают просадки с менеджментом (я фактически один), у меня не было достаточно времени, чтобы организовать процессы планирования/сопровождения/демонстрации для двух команд. По этой причине мы решили объединить команды в одну.
Да, это помогло выиграть время, но нет, положительных результатов это не дало.
Это длилось четыре спринта, но поскольку у команд были совершенно разные профили разработки, у разработчиков не было абсолютно никакого смысла работать вместе.
Разделение команды
Со временем работников стало больше и сфер развития стало больше, появились мобильные телефоны или что-то еще.Как я сказал в пункте про объединение команд, людям совершенно незачем работать вместе, если между ними нет прямой связи в разработке проектов.
Соответственно, мы разделили команды на разные направления.
Да, это давало продуктивный результат для каждой отдельной команды, но каждая команда отнимала у менеджера очень много времени.
Различное время спринта
Мы попробовали разные варианты:- Двухнедельный спринт. Оптимальный баланс между разработкой и планированием.
Но есть определенный минус — в течение двух недель появляются дополнительные задачи (умные или срочные задачи от руководства), которые нам предстоит выполнить, по этой причине спринт не всегда заканчивается успешно.
- Еженедельный спринт. Отношение больше к планированию работы.
А вот сторонних задач почти нет; все спринты заканчиваются успешно.
- Четырехнедельный спринт. Есть очень сильные отклонения в результатах спринта.
Самый неудачный для нас спринт.
Перешел на доску с маркерами.
От ватмана отказались, он выглядит некрасиво, разработчикам он не понравился на обоях.
И это решает проблему отрыва ленты от бумаги.
Но появилась новая проблема - клей на доске.
Также пропала диаграмма сгорания в бумажном виде, так как я стал выводить изображение схемы на телевизор в офисе разработчиков.
Следующий этап: Стали маркерами на доске писать ежедневные таблицы розыгрышей: 
Таблица содержит: номер, столбец для записи задач не из плана, столбец для записи задач из плана.
Перешел на облачное решение: google doc
Мы отказались от продуктов MS и перешли на облачное решение Google Doc. Список Scrum/Sprint также был модернизирован.Основное отличие от первой версии листа: задачи разбиты по каждому сотруднику и они декомпозированы.
(ссылка есть в источниках и ссылках)
Мы начали вести диаграммы сгорания в таблицах Google. Со временем в таблицу стали добавляться новые значения: 
Поскольку при длительном спринте у нас была тенденция не укладываться в спринт (мы пытались брать резервы, но это ни к чему хорошему не приводило), мы ввели новое значение — off-plan, которое показывает график с учетом сжигание незапланированных задач.
Тогда мы пошли еще дальше и ввели еще три значения: Реальное, Off-plan (ошибка) и Off-plan (дополнительно): 
На графиках отражено:
- В идеале.
Как обычно, как сжечь.
- План.
Как сжигаются запланированные задачи.
- Вне плана (ошибка).
То, как сгорают запланированные задачи и задачи, которые не были учтены в плане, являются ошибками планирования.
- В проекте (за дополнительную плату).
Как сжигаются запланированные задачи и задачи, не относящиеся к задачам спринта (умные и те, что пришли от руководства).
- Настоящий.
Как на самом деле горят задачи = план + ошибки + доп.
Перейти к презентациям Google
Удобное решение, можно работать со всеми одновременно:
Теперь у нас гораздо больше слайдов, чем было вначале, но презентация стала более понятной и занимает меньше времени.
Мы попробовали плагин для Redmine
Мы установили плагин для Redmine, он называется Backlog’s. Дает возможность организовать работу с бэклогом продукта и спринтами через Redmine:
В этом плагине есть электронная доска задач, которая полностью повторяет функционал той, которая была у нас изначально в реальном виде.
Все столбцы подхвачены из Redmine — это значение статуса задачи.
Sprint заменяет значение и функциональность слова «версия» в Redmine. Довольно удобный плагин, пользуемся им и сейчас.
Был представлен регалиметр.
Отражает общее количество сожженных Story Points каждого сотрудника за все спринты.
Поощряет рабочих работать более продуктивно, каждый раб Теги: #scrum #agile #Управление проектами #управление командой #управление проектами #управление персоналом
-
10 Шагов К Успешному Выступлению На Хакатоне
19 Oct, 24 -
Весенный Мончегорск: Город Металлургов
19 Oct, 24
