- PVSM.RU - https://www.pvsm.ru -
Не в коем случае не хочу утверждать, что это гайд по тому, как вводить Scrum, — это лишь опыт введения и адаптирования Scrum’а под нужды одной компании. Данный опыт может быть интересен/полезен, как новичкам: основные наводки, этапы, циклы и т.п., так и профессионалам: обсудить что пошло не так, чего делать не стоило и т.п. Подчеркну, то что у нас вышло — это лишь нечто напоминающее Scrum.
Я работаю руководителем IT-отдела (менеджером проектов) в одной маленькой/средней томской фирме. Численность работников в IT-отделе на начало деятельности: 5 человек, на данный момент: 24 человека.
На начальном этапе я был геймдизайнером, но постепенно перекочевал в стан проект менеджеров. Примерно, это случилось летом 2014 года, данное время и будем считать начальной точкой.
Как и большинство начинающих управленцев, я ринулся изучать материалы: искать в интернете, смотреть записи конференция, читать книги, общаться со старшими собратьями из других фирм, приобрел кучу знаний, как я считал на тот момент (это естественно было ошибкой). И я, амбициозный и одухотворенный новыми целями и задачами, ринулся в бой.
Я считаю основной проблемой начинающего управленца: отсутствие или неправильная коммуникация с работниками. Причин этой проблемы может быть много: отсутствие опыта, недоверие со стороны работников, незнание основных технических/бизнес процессов и т.п. Но мне повезло в данном вопросе. Изначально я тесно работал с разработчикам, являясь геймдизайнером, а до этого я немного поработал программистом при полном отсутствии менеджмента, поэтому у меня было некое видение чего же не хватает.
Изначально у нас был развернут старенький Redmine без всяких плагинов и настроек, можно считать его практически чистым, TeamCity (бесплатный) для обеспечения хоть какого-то билдинга, SVN, куда же без репозитория. В Общем все работало.
Задачи ставились в redmine, по мере выполнения проставлялись часы а иногда и проценты выполнения, но зачастую не было ни сроков ни каких-то планов, очень везло, если был хотя бы обговоренный dead-line.
И тут настало мое время. Руководство дало мне добро на применение всего, что душе угодно (принесет больше прибыли). Как я уже писал выше — это лето 2014.
На тот момент с Agile мы были еще слабо знакомы, университетский курс и пару статей. Поэтому у нас еще не возникало мыслей о какой-то гибкости, и мы начали действовать по старинке (возможно, мысли возникали, но отсутствие опыта и что-то еще не давало им пробиться дальше). Изначально мы зафиксировали наши основные задачи на досках, которые у нас висят практически в каждом кабинете. Выглядело, это примерно так:
Естественно все было перенесено и в электронный вид: по некоторым задачам зафиксировано в redmine в виде feature или epic, по некоторым в старом добром Excel, также поставили важность и приблизительные сроки выполнения задач. Потом мы приступили к декомпозированию и оценке задач с каждым работником, который будет выполнять задачи. Получился набор feature с sub-tasks и оценкой сроков выполнения задач. Получился своеобразный backlog, но с ним дальше нужно как-то работать, сам по себе он не дает результатов.
За некоторое время до этого я сталкивался с Диаграммами Гантта (ленточные диаграммы) в фирме, в которой работал программистом. Сделал пару диаграмм по нашим проектам, наброски показал руководству, и эта методика им понравилась. И я приступил к изучению инструментов, которые позволили бы мне в наилучшем виде сделать эти самые диаграммы.
Мной были опробованы:
Вот так выглядели планы:
В итоге, потыкавшись с некоторыми программами и время от времени их меняя, мы несколько месяцев вели проекты с активным использованием диаграмм Гантта. Руководству это все нравилось, они видели четкие и утвержденные планы, и, вроде как, все устраивало, за исключением небольшого НО (большого).
Это НО, Руководство и не только: маркетологи, отдел продаж и т.п. постоянно продавливали какую-либо разработку в план в самые неподходящие моменты. Это приводило к тому, что нужно было полностью перестраивать план и смещать задачи разработчиков, с придумыванием новых задач на время простоя, если такое появлялось. Когда в команде было мало человек, то особых проблем не возникало, сдвинуть пару человек ничего особо страшного, но когда от завершения одной задачи стало зависеть более двух человек, а иногда пропихивания приводили к тому, что задачи вообще исчезали, то перестраивать планы стало проблематично.
Вот тут то и возникла потребность в чем-то ином.
Собрав feedback от руководства и главных действующих лиц компании, был сформирован некий список того, что же хотелось увидеть:
Также был собран feedback от разработчиков:
Основные концепции разработчики и так понимали из статей, так что с ними проблем практически не возникло, все восприняли с энтузиазмом. Основной проблемой было руководство, но так как оно в процессах практически не участвует, то нам и карты в руки.
Мы общались с менеджерами из других фирм, узнавали, что и как у них. Смотрели какие отклонения от нормы они делали, смотрели, как и что может быть применено у нас. Сказать честно: особо ничего не почерпнули. Основной вывод: все действуют, как им заблагорассудится (какой Agile удобен для них).
Нами было пересмотрено кучу статей, какие именно фигурировали, вспомнить уже никто не может. Но их было множество. Времени на это было выделено предостаточно. Естественно все упирается в Agile Манифест, большинство статей и сайтов ссылаются на него, так что мы не стали исключением, и брали его, как первоисточник. (ссылка есть в источниках и ссылках)
Книг было пересмотрено не много. Часть из тех, которые советовали мельком поглядывали, но ничего отличающегося не находили и переставали читать. Основной (для себя), я считаю, “Agile и XP заметки с передовой” её я прочел раза три, и всегда, если мне задают вопрос: “Как узнать про Scrum?” -, я называю её. (ссылка есть в источниках и ссылках)
Расписали основные мероприятия и сформировали небольшой список с описанием действий, раздали всем работникам для ознакомления. На тот момент он был, естественно, далек от совершенства. (ссылка есть в источниках и ссылках)
Естественно нужно было где-то достать карты для Poker-planning. пересмотрели в интернете ряд магазинов, стоимость колоды для четырех человек варьировалась от 1000 рублей до 2000 рублей. Денег просить у руководства мне особо не хотелось, и поэтому я их сделал сам. Обычная бумага А4, черно-белый принтер, ножницы, — вот что вышло:
Множество раз пытался их переделать, цветной принтер, картон и многое другое, но эти старые добрые карты (не в полном составе) служат до сих пор.
Интересный факт. Надеюсь я ничего не перепутал. Один из немногих на тот момент магазин по продаже колод карт, который мне мне понравился — planningpoker.ru. Подумал тогда, какие же прикольные карты. Позже, спустя несколько лет на конференции директор фирмы, которая организовала этот магазин, подарил мне одну из таких колод совершенно случайно. (ссылка есть в источниках и ссылках)
Следующий важный этап, это подготовка Scrum-desk, взял обычные ватманы, пару А3 и А4, маркеры, скотч и др. И получилось довольно таки неплохо:
Первый backlog мы строили в MS Excel, разбили все, как нужно на колонки:
Естественно, присутствует еще ряд колонок, которые не вошли на рисунок, но это другая история. Подчеркну, у нас получились именно задачи (feature), а не пользовательские желания (user-story), как это принято в Agile. Первый sprint было принято решение сделать двухнедельным. Расставили приоритеты, отсортировали, пометили зеленым, что хотелось бы взять на sprint, расставили story-points. Хм, что такое story-point?!
На систему оценки в story-points — идеальные человеко дни, перейти достаточно сложно и непонятно для разработчиков. Как мы объясняли story-point — это идеальный восьмичасовой рабочий день разработчика, когда у него есть все под рукой, ничто не отвлекает его от работы (уже заметны проблемы, есть все и не мешает хм...), он находится в изолированном от других помещении, где есть свежий воздух, еда, чай/кофе, туалет и он продуктивно выполняет поставленную задачу, решение которой ему полностью ясно. Некоторые вещи еще добавлялись при объяснении новичкам, но они особо не имеют значение.
В нашей компании практически нет cross-разработчиков? есть отдельные тестировщики и мы разрабатываем под различные платформы. Соответственно, мы слабо ложимся на одно из понятий Scrum, как унификация работников. Мы им пренебрегли и в первом sprint’е у нас участвовали разные разработчики в одной команде.
Были распечатаны все features из backlog’а, которые должны были пойти в sprint, и мы начали оценку.
Первая планерка прошла удачно, заняла примерно 4 часа при участии 5-6 человек. Естественно (как оказалось для нас), взяли в sprint далеко не все, что изначально планировали. На планерке часть времени присутствовал директор, и ему и команде данное мероприятие очень понравилось, и команда с рвением приступила к выполнению features.
(ссылка есть в источниках и ссылках)
Изначально, я распечатывал данный лист и развешивал его в каждом кабинете, а также рассылал по почте основным действующим лицам. Но позже выяснилось, что это лишь трата бумаги и это особо никому не нужно, хватало одного листа (в дальнейшем больше, когда стало больше it кабинетов) в кабинете разработчиков.
Зачем нужен лист?
Для того чтобы другие команды и вовлеченные в проект люди представляли какие задачи в данный момент выполняет та или иная команда. А также для того, чтобы видеть какой результат будет через определенный промежуток времени.
На первую планерку все явились, как по часам, что не радует (в дальнейшем было все не так радужно). Собрались, начали обсуждать поочередно у кого как что идет, вопросов и проблем ни у кого не было. Перешли к Scrum-desk.
Начали двигать стикеры и тут уже столкнулись с проблемой, так как стикеры были приклеены к ватману на скотч, отдирать их и переклеивать составляло некоторую проблему. С этим с горем пополам справились (в дальнейшем приобрели сноровку и это не составляло проблему). Стали проставлять сожженные story-points, и тут возник некий вопрос: не у кого из разработчиков не было проблем и вопросов, а story-points сожгли то не достаточно. Причина, как обычно банальна: у кого-то просто некоторое время ушло на раскачку и он просто не все время делал свою задачу, кто-то вел подготовительные работы, которые в sprint не были никак заложены и в том же духе. В итоге у нас вышло нечто похожее:
Изначально стикеры просто лепились на доску, но со временем стали их закреплять дополнительно на скотч, было пару прецедентов когда все слетало. Позже появилось еще пару столбцов типа: in testing, code review и т.п.
Burn-down нужна для того чтобы можно было отслеживать прогресс выполнения sprint’а у команды, а также для того чтобы в визуальном виде можно было видеть отклонения от выполняемого плана по времени. Основная цель burn-down: показать команде (так как у нас самоорганизующиеся команды), что нужно принять оперативные меры, если произошло отклонение.
Множество инструментов позволяют строить burn-down диаграммы в электронном виде, мы воспользовались MS Excel, а также строили на ватмане.
Изначально (позже появлялись дополнительные столбцы) наша таблица содержала:
К сожалению в бумажном виде не сохранилась, недавно была глобальная уборка, весь хлам выбросили.
В электронном виде делали при помощи MS Excel:
Как видно по диаграмме — первый sprint прошел практически удачно, небольшие отклонения от идеального исполнения. НО, как гласит правило: Если по окончанию sprint'a есть не сожженные story-points, то sprint провален. На это правило, на тот момент, мы закрыли глаза и радовались успешному завершению sprint'a!
Пришло время продемонстрировать руководству результаты sprint'a. “Команда” (менеджер) подготовила свою презентацию, в дальнейшем каждый член команды делал свою часть. Изначально не было стандарта презентации. Собралось много зрителей: руководство, часть отдела продаж и маркетинга.
Презентацию делали в MS Powerpoint:
В первой презентации было всего четыре слайда, по этой причине разработчикам тяжело было демонстрировать, так как не было слайдов того о чем рассказывать, но в дальнейшем мы исправились.
Так как у нас, на тот момент, не было conference-room презентация проходила в кабинете разработчиков, достали проектор и светили на стену.
Изначально выступил менеджер (я) рассказал для чего все тут собрались, рассказал основные цели и задачи sprint’a, и начали выступать по очереди разработчики, завершилось все выступлением менеджера с демонстрацией burn-down диаграммы и вопросами со стороны публики.
На первой демонстрации, как в прочем еще sprint'ов десять, разработчики рассказывали для себя: применение сложной терминологии, углубление в предметную область, демонстрация результатов не для обычных людей. На начальных sprint'aх, иногда и сейчас, приходилось перефразировать, резюмировать демонстрацию разработчиков, для того чтобы заинтересованные люди могли понять о чем идет речь.
Со стороны публики было много отвлеченных вопросов, которые косвенно относились к демонстрируемому sprint’у, на которые они очень хотят получить ответ, — это очень затягивает демонстрации и по сей день. Первая демонстрация длилась часа полтора.
Первый sprint прошел удачно и для разработчиков. Отзывы были только положительные.
Какие улучшения были обсуждены на первой ретроспективе:
Все понравилось, требуется больше слайдов в презентацие. Руководство захотело привязывать премиальную часть ЗП разработчиков к результатам демонстрации sprint'a: заинтересованные лица проставляют субъективные оценки каждому разработчику с проставлением критериев этой оценки, оценка менеджера — среднее арифметическое из всех оценок. Данная система не особо прижилась, но это уже совсем другой рассказ.
После первого sprint’a уже много воды утекло, было предпринято множестве действий по оптимизации процессов, некоторые имели какой-то profit, многие нет.
Какие меры предприняли
Изначально у нас было две команды разного профиля разработки, у каждой был собственный Scrum c блэкджеком и Scrum-desk. Но так как у нас всегда, и сейчас, есть просадки с менеджментом (я фактически один), то у меня не хватало времени на организацию процессов по планированию/ведению/демонстрации на две команды. По этой причине нами было принято решение объединить команды в одну.
Да, — это помогло выиграть некоторое время, но, Нет, — это не дало положительных результатов. Такое продлилось четыре sprint'a, но так как у команд был совершенно разный профиль разработки, разработчикам было совершенно незачем работать вместе.
Со временем работников становилось больше и становилось больше направлений разработки, появлялись то мобилки, то еще что-нибудь. Как я говорил в пункте с объединением команд, людям совсем не за чем работать вместе, если между ними нет прямой связи в разработке проектов. Соответственно, мы разделили команды по разным направлениям. Да, — это дало продуктивный результат для каждой отдельной команды, но каждая команда, сожрала уйму времени менеджера.
Попробовали различные вариации:
В итоге мы остановились на двухнедельных sprint’ах.
Отказались от ватманов, некрасиво смотрится, разработчикам не нравилось это на обоях.
И решает проблему с отрыванием скотча от бумаги. Но, появилась новая проблема — клей на доске. Также пропала burn-down диаграмма в бумажном виде, так как я стал выводить изображение диаграммы на телевизор в кабинете разработчиков.
Следующий этап: стали писать ежедневные таблицы митингов маркерами на доске:
Таблица содержит: число, столбец сжигания задач не из плана, столбец сжигания задач из плана.
Отказались от продуктов MS, перешли в облачное решение google doc. Также был модернизирована Scrum/Sprint -list. Основное отличие от первого варианта листа: задачи разбиты по каждому работнику и они декомпозированы. (ссылка есть в источниках и ссылках)
Стали вести burn-down диаграммы в google таблицах. С течением времени стали добавляться еще значения в таблицу:
Так как при длительном sprint'e у нас появилась тенденция: не укладываться в sprint (запасы пробовали брать, ни к чему хорошему не привело), ввели новое значение — off-plan, которое показывает график с учетом сжигания не запланированных задач.
Далее пошли еще дальше, ввели еще три значения: Real, Off-plan (error) и Off-plan (extra):
Графики отражают:
Удобное решение, можно работать всем одновременно:
Сейчас у нас гораздо больше слайдов, чем было вначале, но получается более четкая презентация и занимает меньше времени.
Поставили плагин для Redmine, его название — Backlog’s. Дает возможность организовывать работу с backlog’ом продукта и sprint’ами через Redmine:
У данного плагина есть электронная доска задач, которая полностью повторяет функционал той, которая у нас была вначале в реальном виде. Все столбцы подхватываются из Redmine, — это значение статуса задачи. Sprint замещает значение и функционал «версии» в Redmine.
Достаточно удобный плагин, мы его используем и сейчас.
Отражает суммарно сожженные story-points каждого работника за все sprint'ы. Стимулирует работников работать более продуктивно, каждый работник способен брать на sprint определенное количество story-ponts. Видя, что другие ребята работают продуктивнее него, работник предпринимает попытки, чтобы достигнуть более хороших результатов. У нас среднее количество story-points на двухнедельный sprint — это семь.
В первую очередь все нововведения направлены на улучшение производительности и на сокращение времени на планирование и сопутствующие работы. Переход в облако и на полностью электронную работу значительно сократил время на работы по планированию.
На данный момент существует проблема: количество работников велико для одного менеджера и мы не успеваем проводить все работы по планированию. Что делать с этим мы знаем. Пытаемся действовать по наработанной схеме.
В данный момент у нас, опять, активно внедряется 1С Битрикс, руководство хочет чтобы все работники были в одной системе. Планируем изучать новый инструментарий и смотреть, как нашу работу можно перенести в CRM. На данный момент есть кое-что на примете: доска для Битрикса — scrumban.ru. (ссылка есть в источниках и ссылках)
Есть планы при помощи MS Project применять метод освоенного объема в параллели ко всей нашей системе.
В заключении хочу повториться, что это не в коем случае не гайд, а лишь опыт одной небольшой фирмы. Надеюсь что после прочтения статьи у вас останутся лишь позитивные мысли и вы вынесете для себя нечто полезное, а может быть и опыт, как делать нельзя.
Источники и ссылки:
Книга: «Scrum и XP: заметки с передовой» [1]
Agile-манифест [2]
Документ с основными мероприятиями [3]
Scrum-list (первый ) [4]
Ссылка на магазин, где купить Poker planning [5]
Scrum-list по прошествию времени [6]
Доска для Битрикса [7]
Автор: 1aZzy
Источник [8]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/scrum/223196
Ссылки в тексте:
[1] Книга: «Scrum и XP: заметки с передовой»: http://scrum.org.ua/wp-content/uploads/2008/12/scrum_xp-from-the-trenches-rus-final.pdf
[2] Agile-манифест: http://agilemanifesto.org/iso/ru/manifesto.html
[3] Документ с основными мероприятиями: https://docs.google.com/document/d/1yrA7__IYtstd9AccF9iF6VfTWADEDiDrzBvZpFuszkg/edit
[4] Scrum-list (первый ): https://docs.google.com/document/d/1uJVeDjRIGT7a9JdhlJn1qavkKiQJ_NBD1wkFkkVViOA/edit
[5] Ссылка на магазин, где купить Poker planning: http://www.planningpoker.ru/#buy
[6] Scrum-list по прошествию времени: https://docs.google.com/document/d/1U9K6T9jKlhEgXpul433OUpB-zpYyKeNzAThmt8_a7PM/edit
[7] Доска для Битрикса: http://scrumban.ru/
[8] Источник: https://habrahabr.ru/post/318002/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.