Эта статья мотивирована желанием выжать разработчика дать возможность разработчикам реализовать свой потенциал максимально и во многом опирается на книгу "Team Topologies" (Matthew Skelton and Manuel Pais).
Я не буду цитировать книги, а её содержание не обязательно будет покрываться с моим пониманием прочитанного материла, тем более что я её пока не дочитал.
Моей задачей в этой статье будет представить свое виденье существующих процессов и циклов разработки, их недостатки, а так же альтернативный подход к ним. Итак начнем
Спринт
У нас есть backlog с заданиями. Задания имеют некоторый вес - пункты либо время. Ограничиваем максимальный вес заданий на человека, указываем время выполнения - обычно это две недели и получаем спринт, а вместе с ним индивидуальную реализацию заданий, непониманием что делать с code review и кому и когда этим заняться, низким качеством документации и тестов.
Это не так, скажете вы - процесс можно наладить так что каждый будет знать когда и что делать, а стандарты документации и тестов можно забить где-то в документах и не давать approve пока задание не соответствует этим стандартам.
Если именно так вы и хотите сказать, то вы будете правы. А может и не будете. Я не знаю.
Статистик нету, а если и есть то кто знает что они реально отображают. Общепринятые практики вроде есть, но каждый отдельный проект, кажется, реализует их по своему. Разные FAANGи падают, а фирмы с двадцати человек продаются за миллиарды долларов.
Я сменил несколько фирм. Где-то спринты были, где-то нет. Кто-то делал standup каждый день, кто-то раз в неделю.
В целом, если нарисовать ось x - мотивированности членов команды и y - следование project management парадигмам, то я, наверное, в разных моментах, находился в каждой из четвертей этой плоскости и я не помню разницы. Не зависимо от фирм, гор мы никогда не сдвигали. Документация всегда могла быть лучшей (или просто могла бы быть), а тесты что-то покрывали. Задания делались. Бизнес был доволен.
Вы можете подумать зачем же я говорю о тестах и о документации раз статья о спринтах. И при чем тут мотивированность команды? Уже объясняю.
Я не хочу обсуждать как делать хорошую документацию или что значит хорошее покрытие тестами. В этой статье мы примем что существует единственный подход к написанию тестов или документации и наша команда следует этому подходу, при этом сама команда максимально мотивированна. Еще мы примем что несмотря на единственный подход к тестам, документации и т.д. делаем мы это не эффективно. Проблема не в том что мы делаем, а как мы это делаем. Проблема в самих спринтах.
Недостатки Спринта
Книга, которую я вспомнил ранее, здесь не случайно. Один из лучших её элементов - это внимание к Закону Конвея, а именно, наблюдению, что структура любой системы повторяет структуру коммуникации между её авторами.
Например. Если вы хотите сделать микросервисы, не обязательно специально делить проект чтобы раздать отдельные куски разработчикам. Поделите самых разработчиков на группы и ограничьте коммуникацию между группами. В натуральный способ, в условиях ограниченной коммуникации, группы будут вынуждены сделать свою часть проекта так, чтобы дать возможность другим частям проекта с ней взаимодействовать не зная при этом как система реализована внутри. То есть появится API.
Это наблюдение и играет важнейшую роль в оптимальности спринтов. Если коммуникация так сильно влияет на структуру системы, какая система получится если каждый её элемент делается в изоляции от другого? А именно так работают задания в спринтах.
Каждый делает свои задания, другой человек вмешивается только когда нужно сделать review. Сам review делается одним или двумя другими разработчиками, а не всей командой. Зная жизнь, делаются такие review неохотно, в последний день спринта, даже если таски закрыли 3 дня назад. А потом же еще нужно сделать правки. Значит таски переходят в следующий спринт.
Есть еще минимум 2-3 вещи которые происходят в следствии такого процесса. Я думаю вы с ними сталкивались, по этому развивать эту тему не буду.
Другой недостаток - это центральная роль дедлайна, то есть времени. Тут можно подтянуть пирамиду: время - качество - цена, но не будем. Я, честно, сомневаюсь что качество самого кода поменяется если сместить акцент с дедлайнов.
Тут дело в другом. Нету лучшей мотивации, чем внутренняя - присущая самому заданию. То есть, можно конечно сказать: у тебя 2 недели, сделай задание или умри. А можно дать задание человеку, который с удовольствием и интересом будет ковырять задание сам и возможно даже справится быстрее чем за 2 недели. Именно так работают backlog'и (если конечно вам позволяют самому выбрать оттуда задание).
Еще один недостаток - это атрофирование отношений между разработчиками. Возникает это натурально в связи с индивидуальным распределением заданий. У тебя с Васей нету общих целей. Он за свои таски получает по шее, ты - за свои. Если твой таск висит месяц без review, то это "их" problem, но так как коллективно наказывать нельзя, а каждый член команды ведь был занят своими тасками, то problem ничей. Можно развести руки, а через год перейти в другую фирму где ты опять будешь сам на удалёнке точить таски без каких-либо "друзей по работе".
Эстафета
Читая книгу и рефлексируя о своём опыте я думал как же создать другой процесс, который будет служить альтернативой спринту и при возможности исправит некоторые его недостатки. Назвать я этот процесс решил эстафетой, так как это тоже спорт, тоже связан с бегом, но при этом командный. Название может не самое удачное, так как подразумевает некоторую последовательность в выполнении заданий, но это не важно. Что же такое эстафета и как она должна работать.
Главная черта - отсутствие дедлайна. Он то конечно есть, но его не видно.
Реализация предельно проста - разработчики берут задания из backlog'a как и прежде. Работают над заданиями они так же. Нельзя двум человекам седеть над одним заданием, а значит не будем их заставлять. Различия начинаются когда человек закончил свои задания и выставил их на review. Так как самому себе review делать не положено - человек будет без работы, а значит работу ему нужно предоставить. Тут вариантов два: он может забрать не начатое задание коллеги либо начать review законченных заданий. Когда все закончили и все review сделаны, а тесты и документация написаны тогда эстафета заканчивается. Следующая эстафета начнется либо с понедельника либо со среды (в зависимости что ближе), а у разрабов пока заслуженный выходной.
Тут вы заметите что самого продуктивного работника накажут наградят дополнительной работой. Но в спринтах вы же тоже добираете задания, верно? Более того, посмотрите с другой стороны: каждую эстафету кто-то будет последним, это человек которому постоянно нужно будет помогать. Если все время это будет тот же человек, сколько эстафет нужно будет чтобы понять чтобы этот человек не подходит данной команде? А сколько спринтов для этого бы понадобилось?
Заметьте еще, что теперь, не только натурально появилась общая цель - добить эстафету, но и общая награда. Каждый из этих элементов сблизит команду. Не говоря о общем прочтении новой документации и общих review.
Выводы
Эстафета должна преобразить команду. Даже если команда не станет более продуктивной, она должна сплотиться, а значит и разрабатываемая система должна стать более слаженной. Общие цели, как и общие награды будут этому способствовать. Слабые элементы команды будут обнаружены быстрее, а значит перестанут тянуть всю команду в низ, а на их место может прийти кто-то более подходящий. Документация, тесты и code review улучшатся так как теперь их будет читать почти вся команда, а их написание не будет ничейным заданием, так как будут частью целого процесса - by design.
