Введение
Не в коем случае не хочу утверждать, что это гайд по тому, как вводить 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 от руководства и главных действующих лиц компании, был сформирован некий список того, что же хотелось увидеть:
- Прозрачность разработки. Каждый отдел (в частности руководители) должен был видеть, что же в разработке на данный момент и когда будет следующий результат.
- Внесение изменений в разработку в любой момент. Директор хотел влиять на ход разработки оперативно.
- Отчетность о результатах. Руководство хотело видеть мероприятия по отчетности.
- Пул задач со временем выполнения и приоритетностью
Также был собран feedback от разработчиков:
- Более подробная оценка срока выполнения задач.
- Минимизация последствий вмешательства в разработку извне.
- Повышение осведомленности разработчиков о поступающих задачах заблаговременно.
- Предоставление полной картины на выполняемые проекты.
Что рассматривал еще
- Введение жесткого регламентированного “waterfall”, чтобы нельзя было прерывать процессы. Но все такие возможность прерывать пересилила у руководства.
- Kanban, но как то не особо пошло дальше, точных причин указать не могу.
- Вариант: “ну с богом”, но он уже всех достал!
Почему Scrum удовлетворяет потребности
- Гибкость. Практически в любой момент можно пересмотреть приоритеты и внедрить новые features.
- Прозрачность. Sprint-list у каждого на почте (у главных действующих лиц) и изначально я его вешал в каждом кабинете. Также можно зайти в кабинет со Scrum-desk и посмотреть кто чем занимается в данный момент.
- Отчетность. Демонстрации по окончанию sprint'a, достаточно хорошая процедура, которая дает понять (в какой-то мере) что же вышло в результате.
- Подробная картина проекта (зависит от степени декомпозиции backlog’а). Постоянно обновляющийся дает некое видение проекта, как программистам так и руководителям.
- Безопасность разработчиков. Разработчики в безопасности от вмешательств извне, хотя бы во время sprint'a.
- Более подробное проектирование/планирование. Задача не берется в sprint пока она полностью не понята разработчиками, либо устраивается мини sprint — аналитики/проектирования.
- Постоянное, циклическое улучшение процессов. 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 нами предпринимались:
- Прилепить все листочки на доску.
- Объявляем цель, к которой нужно прийти выполнив sprint, к сожалению (может быть к счастью) у нас было несколько целей, единой цели не было, так как в планировании участвовали разработчики из разных проектов.
- Ведущий разработчик всем рассказывает про каждую feature по отдельности.
- Если возникают вопросы то они тут же решаются.
- Начинаем декомпозировать каждую feature на subtasks и опять же объяснять почему именно так, а не по иному.
- Если все задачи декомпозированы и понятны, начинаем оценку при помощи Poker-planning.
- Называется одна sub-task, и разъясняется еще раз, если кому-то не понятно.
- Все разработчики, которые компетентны выполнять данную задачу (зачастую, практически все), выкладывают карты рубашкой вверх на стол с цифрой, которая равна story-points на выполнение данной задачи.
- После того, как все выложили карты, переворачиваем карты.
- Если есть сильные расхождения, то разработчик, который выложил оценку расходящуюся с остальными, объясняет остальным, почему возникла данная оценка. Если он чего-то не понял, то ему еще раз все объясняют. Далее, переоценка.
- Если нет сильных расхождений, то оцениваемой sub-task присваивается значение, которое ей присвоили разработчики.
- Таким образом оцениваются все sub-tasks, из сумм sub-tasks складывается оценка feature.
- Если оценки features сильно расходятся с предварительной оценкой, нужно позже принять меры.
- Набираем features на sprint. Для первого sprint'a мы установили, что наши разработчики могут выполнять примерно семь story-points в двухнедельный sprint. Соответственно, если их пять, то можно взять задач на 35 story-points. Мы взяли больше — 39, как позже оказалось это было ошибкой.
- Вывешиваем взятые features на Scrum-desk.
- Назначаем время ежедневных планерок (митингов), дату и время демонстрации.
- Начинаем работу.
Первая планерка прошла удачно, заняла примерно 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 по прошествию времени
» Доска для Битрикса
Комментарии (26)
jetcar
20.12.2016 14:42+2все менеджеры любят этот аджайл скрам, всякие графики, но почему-то никто не сравнивает с тем что было до этого, тупо перешли потому что модно и графики красивенькие, но ведь это не показатель, показатель это количество полезной работы которая была зделана, надо сравнить до аджайла и после
померить конечно трудно, но без этого нельзя сказать что стало лучше или хуже.
как показывает практика внедрение управление процессами менеджмента задачами не повышаеат качество и быстроту написания продукта, его повышают внедрение правильных процессов разработки: техническая документация, TDD, код ревью и различные виды тестирования конечного продукта.evocatus
20.12.2016 14:44+1Да. Когда читал, отметил про себя, что на двухнедельный «спринт» у них ушло 4 часа на планирование задач и 1,5 часа на обсуждение результатов в конце. Считай целый рабочий день для множества людей. А в двух неделях 10 рабочих дней. Итого 10% времени как минимум, потому что я не учёл время на подготовку ко всем этим встречам (а готовиться к ним нужно не только менеджеру, у которого, готов поспорить, почти всё время уходит на эти бумажки и ежедневное расклеивание их по офису)
1aZzy
20.12.2016 14:57Вы правы, на подготовку уходит много времени, и я это отмечал, как большую проблему в статье. Но нет, большинство времени уходит не на это. Потраченный день на обсуждение и разжевывание задач ничто по сравнению с тем, какие потери могут быть, например: разработчик не правильно понял feature и реализовал её не так, как нужно было клиенту, или, недавно был случай: клиенту не показали, как положено по регламенту модель его аппарата и сразу сделали боевой образец, итог, аппарат стоит пылится, такой клиенту он не нужен (банально не провели демо).
jetcar
20.12.2016 15:59без знания задачи трудно оценить где именно пошло не так, но скорее всего демо тут проблему не решилобы, да и готовый образец видимо зделали потому что его было легко зделать, если же клиент ждал год и не интересовался что вы делали, то может ему и не нужен был хороший результат.
1aZzy
20.12.2016 16:29Решило бы. Просто не те размеры, которые хотел клиент. Разрабатывали по «хотелкам» клиента.
1aZzy
20.12.2016 14:48Видимо я плохо передал некоторые нюансы. Agile, потому что он позволяет адаптировать разрабатываемый продукт под нужны клиента/руководителя в самые короткие сроки, чем короче итерации, тем быстрее можно перекроить планы, а это нам и было нужно он «фреймворка» ведения проекта. Да, вы правы, для улучшения качества и быстроты нужно внедрять еще множество технических процессов разработки. У нас они внедряются параллельно тому, что описано в этой статье.
jetcar
20.12.2016 15:10но у вас всё равно нет сравнения до и после
как аналогия, взяв машину с мощным двигателем ещё не означает что она доедет из одной точки в другую за более быстрое время, по пути изза большего расхода придёться заправляться намного чаще и в конце она может приехать медленнее чем со слабым двигателем, но меньшим расходом1aZzy
20.12.2016 16:32Да, у меня нет сравнения, так как новую систему строил я, а старых данных у меня к сожалению нет. Да и команда/технологии/процессы кардинально поменялись, тут было бы сравнение не в двигателях, а сравнение лошади и машины.
jetcar
20.12.2016 17:00вот не надо про лошадь и машину, лошадь тогда будет аджайлом так как по параметрам ближе,
кстати раз аджайл уже работает и есть оценимые результаты то надо для сравнение поработать без него какоето время и тогда можно не только сравнить, но и убедить всех скептиков в выгоде ну или наоборот тут всё от результата зависит.
думаю довольно разумное предложение, сам бы потестил, но я ни кем не руковожу, а в новой фирме пока достаточного влияния не имею1aZzy
20.12.2016 17:07Agile мы применяем разумно, есть проекты, которые идут по старой доброй каскадной модели, так как мы работаем и с тендерами в том числе, а там нужно иметь четкие сроки завершения того или иного этапа. У всего должна быть мера. Я далеко не из тех, которые пропагандируют agile и только его. И сравнение лошади и машины, — это сравнение того как работали раньше (абы как) с тем, что есть сейчас.
WarFollowsMe
20.12.2016 14:48+1А не пробовали вместо физических досок использовать электронные аналоги? Что-то вроде trello например.
1aZzy
20.12.2016 14:50Redmine с плагином backlog's предоставляет некоторую электронную доску задач, но она мне не совсем нравится. Плагин для 1С Битрикса потрогал, но пока дальше в работу не пошло. В ближайшее время планируем внедрять. Посмотрю ту, которую вы посоветовали, спасибо.
Odrin
20.12.2016 15:30Слово «scrum» в статье используется 24 раза, но при этом сама эта методология у Вас в итоге не используется. Зато есть карточки, листики на стене, графики и презентация. Так что да, как Вы в конце статьи и отметили:
а может быть и опыт, как делать нельзя.
Askofen
21.12.2016 18:33На мой взгляд, при организации работы команды совершено несколько ошибок. (На истину в последней инстанции я не претендую, но свою точку зрения выскажу.)
1. Большие затраты времени на планирование спринта. Если в планировании принимают участие 6 человек и тратят на это 4 часа рабочего времени, то потери времени 24 человеко-часа. Это три дня. Зачем это нужно? Люди должны приучаться работать самостоятельно и индивидуально. Можно распределить задачи между членами команды и попросить каждого из них сделать task break-down & estimation. Затем ведущий программист сделает ревью. Другой вариант — поручить эту работу лиду, а затем сотрудник, которому поручается данная задача делает ревью оценки и декомпозиции. Такая процедура займет гораздо меньше времени.
2. Одно совещание для разных команд существенно увеличивает общие затраты времени. Сотрудников команды А не интересуют задачи команды Б (да и не должны интересовать). Они просто тратят свое время впустую, хотя могли бы в это время продуктивно работать над своими задачами.
3. Общие совещания размывают индивидуальную ответственность. Они позволяют части работников элементарно сачковать, соглашаясь с мнением более активных сотрудников. Каждый человек должен делать свою работу. Если кто-то не умеет делать декомпозицию или оценивать задачи, то важно попросить ведущего программиста его научить. Но, в любом случае, задание должен выполнить тот сотрудник, которому оно поручено. А ревью поможет выявить сделанные ошибки.
4. Использование бумажных карточек в то время, когда имеются электронные системы контроля задач — это расточительная трата времени. Карточки не делятся на подзадачи, плохо фильтруются и плохо ищутся (если, конечно, речь идет не о 5 — 7 штуках). Электронные системы учета задач позволяют быстро искать задачи и быстро их фильтровать. Можно обходиться обычным редмайном или джирой без всяких надстроек. Мы идентифицируем майлстоуны при помощи меток. Точно так же можно поступать и со спринтами.
5. Непонятно, как в команде осуществляется контроль качества. Кто верифицирует сделанные задачи с точки зрения пользователя? Как это успевает делаться в течение одного спринта? Или баги могут фикситься и в другом спринте? Как осуществляется верификация технического решения? Кто за это ответственный?
Общий вывод: непонятно, какие проблемы были в самом начале и как они были решены при помощи скрама. Пока что видны большие потери времени, которые команда вынуждена тратить на планирование и ретроспективы.1aZzy
22.12.2016 07:311. Пример про четыре часа планирования был приведен из одной команды, в других планирование проходит быстрее. Четыре часа: данная команда работает над сложными техническими решениями и только ведущий разработчик имеет понимание, как решать поставленные задачи. Планерка состоит в том, что вед. объясняет остальным, как решать поставленные задачи, так как оюбому может достаться любая задача, то и на планерка должны быть все. Подчеркну, что длинная планерка только у одной команды.
2. В статье я указал на то, что сейчас команды разделены на разные направления, то есть планерка у всех разработчиков проходят по раздельно в соответствии с проектом.
3. Сейчас, только одна команда большая: 5 человек, все остальные 2-3, планерка быстрые и каждый задействован, сачковать не кому не удается.
4. В статье я подчеркнул, что сейчас перешли полностью в электронный вид. Я считаю, чтобы изначально сотрудники познакомились с новой системой, должна быть наглядная визуализация.
5. Проверка задач на ошибки осуществляется отделом тестирования — отдельная команда, иногда состоят в одной команде с разработчиками, иногда в спринте выделяется время на правку багов, но за частую, — это другой спринт. Верификацию от лица пользователей, осуществляют заинтересованные люди компании: руководство, маркетинг, я и др. Техническая верификация: в каждой команде есть вед, который осуществляет контроль по мердж реквестам.
Основная проблема: отсутствие структурности и системности в работе it-отдела организации.Askofen
22.12.2016 14:05Планерка состоит в том, что вед. объясняет остальным, как решать поставленные задачи, так как оюбому может достаться любая задача, то и на планерка должны быть все.
Если задачи разных разработчиков пересекаются, то тогда — да, лиду имеет смысл собрать команду и объяснить подходы к решению. Однако если задачи не пересекаются или пересекаются слабо, то лучше поступить по-другому — распределить их между членами команды, дать время подумать, выработать подходы к решению и с каждым провести индивидуальную беседу. Это будет и продуктивнее, и не будет отнимать время у каждого члена команды на обсуждение вопросов, которые ему не важны.
Все разработчики, которые компетентны выполнять данную задачу (зачастую, практически все), выкладывают карты рубашкой вверх на стол с цифрой, которая равна story-points на выполнение данной задачи.
Оценивать задачу должен исполнитель. Если у исполнителя нет компетенции в какой-то области, которая важна для выполнения задачи, он должен обратиться к соответствующему специалисту или к ведущему программисту. В ряде случаев оценку может производить и ведущий специалист, но он обязательно должен согласовать свою оценку с программистом, который будет задачу выполнять.
Главное при выполнении эстимейта — это декомпозиция и оценка сложности задачи. Эти навыки пролявляются с опытом, когда человек из раза в раз самостоятельно выполняет данную работу и учитывает ошибки, совершенные в предыдущие разы. Игра в карты не помогает ставить такие навыки.
Я считаю, чтобы изначально сотрудники познакомились с новой системой, должна быть наглядная визуализация.
При работе с электронными системами контроля задач важны следующие навыки:
- грамотно и понятно называть задачи;
- умение пользоваться поиском и фильтрами;
- умение вовремя обновлять статус задачи;
- умение грамотно закрывать задачу (нужно указать номер ревизии, в которой задача реализована);
- умение следить за статусом задачи после того, как она перейдет на тестирование, т.к. задача может тестирование не пройти, и потребуются изменения.
Работа с бумажными карточками эти навыки НЕ ставит.1aZzy
22.12.2016 14:39Планерка состоит в том, что вед. объясняет остальным, как решать поставленные задачи, так как любому может достаться любая задача, то и на планерка должны быть все.
Да, — это по той причине, что задачи пересекаются и могут достаться любому, и чтобы не объяснять по десять раз, если исполнитель поменяется, собираемся, чтобы объяснить один раз.
При работе с электронными системами контроля задач важны следующие навыки:
грамотно и понятно называть задачи;
умение пользоваться поиском и фильтрами;
умение вовремя обновлять статус задачи;
умение грамотно закрывать задачу (нужно указать номер ревизии, в которой задача реализована);
умение следить за статусом задачи после того, как она перейдет на тестирование, т.к. задача может тестирование не пройти, и потребуются изменения.
Я с вами полностью согласен, что нужно пользоваться электронными системами, к этому мы и пришли своим путем.
Оценивать задачу должен исполнитель.
К этому мы тоже пришли, но это правильно, если исполнитель один и не изменим не при каких обстоятельствах.
aleksey_buneyev
22.12.2016 06:57Создалось такое впечатление, что у вас руководство это баласт, который умеет требовать и больше не умеет ничего. При вашем интузиазме, инициативности и самоорганизованности непонятно зачем вам руководители?
1aZzy
22.12.2016 06:59Возможно, я не раскрыл всю картину, деятельность нашей организации больше чем на половину не it, вот там то все и крутится у руководства. У меня не достаточно опыта, чтобы организовывать все самому.
aleksey_buneyev
22.12.2016 08:21И про 1С-Битрикс (Вероятно Корпоративный портал в коробке) вы пишете, а почему не пробуете Saas Битрикс24? Там есть тот же task tracker (список, Гант, скоро будет канбан), есть в маркете приложение scrumban, таке есть различные интеграции с Jira и Redmine.
1aZzy
22.12.2016 09:14В статье я писал, что на предприятии используется битрикс, и в ближайших планах: мы будем с ним взаимодействовать. И про scrumban я писал, даже есть ссылка на магазин. Но чесно говоря, нам в it-отделе, он не особо нравится.
ifalur
Хорошая полезная статья, но читать невозможно. Скажите, вы русский язык совсем позабыли? пул, feedback и т.д.
1aZzy
Есть у меня такая проблема. Боремся! Следующий раз постараюсь, чтобы было все лучше!