Из хаоса в Scrum. Опыт и результаты первых шести месяцев

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

Что было перед стартом

Научно-исследовательский департамент. Два отдела занимаются наукоёмкими изысканиями в части оптимизации алгоритмов разного рода распознавания и биометрии — голоса, лиц, речи, — а также синтеза речи. И заворачивания всего этого в SDK (Software Development Kit) для дальнейшего использования в разработке конечных продуктов другими подразделениями. Мой отдел — сборная из группы наукоёмкого тестирования и «вспомогательного персонала» (так это воспринималось в НИД) — технический писатель, аналитик, ассистент. Вообще исходно планировалось добавить в него и программистов, всё это сделать «ресурсным пулом» для руководителей проектов, а я предполагался ресурсным менеджером.

Особенности процессов на начало года

Тестирование было отделено от разработки. А так как процесс управления требованиями тоже практически отсутствовал, так что тестирование строилось скорее на догадках и ответах разработчиков, чем на спецификациях и ясных рамках. В итоге все SDK тестировались непредсказуемо и по времени и по качеству.
Не было ясного роадмэпа — плана развития продукта. Не было даже бэклога. Были только задачи на здесь и сейчас.
Управление осуществляется через тимлида — на нём замыкаются все потоки информации и от него исходят задачи.
Команд как таковых нет. Были группы людей, собранные для работы над конкретными SDK, но эти группы легко перераспределялись. Командами их нельзя было назвать и потому что у них не было осознания общей цели. Люди не всегда были в курсе того, чем занят сосед.

Всё перечисленное уже настораживало и создавало ощущение какого-то сюрреализма. Вроде только глухой нынче не слышал про Agile и самоорганизующиеся команды (хотя глухой наверняка читал). Да бог с ними, с Agile-командами, хотя бы просто команды и непрерывное тестирование ведь уже стали просто стандартом de facto. Может я чего-то не понимаю? Может в «наукоёмкой разработке» работают иные принципы и требуется особенный подход? Я, к слову, часто слышал тут этот аргумент. Но я его слышу в любой предметной области и почти в любой компании.

С согласия руководителей департамента и одного из отделов, мы начали работу по скраму в одной из команд. Не было какой-то определённой цели от руководства в этом переходе. У директора было лишь ощущение, что да, сейчас процесс разработки какой-то не очень и надо бы что-то поменять. А для меня, как для нового в компании человека, в первую очередь надо было выяснить, какие ещё подводные камни мешают наладить нормальный процесс. И скрам в плане выявления препятствий очень удобный фреймворк.

«Let’s get it started, in here …»

Команда разработки в 6 человек + скрам мастер (ваш покорный слуга) + владелец продукта (руководитель отдела). Очень быстро выяснилось, что перечисленные выше проблемы (которые «особенности процессов») — очень небольшая такая верхушка айсберга.
Начиная от того, что стабильной команды всё ещё нет — люди задействованы в разных проектах и занимаются не связанными между собой задачами (потому что некому больше). Заканчивая отсутствием управления конфигурациями, то есть все стенды и среды настраиваются вручную. Каждый раз как в первый раз. А ещё техдолг по архитектуре, тестам и коду размером с эмпайр-стэйт-билдинг, так что внесение любого небольшого изменение легко может занять больше двух недель.

Довольно быстро команду удалось таки зафиксировать и оградить от вытягивания людей. С бэклогом пришлось повозиться, но к 4-му спринту мы переехали в новый Jira-проект в котором стало можно работать без боли.

В команде появился аналитик, но так как это был первый аналитик в департаменте, за него тоже пришлось биться. Потому что «тут надо ТЗ написать для проекта одного, по которому уже срок пробит, но у нас же есть теперь в НИДе аналитик, пусть напишет».

Но главное — люди начали общаться между собой. И очень продуктивно, надо сказать. Группа людей на удивление быстро стала действительно командой, несмотря на то, что половина из них пришла в компанию недавно, а кто-то вообще только что нанят. И все пол года «скрам-эксперимента» можно охарактеризовать фразой с одной из ранних рестроспектив:

☺ Понравилось:
• Мы работаем даже несмотря на серьезные организационные проблемы

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

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

Что вызывало путаницу — это разница между ревью и ретро. Потому что показывать было нечего и некому — трудно получить инкремент продукта за две недели, когда полное тестирование занимает три (ввиду техдолга). Да и как показывать SDK тоже сходу не придумали.

Однако со временем и эти две регулярные встречи устаканились и обрели свою ценность.

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

На чём остановились

Да, в общем-то не остановились.

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

Главное — команда сама видит ценность в использовании скрам-подхода и не собирается отказываться от практик и активностей. Последние два спринта я наблюдаю за ними со стороны и горжусь. Ими.

Что можно выделить из значительных изменений за эти пол года:

в первую очередь это конечно формирование и сплочение команды. Удивительные даже немножко результаты для полугода работы почти с нуля;
у людей начала формироваться общая картина по продукту и его развитию. Появился обмен информацией и не только у разработчиков с разработчиками. Это сказалось, в частности, на быстром развитии новичков;
релиз занял 4 полных спринта (2 месяца). Выглядит не очень, но стоит иметь ввиду, что предыдущий занял шесть месяцев. В а ходе подготовки этого мы ещё изрядно погрызли техдолг по тестовому фреймворку;
зарождается управление требованиями и маппинг их на тесты, а также новая архитектура;
тестирование и планирование стали частью процесса разработки, а не отдельными фазами;
улучшились инструменты — новое пространство в Jira с удобными инструментами планирования спринтов, скрам-доска, а также удалось выбить некоторый платный инструментарий для программистов.

Некоторые изменения коснулись всего департамента:

управление требованиями начало проникать во все команды. По крайней мере начался поиск аналитиков;
тестировщики распределены по команам разработки;
ну и вообще более-менее зафиксировались команды;
в разных командах начали практиковать разные элементы скрама — дэйли стендапы, ретроспективы, планирование, — хотя на полноценный скрам переходить люди всё ещё опасаются (видимо, читают хабр);
наняли первого системного инженера, и начала зарождаться внутренняя централизованная инфраструктура (Ansible, Nexus, GitLab, вот это всё… да, раньше не было или было на уровне отдельных команд).

Персональные результаты:

здорово устал и почти выгорел — на протяжении полугода мозг почти непрерывно думал о работе и рабочих проблемах. Тут и пробуждения в 5 утра от размышлений, и мысли об устранении препятствий для команды в процессе прослушивания концерта..
и это в параллели с развитием группы тестирования как Community of Practices, наймом кучи новых людей в НИД аналитики, тестировщики, системный инженер и управлением отделом;
но результаты впечатляют, конечно, есть чем гордиться. Как ни крути, это моя первая «трансформация» на уровне департамента, а не отдельной команды или отдела, причём без полномочий на уровне департамента и практически без поддержки со стороны руководства;
хотя несколько напрягает неопределённость нового года.

Вот такие получились итоги года в профессиональном плане.