Комментарии 32
Дикая ненужная хренотень, заставлюяшая людей что-то из себя вымучивать. Всё моменты можно обсуждать нормально в рабочем процессе, а не вырывать людей из потока. Нет ничего хуже чем вспоминать, что ты делал раньше, даже в. Рамках двух недель. За две недели не происходит буквально ничего, что можно обсудить. И это ненормально обсуждать рабочий процесс через полгода, вы за полгода не можете поставить работу на поток, и отладить процессы в команде?
А кто сказал про пол года?
Если обсуждать сразу, то это не выдергивание из потока?
Ретроспектива проходит тогда, когда спринт закончен. По его итогу идет разбор полетов. Это помогает каждый следующий этап работы сделать лучше.
Что касается ретро отделов — проводим их раз в два месяца. Разбираем, что было за это время. Это не значит, что остальное время все молчат, как рыбы :)
Это у менеджеров спринт что-то значат, какое-то мерило, менеджерский цикл. Для человека, который работает эти две недели пролетают так, что ты уже не помнишь, что было две недели назад. Если пилишь большую фичу, ты не помнишь, сколько это заняло и сколько ещё займет. Это есть состояние потока, погружение в текущие задачи, мы не хотим хранить ненужный контекст в памяти. И как раз лучшее что может сделать менеджер - это сохранять это состояние, не давать из него выйти, помогая решать мелкие рабочие моменты, распределять задачи, координировать внутри команды и вне с другими. Но менеджеры этого не могут понять, им нужна стимуляция полезной деятельности. И за две недели ну ничего не меняется, и ни один менеджер сам никогда не сможет провести, так как сам не вспомнит точно, кто что делал. Это просто именно что вымучивание. За все время работы у нас не было ни одного полезного ретро. Все полезное уместилось бы в десяток тредов в рабочем чате. И они обожают в этот круг дрочерства вытягивать всех, не понимая, что в отличие от них, у людей есть настоящие задачи. Имхо, производительность команды увеличат не митинги, а если убрать одного тимлида и вместо него взять фулстека, который может перекидываться на ботлнеки в рамках команды. А если что, и сам протестирует, если ботлнеки на тесте. Вот такой человек будет золотой и дай тебя расцелую.
Спасибо за развернутое мнение. Это действительно аргументировано. Я думаю, что где-то есть золотая середина и мы как раз в поиске ее.
Многое зависит от процессов и от компании. Если это органично встроено, то хождения по мукам сводятся к минимуму. Хотя я настроения, подобно вашим, иногда наблюдаю. Вероятно, еще зависит от отношения к ретро.
У вас какие-то проблемы с командой или задачами. Ну или с РО или кто там у вас.
1) за спринт должно, нет, даже не так, ОБЯЗАНО, что-то произойти. Во первых в этом смысл спринта - не просто какие-то рандомные две недели в которые что успели то и успели, а очень конкретные цели на эти две недели. Во вторых спринт средней команды на 6-7 человек стоит компании 1-1,5 млн. В самом худшем случае стоит задать себе вопрос на что их просрали и почему вместо нас не нанять голых баб на такие деньги.
2) В смысле "не помнишь" что было за две недели? У вас там ни тасктрекера, ни гита? Вообще не помнишь? Вот совсем? Про цель спринта молчу, как ее можно забыть я вообще хз.
Может быть такое, что помнишь и просто не случилось ничего, что требует обсуждения. Ну и ок, у других то не так. Им помочь не надо? Порадоваться за них. Подсказать что-то. Вообще ни у кого ничего не случилось? Так не бывает. Демо было, на нем был фидбэк от юзеров. Даже если он хороший, что никто не подумал, что если бы сделали А вместо Б, то было бы ещё лучше? Значит просто все боятся язык из жопы достать и озвучить проблемы.
3) Именно чтобы не выдергиваться из рабочего процесса и не решать проблемы сгоряча и есть ретро. А если разборка что "а мы от дизайнеров макеты поздно получили" и "а чо вы раньше не сказали что так нельзя было, мы уже так нарисовали и согласовали" решается в моменте то это как раз вырывает из процесса и не помогает никак.
4) Фуллстэк который помогает вытягивать ботлнеки и есть тимлид (ну или техлид по терминологии некоторых компаний). Только он именно помогает, а не просто решает все самые сложные ситуации, не давая развиваться другим. И нанимать второго такого - плохая идея. Для того и придумали разделение труда и экспертизу в своей области. А если за вами надо нескольким тимлидам бегать сопли потирать, то точно лучше всё-таки голых баб вместо команды, с ними и повеселее.
5) Менеджер (тимлид или РО) должны помогать решить проблемы, но для этого они должны: а) узнать что она есть, желательно без применения хрустального шара и ректальной криптографии, б) понять что это именно проблема, а не вы выдумали, для чего хорошо бы иметь все точки зрения и ещё пару наблюдений со стороны, в) понять как это чинить, для чего лучше всего подходит экспертиза тех, кто был уже внутри ситуации или шарит в ней. В итоге ретро и есть то место, где я могу узнать от команды что дизайнер нарисовал в макете что-то смог не реально было за спринт сделать, без девопса не успеваем серваки настраивать, тестировщик кейсы прописал поздно и пр.
У вас или очень очень плохая команда, или совсем плохая компания, или крайне специфичная область... но скорее всего, конечно, проблема в вас самих, если за все время прям ни одного хорошего ретро.
Ух, очень развернуто объяснили зачем нужно ретро. Зашел вам плюсик в карму поставить, а столько минусов. Видать те, кто прячется в кокон от проблем, накидали :)
Ретроспектива — это часть процесса разработки. Не бывает, что все прошло гладко, это точно.
«Если вы ничего не сделаете, я уверяю вас, ничего и не произойдёт» ;)
за спринт должно, нет, даже не так, ОБЯЗАНО, что-то произойти
Ну, я сделол за спринт вторую треть сложной задачи. Что произошло? Да, ничего. И прошлый и в позапрошлый это же "произошло".
В смысле "не помнишь" что было за две недели? У вас там ни тасктрекера, ни гита?
Вот именно, товарищ манагер. У вас что, нет ни трекера ни гита? Вы ленитесь туда посмотреть? Может вы вообще не владеете этими инструментами? Что могло помешать вам туда заглянуть? Зачем разводить эту мутотень и повторять то, что уже описано?
чтобы не выдергиваться из рабочего процесса и не решать проблемы сгоряча и есть ретро.
А чем это решение проблемы на ретро отличается от решения проблемы на дейлике? На дейлике я ещё помню в чём была проблема, к ретро могу и забыть.
У вас или очень очень плохая команда, или совсем плохая компания
А может у вас? Ярлыки навешивать легко.
но скорее всего, конечно, проблема в вас самих, если за все время прям ни одного хорошего ретро.
Если вопросы решаются более оперативно, чем раз в две недели, то, с вашей точки зрения, это проблема? И именно у вашего оппонента? А мне кажется, ровно наоборот :)
Запасаюсь попкорном :)
Вот вы говорите про дейлики — так стендап, как и ретро — часть скрама.
На стендапе принимают решения, как лучше сделать именно сейчас, а на ретро вносят изменения в процесс.
Это я сильно упростил, чтобы не писать портянку.
Вот вы говорите про дейлики — так стендап, как и ретро — часть скрама.
Дейлики могуть быть частью скрама, а могут не быть частью скрама.
Дейлики вообще придумали давно. Ещё до рождения скрама. И даже до рождения авторов скрама :)
На стендапе принимают решения, как лучше сделать именно сейчас, а на ретро вносят изменения в процесс
Если мерилом работы является религиозный процесс, то да. А если результат, то it depends. Во многих случаях эффективнее не ждать приседаний по команде, а решать проблемы по мере их поступления.
а на ретро вносят изменения в процесс.
Ну, вот, работает команда пять лет. И вы всё это время каждые две недели вносите изменения в процесс?
Кажется, эти формализованные приседания имеют смысл в начале работы новой команды, когда коллеги ещё не привыкли друг к другу.
Сколько ни работал в разных командах, лучшее, что случалось на ретро - вынесение вопроса - давайте проводить ретро ЕЩЁ реже :)
"Вот именно, товарищ манагер. У вас что, нет ни трекера ни гита? Вы ленитесь туда посмотреть? Может вы вообще не владеете этими инструментами? Что могло помешать вам туда заглянуть? Зачем разводить эту мутотень и повторять то, что уже описано?" - дай я тебя обниму)). У меня если начать задумываться, начинает пригорать, что менеджер хочет чтобы ты помнил предыдущие две недели. Это означает а: ты должен записывать и вести лог всех своих свершений за эти важные для компании две недели, либо б: постоянно держать в памяти устаревающую информацию, а к ретро все это прокрутить заново.
Есть такой тест на память, ты должен с помощью любых техник запомнить максимальное количество слов-существительных из набора(около 20)
проверяется три раза - сразу после запоминания, на следующий день и через неделю и две(не помню, потому что читал про этот тест больше двух недель назад).
Так вот, с каждым разом человек почти всегда называет меньше слов, чем в предыдущий. И это в рамках пары недель. А это всего 20 каких-то несчастных слов, а не полная история мытарств за две недели.
Поэтому когда вы умные менеджеры добавляете человеку обязанность помнить предыдущие две недели, вы вносите дополнительную сложность в процесс, из-за которого
падает индивидуальная эффективность. Как понижая индивидуальную эффективность можно повысить общую для меня загадка, это какая-то скрам-магия.
Как правильно делать: пользуйтесь мать его таск трекером и любыми утилитами по анализу этих данных, разговаривайте с коллегами на дейликах, но не о прошлом, а НАСТОЯЩЕМ, о текущих проблемах.
Пока ретро не начинается с того, что тимлид проговаривает саммари за две недели(что как раз является его прямой задачей, управлять процессами и помнить их историю, как минимум в рамках своей команды) я считаю это симуляцией полезной деятельности.
У вас ошибка в фразе "стимуляция полезной деятельности". В целом правильные замечания, проблема в том что чаще всего человек проводящий ретро не понимает его смысл, поэтому и получается вымучивание. У меня был только 1 раз когда скрам мастер не симулировал процессы, а реально делал полезную работу. И в этом плане ретро было время когда разработчики могли рассказать о своих проблемах, поделиться чем-то полезным и самое важное после этого ОН что-то делал, так чтобы это не пропадало в ящике отложенных (на никогда) дел.
Вы как-то всех судите по себе.
Если вы работаете на износ, что в конце спринта не помните, что было в начале - этот вопрос надо обязательно поднимать в команде. И ретро отличное место для этого.
Так и выгореть недолго...
Но я в командах давно решил эту проблему: делаю доску для ретро вначале спринта, ссылка всегда одна и та же, вся команда знает где она лежит. И если члену команды хочется что-то обсудить, чтобы не держать мысль до конца спринта - он сразу пишет ее на доске. Дальше перед ретро смотрим - есть что обсуждать или ретро можно скипать.
п.с. ни разу еще не скипывали, всегда проблемы набираются. Просто иногда проводим быстрее запланированного тайминга.
За стандартные две недели происходит в живой команде до фига. А если и демо прошло не очень ...
Возможно вам не повезло с командой, либо с менеджером
Потому что почти всегда есть что сказать
И да, можно кого-то позвалить. И даже не кого-то одного :)
А вот незнаю. Мне (и как оказалось - команде) очень нужная хренотень, потому что без ретро ловлю себя на мысли, что заканчиваю рабочий день не дорабатывая, есть какое-то ощущение незаконченности, будто весь день ничего не сделал. При этом проект перформит сильно лучше конкурентов по рынку, таски закрываются, новые продукты выкатываются, процессы улучшаются, всякие штуки по управлению командой делаются, 1-2-1 проходят регулярно, а вот я как-будто ничего и не делаю. А все потому что с конца весны ретро перестал проводить, и нет четкого осознанного и озвученного подведения итогов и результатов ни у кого.
Есть такое мнение, да. Многое зависит от процессов и от того, как проходит сама организация.
Если команда не видит изменений и улучшений, то будут поддакивать и давить из себя хоть что-то :)
Так не надо поддакивать и проводить ретро ради проведения. Пришли за 2 минуты сказали что все хорошо и пошли работать дальше. NB У меня так ни разу не было, но в целом я не против и такого формата.
Лучше уметь возможность обсудить и решить проблему и не иметь таких проблем. Обратная ситуация куда хуже.
Это как огнетушитель или аптечка. Их покупают, надеясь никогда не воспользоваться. Вот только если припрет эти предметы ничто не заменит.
У автора, мне кажется, желтый раздел излишний. Но если ответ "ничему, все равно" приемлем, то ок.
Во время ретроспективы предложите команде вспомнить пройденный этап. Какие ключевые события в то время произошли, над чем необходимо поработать? Приведите несколько примеров самостоятельно, чтобы задать тон и показать открытость мероприятия.
Это главный минус, который я увидел в вашей идее.
Ретро митинг должен быть
1. доступен для всех желающих, но практически обязателен для тимлидов/техлидов/менеджмента/архитектора
2. Приходить на него нужно подготовленным. То есть уже с конкретными проблемами, в идеале заранее добавленными в нужный документ/таблицу с полями "название, описание, приоритет, и другие которые в вашем процессе используются".
3. Проводиться ретро должен не каждый спринт, а выбрать оптимальные промежутки. Причем можно через 2-3 ретро посмотреть как оно идет и снова поменять.
Тогда это будет не болтай-шатай, а просмотр предыдущих проблем, выработка решения что с ними делать. Если решение было выработано - обсуждение насколько оно удачно решает проблему. Если не решает - придумать/обсудить новое или закрыть эту тему, пока никто не предложит что-то, что работает лучше, чем сейчас.
Ну и рассмотрение новых проблем и решение, добавлять ли их в общий список.
Ретро - это вынос проблем, которые могут быть внутри определенной задачи/команды, но которые аффектят гораздо больший кусок организации, и следовательно не может быть решен внутри.
Это решение проблем вашего SDLC, подхода к работе, к инфраструктуре.
Это хорошая и важная часть, но ее нужно уметь готовить, а именно - минимизировать сами митинги в продолжительности (приходить с подготовленными вопросами, а не вкидывать их прямо во время ретро), и от ретро должна быть реальна польза - проект должен быть готов внедрять решения различного уровня сложности. Для этого менеджмент должен реально выделять ресурсы. Как капасити, так и финансы.
Но на ретро также можно и выяснить, почему есть такая проблема, и реально понять, что изменить некоторые вещи на более удобные, реально стоят дороже, чем кажется, и иногда настолько дороже, что заказчик не готов это оплачивать.
Вроде я так и написал, а вы сказали другими словами)
Про ретро в отделах/ подразделениях зря написали. Там как раз устоявшийся коллектив которому ретро не нужны. А вот на проектах со сборной командой впоне таки требуется и именно в таком духе как описано выше.
Вы сказали "Во время ретроспективы предложите команде вспомнить пройденный этап"
Вот именно на этом моменте, ретроспектива за пару митингов превратится из инструмента в место для нытиков, которых никто не воспринимает, в результате на него перестанут приходить, перестанут серьезно воспринимать, перестанут им пользоваться.
Ретроспектива должна проходить эффективно, иначе в проекте где больше одной команды, она будет просто переливанием различных мелочей и продолжением обсуждений спринта.
Выступающие должны прийти с готовыми темами, может даже с готовым решением, которое кратко обсудят, назначат ответственного (не исполнителя, а того кто организует/проследит/придумает решение более детально на следующий митинг), и перейдут к следующему.
В Agile может быть много разных типов митингов. Но чтобы Agile работал, каждый митинг должен отвечать за свою часть, и самоорганизованность команды и каждого игрока в ней влияют на то, как Agile работает в проекте.
Ретро, спринты, скрамы.
Пусть сначала авторы этого процесса покажут результат своей работы. Я не понимаю почему народ на слово верит хрен пойми кому.
Вот торвальдс делает(делал) ядро линукса через mail lists и так до сих пор происходит. При этом там нет скрама, ядро работает на сотнях миллионов устройств. Т.е. это наисложнейший универсальный мировой продукт.
Вопрос почему люди выбирают какой-то непонятный скрам, который реально не доказал свою успешность в деле, а не изучают процессы в результате, которых был сделан мировой продукт огромной кучей людей?
Да безусловно скрам содержит полезную инфу, но целиком и полностью ей доверять никак нельзя.
Я не хочу читать, что это работает, я хочу запустить и проверить что это работает.
Почему 2 недели например? у меня есть фичи которые делаются 2-3 мес, и частичная их работа бизнес не интересует, т.е. бизнес начнет зарабатывать деньги когда фича будет, а что там просиходит до этого их мало интересует.
Если мне скажут например мы ходим на ретро, я скажу, что все проблемы были озвучены своевременно и пойду работать.
Если манагер не улавливает проблемы в контексте, и выдергивает всю команду на то, чтобы ему еще раз сказали, что у него не так в команде, такой менеджер мало того что сам не работает, так еще и мешает работать другим.
Вот сижу я, условный сеньор-помидор, и делаю задачу. И понимаю, что мне что-то не нравится. Я могу пойти и сказать, что, вот, так и так, пните бек/фронт/пм, потому что вот такие проблемы есть. Или я могу эти проблемы высказать лично - обсудить директивно с тем, кто эти проблемы создает. Есть хотя бы одна причина, почему я должен ждать две недели до конца спринта, и говорить об этом там? Мы ведь взрослые люди, ведь так?
А нет, видимо не так. Не знаю, с чем связано, но разработчик в глазах менеджмента потихоньку скатывается к развитию двухлетнего ребенка с функцией писать код. Отсюда внезапно появляется тысяча статей о том, как мы начали кормить разработчиков овсяной кашей, и как это повысило нашу производительность. Другой менеджер, прочитав статью, решает, что нужно срочно внедрять такие же методы, и пишет статью на хабр, а дальше оно копится как снежный ком. Начали появляться различного рода профессии вроде неких деврелов, чтобы взаимоотношения строить - ведь логично, что взрослые люди в наукоемкой профессии не в состоянии друг с другом договориться.
Как люди 10 лет назад писали код? Задачу дали - инструмент дали - не мешают. И работало ведь.
>почему я должен ждать две недели до конца спринта
Непочему. Ждать не нужно. На ретро скажете была проблема, быстро решили, все молодцы. Делов на 2 минуты.
Или на ретро скажете была проблема, пол спринта добил чтобы решили, в итоге свою задачу доделывал впопыхах или вообще не успел.
Ретро для системных проблем, а не сиюминутных. Потому и готовиться особо не надо. Системная проблема на то и системная, что не даст о себе забытью
Как люди 10 лет назад писали код? Задачу дали — инструмент дали — не мешают. И работало ведь.
Причем работало даже лучше, чем поделия, работающие сейчас.
Товарищ автор, вам для инфо да и в целом для расширения кругозора т.к. мнения в комментариях полярные.
В целом одни и те же принципы эксплуатируют различные методологии в различных сферах деятельности. Отличия лишь в названии и предметной области. Так например бережливое (Lean) производство предлагает выделять время (например час в неделю) на выявление проблем и улучшение процессов.
По своей сути выделение отдельного сервера для сборок, покупка дополнительного шредера архивариусу и установка отдельного крана с деионизированной водой на производстве - это решения одного порядка и к ним приходят примерно одинаковым способом. Выявляют системную проблему и борются с нею. Выявляют на ретро или любом другом аналогичном мероприятии.
Публикации
Проведение ретроспективы в компании: что это простыми словами, как и зачем ее проводить, чтобы была польза? + чек-лист