Эта статья мотивирована желанием выжать разработчика дать возможность разработчикам реализовать свой потенциал максимально и во многом опирается на книгу "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.
Комментарии (19)
funca
23.06.2023 16:28Есть кусок работы, есть достаточно автономная команда и нужен результат. Кажется в советское время это называлось бригадный подряд.
delicious
23.06.2023 16:28+2поздравляю, вы изобрели
эстафетуканбан
Arvardan Автор
23.06.2023 16:28Различий, на самом деле, больше чем схожестей.
В эстафете:Разработка циклами (итерациями)
Ограниченное количество заданий в итерации
Перерывы между итерациями
Поощряется работа нескольких человек над одним заданием
Возможно есть еще два-три различия, но сейчас не вспомню.
В общем канбан ориентируется на задачи, а эстафета на команду
reinmaker1990
23.06.2023 16:28Работа циклами, ограничение заданий в эстафете это вот как раз про канбан, так же вы выпускаете из вида что команда может быть мультиплатформенной, например ребята которые пишут мобилку на swif и kotlin, а так же уважаемые господа которые делают десктоп на. NET, тут мы сразу утыкаетмя в то что подхватить задачу если она сложнее того что уже можно автоматизировать и получить от chatgpt - крайне проблематично.
Вы упомянули что дедлайн как бы есть, но для команды его нет, это тема как мне кажется до конца не расурата, имхо дедлайн будет всегда и будет он висеть дамокловым мечом над командой, но при разных ситуация он может рубить головы, а может подталкивать делать свою систему лучше и более прогназируемой.
nkopylov
23.06.2023 16:28Не вижу связи между спринтами и отсутствием командной работы.
Тот же скрам наоборот поощряет коллаборацию через одну цель спринта, дальше уже зависит от команды как готовить ежедневную работу. Можно и без одиночных задач. Можно и без ревью.
Можно с активным парным программированием и даже моббингом, можно через one piece flow всей командой обрабатывать бэклог спринта по одному элементу до полной готовности.
Hokum
23.06.2023 16:28Как плюс подхода преподносится, что «самое слабое звено» будет видно сразу же и порицается всеми. На мой взгляд - это минус. Команда, если это команда. И так знает кто что делает, а кто ничего не делает. Но и выгонять такого человека для команды не выгодно, так как на его месте обязательно окажется кто-то другой. Но в то же время, такому изгою будет нет-нет да вспоминать, что из-за него они остались без выходного. Но это не так!
Я не верю в бизнес, который так легко даст команде явно ничего не делать целый день, а то и два. Собственно в том же скраме, объем задач подбирается из скорости команды, так чтобы не было простоя и, в идеале, всё успели сделать. Так что и в вашем примере всё будет точно так же. Задачи будут браться в эстафету так, чтобы у команды не осталось выходного.
И тут, как раз самый медленный сотрудник и мог бы обеспечить остальным выходной. Все всё сделали и отревьюили, осталась задача самого медленного. Вот пока он её делает, все остальные могут отдыхать. И вот он дополнительный выходной, но как только менеджер увидит простой остальных, то в следующий спринт/эстафету задач будет больше.
Так что в случае со спринтами, любыми спринтами, команде выгоднее работать в несколько замедленном темпе, чтобы спринт/эстафету закрывать ровно в срок и переодически не успевать, чтобы у менеджера было ощущение, что команда загружена на 100%.
Для меня, как линейного сотрудника, самым комфортным и эффективным вариантом был как раз канбан. Причем, так как наш продукт был частью большего продукта, то у нас бвл интервал раз в две недели когда мы «отдавали» всё, что было сделано на интеграцию с другими командами. Собственно можно было бы и отдавать после каждого мержа в мастер, так как он у нас был стабильным и в него изменения попадали после всех тестов, но так было проще координировать изменения от всех команд.
Мы не тратили время на груминги и оценку задач. По задачам у нас был один критерий - можно её сделать за две недели или точно нет. Если нет, то дробили на части и декомпозиция - это была отдельная задача, которая бралась в работу.
Ну и в целом, ежедневные синки вполне себе показывают кто хорошо работает, а кто не очень. Команда же понимает какие задачи у кого и потом на ревью видит, что в итоге получилось и может сопоставить затраченные усилия и результат. Так что дополнительно показывать аутсайдера нет необходимости. Да и менеджер будет видеть по статусам, что человек работает не очень эффективно. Когда из синка в синк, человек говорит, что то тут проблема, то там, а у остальных такого нет, то даже в код смотреть не надо, чтобы понять, что или компетенции не хватает и надо помочь в развитии, или мотивация упала, а может ещё какие-то причины.
Arvardan Автор
23.06.2023 16:28ежедневные синки вполне себе показывают кто хорошо работает, а кто не очень
Не могу согласится.
Пример из жизни. Поставлена задача сделать фильтр на сигналы, чтобы высокие и низкие частоты были распознаны как аномалии. Один человек ставит if сверху и if снизу и закрывает таск в тот же день. Другой человек в течении недели поверхностно изучает теорию сигналов и делает фильтр через какую-то формулу.
Второй подход труднее, вызывает проблемы, но решает задачу на всегда. Первый подход простой, но через две недели нужно будет фиксить так как по выходным разброс сигнала меньше и аномалии не пересекают границу заданную if'ом.Hokum
23.06.2023 16:28Всё как обычно "зависит от". :) Но в приведенном вами примере, в случае команды, когда один пошел изучать теорию сигналов и сказал об этом на синке, то другой мог предложить поставить if-ы. И в итоге обсудить как данную задачу лучше решить в данный момент. Далеко не всегда фундаментальное трудоемкое решение нужно. Иногда можно обойтись и парой if-ов. А если потребность в этом есть, то и вопросов к нему не будет.
Опять же, команда (да и руководитель) видит и может оценить, что человек говорит на синке и что в итоге он сделал. В случае с фильтром - как много членов команды смогли бы такое сделать без изучения теории? Похожая ситуация может возникнуть и при использовании новой для человека библиотеки/фреймворка. Это нормально.
А если область сложная и подобные задачи встречаются часто, то сотруднику надо дать время и оплатить прохождение специальных курсов, чтобы ему было проще работать, ну если все остальные знакомы с необходимой базой или всех отправить. Тут зависит от команды и менеджера. Где-то всех отправить, где-то одного-двух, кому больше всех интересно, а он потом они обучат остальную команду по ходу работы.
На синке человек не просто говорит из дня в день "делаю таск №342", а говорит, что конкретно он делает, с какими проблемами столкнулся, как думает их решить или что уже сделал для их решения.
M1straL
23.06.2023 16:28Жаль, у меня нет рейтинга поставить вам плюс.
Важные мысли я почерпнул и записал
Nick_Maverick
23.06.2023 16:28Хм, надо попробовать. В обычный спринт к задачам на разработку даём задачу на ревью и даём ответственных. Возможно допилить конфиг джиры на автомат создание сабтаски при попадании в кодревью (Создание пулл)
Hokum
23.06.2023 16:28+1Это совсем не обязательно отдельная задача, достаточно просто статуса задачи. Таскать на ревью, таскать на тестирование - хорошо для KPI - смотрите как много тасок делает команда, но забивает доску. А после ревью создавать сабтаску на исправление, а потом на ревью исправлений? И сколько задач надо на ревью, если ревьювеоров больше одно - по количеству ревьюверов?
Плюс одну таску по статусам туда-сюда двигать замучаешься, а тут жонглировать большим количеством. Вы же это хотите ввести не просто так, а чтобы понимать сколько времени тратится на тот или иной процесс. Поэтом надо фиксировать когда задача находится в активной фазе - разработка/ревью, а когда в ожидании ревью или исправлении замечаний.
Но для выявления узких мест достаточно мониторить в каком статусе и сколько задача провисела, джира точно умеет такую аналитику делать, у нас её строили. А в случае оценки задач, можно накидывать сторипоинты на оцепенею задачу. В среднем 50% от длительности задачи можно накинуть на ревью. Если в среднем приходится больше времени тратить, то значит что-то не так с процессом разработки и проблемы выявляются слишком поздно.
Arvardan Автор
23.06.2023 16:28+1Канбан пробовали? Тут товарищи заметили схожести, а к нему есть уже board в Jira.
M1straL
Мне видится здесь сразу 2 проблемы:
Если нет дедлайна, то 90% особей человека прокрастинируют. Это факт.
В некоторых конторах я сталкивался с тем, что люди брали задания попроще, а потом презентовали это как выполнение KPI. В вашей системе люди, которые будут брать сложные задания всегда будут оказываться последними в эстафете.
Arvardan Автор
Расчет на peer pressure. То есть, человек не знает работают ли его коллеги над своими заданиями, а это значит что могут и работать. Это в свою очередь должно вызвать чувство, либо понимание, того, что, как только кто-то из коллег закончит, на него могут обратить внимание. Это чувство будет нарастать по мере завершения заданий коллегами. Если половина уже всё, а он даже не начал, то коллеги это точно поймут.
Касаемо сложности заданий не могу ничего сказать. Вроде у всех тот же потолок по пунктам сложности. Если задание было сложнее чем говорят пункты, тогда его можно разбить на две части и отдать вторую тому кто уже закончил. Либо все без работы будут ждать одного человека, но тогда выходной наступит позже. В некоторых ситуациях, желание получить дополнительные выходные в четверг и пятницу будут достаточным стимулом чтобы закрыть эстафету к среде.
barloc
Если нет дедлайна, то 90% особей человека прокрастинируют. Это факт.
Мне кажется, что это касается не такой большой группы людей и лучше от них избавляться в команде. Команда же несет коллективную ответственность - один прокрастинирует, значит остальные пашут за него.
Меня, например, не поджимает дедлайн какой-то задачи - меня поджимает количество задач за ней. Если начать работать медленно, этот снежный ком будет расти и расти и вкалывать для растаскивания придется ух как.
M1straL
При условии, что у вас ультразамотивированные профессиональные ребята в вакууме.
В реальной жизни у каждого свои мотиваторы.
Почти невозможно собрать команду, которая не обращает внимание на работу других отделов.
Почти не бывает случаев, когда косякнул отдел А, из-за кторого всем пришлось перерабатывать, а потом отдел А разогнали, чтобы найти более компетентных людей.
А вот это все капает, капает, капает каждый день.
Если же вы смотрите на это через призму - я делаю то, что говорят, то вы не мотивированный человек.
barloc
Не вижу противоречий :) Если косячат рядом - это не значит, что вам можно делать так же. Это просто непрофессионально, на мой взгляд.
Решений может быть несколько - например, предложить помощь соседней команде :)
dph
Если у вас нужно давление для борьбы с прокрастинацией - то у вас в компании более существенные проблемы, нежели процессные и нужно всерьез работать над культурой и наймом. Или, лучше, поменять компанию.
Если в компании KPI на разработчиков на число задач - то в компании очень большие проблемы с вменяемостью менеджмента, так что, опять-таки, лучше менять компанию.