Комментарии 28
Мне видится здесь сразу 2 проблемы:
Если нет дедлайна, то 90% особей человека прокрастинируют. Это факт.
В некоторых конторах я сталкивался с тем, что люди брали задания попроще, а потом презентовали это как выполнение KPI. В вашей системе люди, которые будут брать сложные задания всегда будут оказываться последними в эстафете.
Расчет на peer pressure. То есть, человек не знает работают ли его коллеги над своими заданиями, а это значит что могут и работать. Это в свою очередь должно вызвать чувство, либо понимание, того, что, как только кто-то из коллег закончит, на него могут обратить внимание. Это чувство будет нарастать по мере завершения заданий коллегами. Если половина уже всё, а он даже не начал, то коллеги это точно поймут.
Касаемо сложности заданий не могу ничего сказать. Вроде у всех тот же потолок по пунктам сложности. Если задание было сложнее чем говорят пункты, тогда его можно разбить на две части и отдать вторую тому кто уже закончил. Либо все без работы будут ждать одного человека, но тогда выходной наступит позже. В некоторых ситуациях, желание получить дополнительные выходные в четверг и пятницу будут достаточным стимулом чтобы закрыть эстафету к среде.
Если нет дедлайна, то 90% особей человека прокрастинируют. Это факт.
Мне кажется, что это касается не такой большой группы людей и лучше от них избавляться в команде. Команда же несет коллективную ответственность - один прокрастинирует, значит остальные пашут за него.
Меня, например, не поджимает дедлайн какой-то задачи - меня поджимает количество задач за ней. Если начать работать медленно, этот снежный ком будет расти и расти и вкалывать для растаскивания придется ух как.
При условии, что у вас ультразамотивированные профессиональные ребята в вакууме.
В реальной жизни у каждого свои мотиваторы.
Почти невозможно собрать команду, которая не обращает внимание на работу других отделов.
Почти не бывает случаев, когда косякнул отдел А, из-за кторого всем пришлось перерабатывать, а потом отдел А разогнали, чтобы найти более компетентных людей.
А вот это все капает, капает, капает каждый день.
Если же вы смотрите на это через призму - я делаю то, что говорят, то вы не мотивированный человек.
Если у вас нужно давление для борьбы с прокрастинацией - то у вас в компании более существенные проблемы, нежели процессные и нужно всерьез работать над культурой и наймом. Или, лучше, поменять компанию.
Если в компании KPI на разработчиков на число задач - то в компании очень большие проблемы с вменяемостью менеджмента, так что, опять-таки, лучше менять компанию.
Есть кусок работы, есть достаточно автономная команда и нужен результат. Кажется в советское время это называлось бригадный подряд.
поздравляю, вы изобрели эстафету канбан
Различий, на самом деле, больше чем схожестей.
В эстафете:
Разработка циклами (итерациями)
Ограниченное количество заданий в итерации
Перерывы между итерациями
Поощряется работа нескольких человек над одним заданием
Возможно есть еще два-три различия, но сейчас не вспомню.
В общем канбан ориентируется на задачи, а эстафета на команду
Это все - канбан :)
Работа циклами, ограничение заданий в эстафете это вот как раз про канбан, так же вы выпускаете из вида что команда может быть мультиплатформенной, например ребята которые пишут мобилку на swif и kotlin, а так же уважаемые господа которые делают десктоп на. NET, тут мы сразу утыкаетмя в то что подхватить задачу если она сложнее того что уже можно автоматизировать и получить от chatgpt - крайне проблематично.
Вы упомянули что дедлайн как бы есть, но для команды его нет, это тема как мне кажется до конца не расурата, имхо дедлайн будет всегда и будет он висеть дамокловым мечом над командой, но при разных ситуация он может рубить головы, а может подталкивать делать свою систему лучше и более прогназируемой.
Не вижу связи между спринтами и отсутствием командной работы.
Тот же скрам наоборот поощряет коллаборацию через одну цель спринта, дальше уже зависит от команды как готовить ежедневную работу. Можно и без одиночных задач. Можно и без ревью.
Можно с активным парным программированием и даже моббингом, можно через one piece flow всей командой обрабатывать бэклог спринта по одному элементу до полной готовности.
Как плюс подхода преподносится, что «самое слабое звено» будет видно сразу же и порицается всеми. На мой взгляд - это минус. Команда, если это команда. И так знает кто что делает, а кто ничего не делает. Но и выгонять такого человека для команды не выгодно, так как на его месте обязательно окажется кто-то другой. Но в то же время, такому изгою будет нет-нет да вспоминать, что из-за него они остались без выходного. Но это не так!
Я не верю в бизнес, который так легко даст команде явно ничего не делать целый день, а то и два. Собственно в том же скраме, объем задач подбирается из скорости команды, так чтобы не было простоя и, в идеале, всё успели сделать. Так что и в вашем примере всё будет точно так же. Задачи будут браться в эстафету так, чтобы у команды не осталось выходного.
И тут, как раз самый медленный сотрудник и мог бы обеспечить остальным выходной. Все всё сделали и отревьюили, осталась задача самого медленного. Вот пока он её делает, все остальные могут отдыхать. И вот он дополнительный выходной, но как только менеджер увидит простой остальных, то в следующий спринт/эстафету задач будет больше.
Так что в случае со спринтами, любыми спринтами, команде выгоднее работать в несколько замедленном темпе, чтобы спринт/эстафету закрывать ровно в срок и переодически не успевать, чтобы у менеджера было ощущение, что команда загружена на 100%.
Для меня, как линейного сотрудника, самым комфортным и эффективным вариантом был как раз канбан. Причем, так как наш продукт был частью большего продукта, то у нас бвл интервал раз в две недели когда мы «отдавали» всё, что было сделано на интеграцию с другими командами. Собственно можно было бы и отдавать после каждого мержа в мастер, так как он у нас был стабильным и в него изменения попадали после всех тестов, но так было проще координировать изменения от всех команд.
Мы не тратили время на груминги и оценку задач. По задачам у нас был один критерий - можно её сделать за две недели или точно нет. Если нет, то дробили на части и декомпозиция - это была отдельная задача, которая бралась в работу.
Ну и в целом, ежедневные синки вполне себе показывают кто хорошо работает, а кто не очень. Команда же понимает какие задачи у кого и потом на ревью видит, что в итоге получилось и может сопоставить затраченные усилия и результат. Так что дополнительно показывать аутсайдера нет необходимости. Да и менеджер будет видеть по статусам, что человек работает не очень эффективно. Когда из синка в синк, человек говорит, что то тут проблема, то там, а у остальных такого нет, то даже в код смотреть не надо, чтобы понять, что или компетенции не хватает и надо помочь в развитии, или мотивация упала, а может ещё какие-то причины.
ежедневные синки вполне себе показывают кто хорошо работает, а кто не очень
Не могу согласится.
Пример из жизни. Поставлена задача сделать фильтр на сигналы, чтобы высокие и низкие частоты были распознаны как аномалии. Один человек ставит if сверху и if снизу и закрывает таск в тот же день. Другой человек в течении недели поверхностно изучает теорию сигналов и делает фильтр через какую-то формулу.
Второй подход труднее, вызывает проблемы, но решает задачу на всегда. Первый подход простой, но через две недели нужно будет фиксить так как по выходным разброс сигнала меньше и аномалии не пересекают границу заданную if'ом.
Всё как обычно "зависит от". :) Но в приведенном вами примере, в случае команды, когда один пошел изучать теорию сигналов и сказал об этом на синке, то другой мог предложить поставить if-ы. И в итоге обсудить как данную задачу лучше решить в данный момент. Далеко не всегда фундаментальное трудоемкое решение нужно. Иногда можно обойтись и парой if-ов. А если потребность в этом есть, то и вопросов к нему не будет.
Опять же, команда (да и руководитель) видит и может оценить, что человек говорит на синке и что в итоге он сделал. В случае с фильтром - как много членов команды смогли бы такое сделать без изучения теории? Похожая ситуация может возникнуть и при использовании новой для человека библиотеки/фреймворка. Это нормально.
А если область сложная и подобные задачи встречаются часто, то сотруднику надо дать время и оплатить прохождение специальных курсов, чтобы ему было проще работать, ну если все остальные знакомы с необходимой базой или всех отправить. Тут зависит от команды и менеджера. Где-то всех отправить, где-то одного-двух, кому больше всех интересно, а он потом они обучат остальную команду по ходу работы.
На синке человек не просто говорит из дня в день "делаю таск №342", а говорит, что конкретно он делает, с какими проблемами столкнулся, как думает их решить или что уже сделал для их решения.
Жаль, у меня нет рейтинга поставить вам плюс.
Важные мысли я почерпнул и записал
Хм, надо попробовать. В обычный спринт к задачам на разработку даём задачу на ревью и даём ответственных. Возможно допилить конфиг джиры на автомат создание сабтаски при попадании в кодревью (Создание пулл)
Это совсем не обязательно отдельная задача, достаточно просто статуса задачи. Таскать на ревью, таскать на тестирование - хорошо для KPI - смотрите как много тасок делает команда, но забивает доску. А после ревью создавать сабтаску на исправление, а потом на ревью исправлений? И сколько задач надо на ревью, если ревьювеоров больше одно - по количеству ревьюверов?
Плюс одну таску по статусам туда-сюда двигать замучаешься, а тут жонглировать большим количеством. Вы же это хотите ввести не просто так, а чтобы понимать сколько времени тратится на тот или иной процесс. Поэтом надо фиксировать когда задача находится в активной фазе - разработка/ревью, а когда в ожидании ревью или исправлении замечаний.
Но для выявления узких мест достаточно мониторить в каком статусе и сколько задача провисела, джира точно умеет такую аналитику делать, у нас её строили. А в случае оценки задач, можно накидывать сторипоинты на оцепенею задачу. В среднем 50% от длительности задачи можно накинуть на ревью. Если в среднем приходится больше времени тратить, то значит что-то не так с процессом разработки и проблемы выявляются слишком поздно.
Один из законов управления гласит, что усиление контроля ведёт к снижению теоретической производительности. Можно заводить такси на каждый чих, но накладные расходы на их менеджмент сведут всю пользу на нет.
статус "надо попробовать" это как раз про то, что можно попробовать ) А попробовать это строго тогда, когда в команде есть вопросы с ревью процессом, и только тогда. ИМХО это более мене формализованный подход - поставить метрику, определить круг вовлеченных, и снять возражение "не хватка времени". Вдруг в команде понимание "Collective code ownership" еще не выросло, нужно помочь )
Заведение отдельной задачи на ревью не очень то и поможет. Да, попробовать можно, но, кажется, что просто статус у основного тикета "в ревью" так же поможет отследить сколько задача находится в ревью.
Код-ревью вообще довольна дискуссионая вещь. Если цель "попробовать" - доказать разработчикам, что у них есть время, на ревью, хотя они утверждают, что нет. То скорей всего проблема не во времени.
Возможно, на ревью выкатывается слишком большие части, которые просто не хочется ревьюить, если это является нормой для команды, то может от код-ревью перейти к дизайн ревью, где разработчик перед исполнением задачи нарисует/опишет словами что он будет делать, так чтобы было примерно ясно как именно это будет реализовано.
Тогда и код-ревью будет проводить проще, так как надо будет сопоставить то, чтобы было задумано с тем, что получилось. А может и вообще отказаться от код-ревью. Или смотреть на код-ревью только тесты.
Работа с возражениями -- это и есть цель для "попробовать" и строго тогда когда они есть. Если все норм работает -- не трогаем ).
А теперь по пунктам, они кстати все относятся к "понимание "Collective code ownership" еще не выросло":
"на ревью выкатывается слишком большие части"-- вот сразу вопрос к грумингам эстимейшн процессу и декомпозиции задач
"дизайн ревью, где разработчик перед исполнением задачи нарисует/опишет словами что он будет делать, так чтобы было примерно ясно как именно это будет реализовано" -- чаще всего происходит при груминге для синхронизации понимания остальными PBI и верификации содержимого.
"смотреть на код-ревью только тесты" ИМХО тесты это часть документации продж. И не смотреть остальное как то такое
Небольшие, хорошо поставленные и сформулированные задачи - это здорово! Если это так, то странно, что у разработчиков не хватает времени его делать, ну разве, что они перегружены задачами.
"смотреть на код-ревью только тесты" ИМХО тесты это часть документации продж. И не смотреть остальное как то такое
Вообще легко, можно и тесты не смотреть зависит от проекта и команды, конечно. Но в целом, если код покрыт тестами и тесты корректны, то не так важно как цель достигнута. Т.е. если код написан великолепно, но в этот код больше никто никогда не полезет или менять его придется не часто, то мало кто восхитится красотой, равно как и если код плохой - об этом никто не узнает. Со своей задачей справляется - это главное. Если над этим кодом активно ведется работа, то так или иначе несколько людей взглянут на этот код и поправят его. Стоит внутри проекта давать трогать разные его части всем членам команды, чтобы они лучше понимали, как и что работает. Ревью не заменит практику.
Поэтому в целом, код ревью может и отсутствовать. По договоренности внутри команды. Ревью приносит реальную пользу лишь когда велик шанс, что будет сделано не то, что надо, ну или нет доверия друг к другу. На первых порах формирования команды полезно, чтобы выработать единые подходы, при онбординге. В остальных случаях, это скорее дань моды, чем практика приносящая существенный результат. Если у вас хорошо выстроены процессы постановки задачи, а судя по тому, что Вы говорите - это так и есть, то вполне вероятно, что команда может и отказаться от обязательного код ревью каждой задачи без какого-то ущерба. Ну и проверить это довольно легко, особенно, если у вас спринты небольшие. Если качество сильно упадет без ревью, то это быстро вскроется и эксперимент можно прекратить. А если кто-то в коде случайно заметит что-то "плохое", то автору можно об этом сказать и при работе над кодом в этом месте поправить.
Я работал и там где ревью было обязательно и там где оно было по желанию. На качество исполнения влияло только качество постановки задачи.
Канбан пробовали? Тут товарищи заметили схожести, а к нему есть уже board в Jira.
Мне кажется вы не совсем верно расшифровывайте термин "Эстафета", эстафета - это совокупность командных действий в которых участники проходят этапы один за другим
Т.е. если применить в к вашему тексту, то скорей надо рассматривать следующую последовательность эстафеты в команде
анализ
задача на бд
задача на бэк
задача на фронт
задача на тестирование
задача на приёмку (техпис и т.д.)
Список можно расширять и дополнять. При такой эстафете дела должны пойти лучше и результат уже будет командным
И получается, как указали коллеги выше Kanban)
Публикации
Концепция «эстафеты» как альтернатива спринта