Как мы достигли идиллии, работая без менеджеров. Часть 2. Тайная комната
Привет тебе, дорогой читатель! В предыдущей статье я рассказывал о том, как 28 разработчиков смогли выстроить рабочий процесс, в котором нет роли менеджера. Мы продолжаем с удовольствием работать и выпускать сложные фичи одну за одной. Скоро нам предстоят бессонные ночи перед выпуском релиза. И затем самый приятный этап — технический спринт и проведение ретро релиза, а также мероприятия по планированию следующего релиза.
Сегодня я расскажу об активностях, которые обеспечивают максимальную прозрачность рабочего процесса и позволяют не выпадать разработчикам из событий, происходящих в целом компании и в других командах в частности. Хотите выстроить качественные процессы и работать с удовольствием? Добро пожаловать под кат!
Перед тем, как продолжить делиться опытом организации процесса разработки, я хочу уточнить пару вопросов относительно специфики компании. Бизнес-структура компании подразумевает разработку продукта in-house и последующую продажу решения клиентам. В компании есть маркетинговый отдел, отдел сбыта и другие подразделения помимо отдела разработки. Это во многом определяет возможность взаимодействия напрямую с продуктовым аналитиком, который и является поставщиком основных требований к продукту. В обычном смысле, у нас нет клиента-заказчика со стороны. Мы сами вырабатываем требования, сами разрабатываем и сами продаем. Традиционная продуктовая компания.
Тем не менее, я настаиваю на том, что опыт организации процессов между командами разработки и разработчиками внутри команд может быть использован как пример для выстраивания процессов в Вашей компании, будь она разработчиком аутсорсных решений или продуктовой компанией. Классический скрам «по книжкам», как показывает опыт, не применим в реалиях разработки реальных продуктов, и именно поэтому специфика продукта определяет специфику процессов.
Напомню, в нашей компании работает на данный момент 28 разработчиков. То, что применимо для 7 команд (по четыре разработчика в команде) может стать нецелесообразным при работе 15 команд и наоборот. В то же время, и разработка качественной архитектуры кодовой базы, и выстраивание качественных процессов подразумевает свободу масштабирования без больших затрат. Кроме этого, в большинстве компаний отдел разработки одного направления большого продукта состоит как раз из 5–7 команд (20–30 человек). Такой отдел, как правило, имеет свободу принятия независимых архитектурных решений, свободу организации внутренних взаимодействий и выстраивания процессов.
Renga Structure — cистема для проектирования конструктивной части зданий/сооружений. Программа для инженеров-конструкторов и проектировщиков по созданию информационной модели здания или сооружения и получению чертежей марок КР/КЖ/КЖИ/КМ/АС.
Семейство продуктов Renga предназначено для проектирования по технологии BIM. Высокая производительность систем позволяет работать с большими проектами без видимого снижения качества работы с 3D-моделью:
Объектное проектирование
Создание в Renga 3D-модели здания/сооружения инструментами объектного проектирования (стена, колонна, окно и т.д.)
Коллективная работа
Обмен, хранение и управление данными осуществляется с помощью BIM-Server Pilot.
Взаимодействие со сметными системами.
Интеграция Renga посредством API со сметными системами 1С-смета и ABC-смета для взаимодействия проектного и сметного отделов.
Обмен данными
Renga позволяет обмениваться данными с другими системами через различные форматы (.ifc, .dwg, .dxf, .obj, .dae, .stl, .3ds, .lwo и .csv).
Автоматизация получения спецификаций и ведомостей
В Renga реализована функция получения отчетов для формирования спецификаций, ведомостей и экспликаций.
Автоматизация получения чертежей
По данным 3D-модели автоматически получаются виды (фасады, разрезы и планы) и размещаются на чертежах в заданных масштабах.
Итак, 5–7 команд, разработка собственного продукта. Как же выстроить процесс без участия менеджера? В первой части статьи я уже рассказал о таких активностях, как груминг, плнирование и ретро команд. Далее речь пойдет об активностях, позволяющих синхронизировать работу нескольких команд и двигаться в одном направлении.
Пример проекта в Renga Structure
Синхронизация команд
Длина спринта у нас — десять рабочих дней. Между спринтами есть два дня для проведения демо, ретро и планирования. Если между спринтами есть два дня на ретро, демо и планирование — это не значит, что в эти два дня не пишется код. Это значит, что в эти дни активности идут с бОльшим приоритетом, чем написание кода. Эти два дня являются хорошим буфером для амортизации недооценок/переоценок по спринту. Синхронизация команд — активность, не привязанная к графику спринтов. Такая синхронизация проводится каждую пятницу в одно и то же время после обеда. На синхронизации присутствуют все разработчики, тестировщики и продуктовые аналитики. В общем смысле, синхронизация команд — это стендап, где от каждой команды выступает один разработчик и рассказывает, что командой было сделано, какие участки кода были затронуты и как это может повлиять на другие команды.
Часто в компаниях синхронизация проводится в виде собрания тимлидов команд. У этого подхода есть минус, который я подробно обсуждал в предыдущей статье: один человек может забыть, не обратить внимание на множество деталей, которые важны для других. Таким образом, синхронизация тимлидов экономит время команд, но существенно уступает качеству коммуникаций. Подразумевается, что после такого собрания тимлид будет рассказывать каждый своей команде о прогрессе других команд, что опять же потратит время каждой команды. Здесь появляется минус «глухого телефона» при передаче знаний от тимлида команде. Таким образом, команда остается как бы «в стороне» от работы других команд, общаясь только посредством тимлида. Как результат, падает заинтересованность, увеличивается разрыв в понимании общего движения разработки всего отдела. Экономия времени команды никак не может покрывать минусы от отстраненности от общего направления разработки и общения между разработчиками.
После каждого выступления команды, как правило, задаются уточняющие вопросы от любого из присутствующих. Если кто-то понимает, что ответ на вопрос перерастает в отстраненную продолжительную дискуссию, то он/она может прервать диалог и предложить перенести его на другое время. Таким образом, синхронизация семи команд длится не более сорока минут и позволяет всем разработчикам оставаться в струе развития продукта другими командами.
Другой важный аспект, который обсуждается на синхронизации — актуализация сроков разработки. Как правило, раз в две недели команды публично оценивают свои шансы на «успеть вовремя к релизу». В процессе обсуждения становится понятно, какая команда не успевает, а какая выполняет задачи в срок. Кроме этого, благодаря присутствию продуктовых аналитиков, можно изменить приоритеты разработки. Например, одна команда не успевает выпустить функциональность к релизу. Другая команда также не успевает, но аналитик понимает, что бизнес-значимость (business-value) работы первой команды выше, поэтому вторая команда откладывает функциональность, запланированную к релизу и помогает первой команде закончить работу в срок. При этом важно, что каждый член команды слышит рассуждения и аргументы, которые привели к такому решению. Я уверен, что в большинстве компаний, где такое решение было бы принято на синхронизации тимлидов, у команд возникло бы явное непонимание, почему чьи-то фичи важнее, а чьи-то — нет. Здесь же все вопросы можно задать и непонятных моментов остаться не должно.
Результатом проведения таких синхронизаций является осознание и принятие каждым участником процесса разработки актуальных сроков и приоритетов разработки. Также каждый участник понимает актуальные изменения в различных частях кода приложения, что позволяет избежать непонимания при мержах, конфликтах версий и других неожиданных изменениях при работе приложения.
Пример проекта в Renga Architecture
Демо
Другой активностью, позволяющей оставаться в курсе изменений в продукте уже не на уровне кода, а на уровне пользователя — демо. Демо проводится на следующий день после завершения спринта. Демо организуется продуктовыми аналитиками для всех стейкхолдеров продукта — инвесторов, маркетингового отдела, руководителей компании и внутренних отделов разработки. Ведущие демо — аналитики команд, каждый из которых представляет разработанную, протестированную и слитую в основную ветку разработки функциональность продукта. Каждый сценарий демо проверяется накануне показа на соответствие требованиям (Definition of done). Важно понимать, на демо никогда не показываются незаконченные фичи или сценарии. Подразумевается, что любой сценарий, показанный на демо, может быть с хорошей вероятностью использован конечным пользователем продукта без каких-либо ошибок.
В процессе показа сценария, как правило, разъясняется основная мотивация к разработке этой фичи, показываются основные пользовательские сценарии работы. После завершения сценария, все присутствующие могут задавать вопросы. Как правило, стейкхолдеры уточняют тонкости работы фичи, маркетинговый отдел — применимость фичи для клиента и какие-то особенности внедрения, высказывают пожелания по улучшению. Уже не раз в процессе показа, от отдела маркетинга появлялись запросы на доработку фичи, которые добавлялись в план разработки на следующие спринты.
Результатом проведения демо является публикация очередного приращения функционала продукта для всех заинтересованных лиц. Благодаря присутствию на демо разработчиков, тестировщиков, сотрудников отдела маркетинга, проясняется множество моментов, происходит обмен актуальной информацией о сценариях работы продукта. Такая прозрачность знаний о продукте минимизирует расхождения в ожиданиях от той или иной функциональности и позволяет оперативно реагировать на любые предложения.
Ретро релиза
Одной из самых долгих и трудозатратных активностей является ретро релиза. Эта активность длится около 5 часов с перерывом на обед. Ведущим ретро может стать любой желающий, но, как правило, проводится тимлидами-евангелистами. Ретро релиза разбито на несколько смысловых блоков-заданий, выполняемых каждой командой. По результатам каждого задания появляется определенный артефакт, например, карта успеха, карта разочарования, карта полезных и мешающих моментов в течение релиза. Каждый такой артефакт презентуется, как правило, разными членами команды. По результату ретро каждая команда берет в работу позитивные практики работы других команд и старается найти решение негативных моментов в методах работы других команд. Каждое ретро релиза призвано повысить прозрачность практик, применяемых внутри каждой команды, и помочь командам обсуждать различные подходы решения проблем, возникающих в процессе разработки.
Пожалуй, ретро релиза — это самое интересное и полезное мероприятие из всех активностей, применяемых в компании. В короткий срок все команды обмениваются позитивным и негативным опытом, помогают друг другу найти решения задач организации рабочего процесса, оценок задач, составления описаний для фич.
Тайная комната
Тайная комната — это наш демо-зал, в котором проводятся все описанные активности. Здесь есть все, что необходимо — флип-чарты, столы по количеству команд, доски и проектор. В нашем отделе разработки много конструктивных отсылок к Гарри Поттеру. У нас есть Sirius, Ravenclaw и даже Order of Phoenix, но об этом в следующих статьях.
В нашем отделе разработки много отсылок к Гарри Поттеру
Вместо заключения
В комментариях к предыдущей статье была высказана идея, что в таком процессе «без менеджеров» на собрания уходит слишком много времени разработчиков. Я позволил себе оценить отвлечения на активности.
По чистому времени выходит около 0.4 часа на стендапы, 5 часов на планирование, 2 часа на ретро, 2 часа на демо. 28×0.4×10 + 5×28 + 2×28 + 2×28= 364 человеко-часа за 12 дней на 28 человек или 1 час в день на одного человека. Я не учел активности вроде code-review, архитектурных обсуждений, потому что считаю их неотделимой частью процесса разработки.
Поделитесь, сколько времени интегрально у Вас (или Ваших команд) уходит на активности помимо разработки? На мой взгляд, 1 час в день «на поговорить» — очень небольшая плата за распространение знаний, рефлексию команд и повышение прозрачности.
Анатолий Осокин, ведущий инженер-программист, Renga Software.
