Комментарии 28
Прочитал стотью, что бы понять, что такое Ретро. Не понял.
Так что такое Ретро?
По задумке это такая планёрка, на которой вы должны подвести итоги спринта, посмотреть на успехи, на неудачи и сделать выводы или принять меры, чтобы неудач или неудобств было меньше.
Можно тут посмотреть например: https://www.youtube.com/watch?v=McCgpTONOV8&list=PLu7pKL8OAoRQOaAMBm8PeRrNG3AmlbCxd
Это такое смешное совместное времяпровождение, в результате которого подгоняемые должны начать себя хлестать с удвоенной силой , причём бесплатно :)
З. Ы. Для всех, кто в индустрии больше 5 лет и мозги на месте - это мертворождённый формат. Это как идти к психологу, который за много денег поможет тебе разобраться, где ты косячишь в жизни, только вот дурака учить - только портить. В общем, чисто американская фишка.
Кажется, у вас искажённый опыт ретро. Смысл как раз в том, чтобы команда меньше получала тумаков от менеджмента и меньше косячила. С сравнением с психологом тоже не соглашусь - на ретро основная фишка, чтобы команда как раз сама выявляла и решала свои косяки в идеале без приглашённого "мозгоправа".
Скрам-мастер скорее нужен только в начале, чтобы научить команду это делать полезно для неё. Видел команды которые через 6-12 месяцев вполне могли проводить Ретро сами без специально обученного человека
Примерно так и есть. Говорят разговоры, которые ничего не меняют.
Ага. Вот задача Скрам-Мастера перевести эти разговоры в конструктивные обсуждение и фиксацию решений в конце Ретро
Типичное мнение скрам-мастера. "Без меня ничего не заработает".
Был у меня в универе случай. Попросили перетащить большой кондовый стол с этажа на этаж. Все тащили, а один чел, наверняка будущий скрам-мастер, бегал вокруг и типа рулил: "так, так, левее, ещё левее, теперь прямо, ага". Когда мы потные таки дотащили эту дуру до места назначения, он на полном серьёзе сказал: "ну вот видите, при грамотном руководстве всё возможно". Был послан и "в" и "на".
Мой опыт 2.3. Но такие случаи скрам-коучи и их аналоги обычно не любят. Интересно, про этот пункт можно написать статью? Про остальные мне как раз все понятно - "не работайте с мудаками".
Ретро... Одна из наиболее бесполезных штук в рабочем процессе. Бесполезнее только сами скрам-мастеры.
"Серёженька сегодня первый скушал кашку, давайте похвалим Серёженьку, вот тебе звёздочка. А Виталик недоел салатик. Кушай лучше, Виталик, тебе тогда тоже дадут звёздочку". Буээ.
В любой команде все и так знают, кто как кушает.
Обсуждение проблем - очень полезная штука, но зачем ждать ретро? В хорошей команде это постоянный непрекращающийся процесс. Формат ретро "давайте обозначим проблемы, а потом запланируем отдельное совещание" - бредовый полностью, лишний ненужный этап.
Обсуждение достижений - зачем? Почесать СЧВ?
Зато для менеджера ретро это просто песня. Минус час рабочего времени, по итогу можно написать красивый отчёт "заслушали, постановили", обязательно приложить к нему прикольные картинки, которые будут выбираться ещё два часа (запись в отчёте: подготовка к ретро).
Я в разработке 20+ лет и повидал всякое. Но вот ретро в классическом "скрамном" стиле лучше бы не видел.
Менеджеров как правило не пускают на ретро, ибо есть риск, что никто не сознается в косяках. А в целом поддержу, что проблемы лучше всего решать по мере их поступления, но не все такие зрелые разработчики, как вы - многим проще залатать дыры костылями. И в частности для этого делается регулярное обсуждение проблем.
Что, кстати, подразумеваете под "классическим стилем" Ретро?
Менеджеров как правило не пускают на ретро, ибо есть риск, что никто не сознается в косяках.
Без менеджеров тоже никто не сознается, если что-то прокатило, никто не заметил и это не стало причиной чего-то нехорошего. Когда у человека будет следующая задача на подобную тему, он зафиксит косяк в ней и получит дополнительную звёздочку за прозорливость и неравнодушие.
Опять же, если человек увидел баальшой косяк, но было поздно, то "добровольное признание смягчает вину" и приводит к получению дополнительной звёздочки за прозорливость и неравнодушие.
Что, кстати, подразумеваете под "классическим стилем" Ретро?
Классический стиль в моём понимании - это стиль победившего менеджмента.
Надо, не надо - ретро устраивается, потому что это обязательная церемония. Потому что если мы не устроим ретро, это будет не скрам, а если это будет не скрам, то мы работаем неправильно. А если мы работаем неправильно, то это не скрам виноват (он идеален), это вы долбо^W несовершенные и вас надо подгонять под прокрустово ложе идеального скрама, где первичны церемонии, а не результат.
Обязательно будет вводное слово, потом поочерёдно четыре части: "чего мы добились", "какие проблемы поимели", "что я/мы могли бы сделать лучше", "а кто у нас скушал всю кашку и заслуживает звёздочки?". В обязательном порядке по каждому пункту будут опрошены все поимённо, по итогу в жыру упадёт документ с четырьмя колонками и прикольными картинками. Ну и финальное слово, конечно. "Советский Союз и Коммунистическая Партия сталкиваются с всё новыми и новыми вызовами, но мы, как комсомольцы и патриоты Компании, остаёмся верны делу Ленина и Партии..."
>> Надо, не надо - ретро устраивается, потому что это обязательная церемония.
>> Обязательно будет вводное слово, потом поочерёдно четыре части
Да, этот один из самых распространнёных анти-паттернов, котjрый как раз и приводит к тому что у команды вырабатывается стойкая аллергия к Ретро и к Скраму в целом. Я себя не отношу к Scrum Nazi, потому и затяел эту серию статей, чтобы момочь Скрам-мастерам сделать Ретро полезное для команды
...А бывает так, что в команду, где сидят 20-летние патриархи, приходит свежий "масленок", и тупо боится лишний раз задать вопрос, и днями тупит на простенькими задачами. А патриархи думают, что знают, кто и как кушает. И главное - почему. В итоге - статус кво. Патриархам норм, масленку - плохо, но кого из патриархов он волнует?
Обсуждать проблемы вне ретро - можно, и действительно круто, когда команда так может, и это получается продуктивно. Тогда и без ретро обойтись. Другое дело - оговорка "ХОРОШАЯ" команда. Все команды хорошие? Все команды дорастают до хороших? И еще - все команды способны дорасти до хороших?
Почесать ЧСВ - да. Чесать ЧСВ - полезно, особенно для тех, кто еще до 20-летних "помидоров" не дорос. Да и сеньорам некоторым важно признание успехов. Почему это так обесценивается - непонятно. Если чесать ЧСВ правильно, не приторно и ненавязчиво - то это нужно всем.
Если ретро - это дань карго-культу, в который возведен скрам в команде, то возможно, не надо заниматься ИБД. А если в команде есть выстроенные внутренние порядки, как команда разруливает внутренние косяки - то и прекрасно. Если для этого используется ретро - хорошо. Если другие инструменты - тоже хорошо. НО! Моменты работы надо ошибками и совершенствование команды должно быть всегда. Форма - вторична.
А бывает так, что в команду, где сидят 20-летние патриархи, приходит свежий "масленок", и тупо боится лишний раз задать вопрос, и днями тупит на простенькими задачами.
Лично моё мнение - это его проблемы. Если человек боится задать вопрос, у него в любой сфере будут проблемы. Другое дело, когда он боится задать вопрос из-за постоянного рыка "ты что, тупой?" Но это уже крайняя стадия, и любому человеку должно быть понятно, что оттуда надо валить.
Сам я, слава яйцам, с таким не сталкивался, но моему бывшему коллеге (на тот момент уже бородатый сеньор) пришлось пройти через подобное. Команда патриархов в "возрасте дожития" устроила себе болотце а-ля Шрек и делало всё, чтобы никто в него не заходил. Непредоставление информации и игнорирование были частью стратегии по выдавливанию нежелательных элементов.
Другое дело - оговорка "ХОРОШАЯ" команда. Все команды хорошие? Все команды дорастают до хороших? И еще - все команды способны дорасти до хороших?
Есть специально выделенный человек: начальник отдела (ака тимлид). Одна из его функций - построить в команде процессы и общий климат. Если тимлид этим не занимается, любая группа хороших людей никогда не станет хорошей командой. Исключение - наличие в команде "серого кардинала", который имеет авторитет и рулит всем по-тихому, не привлекая внимания санитаров.
Чесать ЧСВ - полезно, особенно для тех, кто еще до 20-летних "помидоров" не дорос.
Зачем для этого отдельная церемония? Это делается в ревью, на дейликах и просто в прямой связи: "чувак, клёвое решение!", "Вау, третий релиз без одного бага! Продолжай в том же духе, подтягивай {технологияХ} и будем думать про перевод тебя в миддлы", ...
Правильная формула: одобрение - прилюдное, порицание - тет-а-тет.
Моменты работы над ошибками и совершенствование команды должно быть всегда. Форма - вторична.
+++++
PS: в целом не имею ничего против вашего комментария, хороший противовес моему.
PPS: когда я был молодым и зелёным, мне очень помогла книжка Йордана "Смертельный марш. Полное руководство для разработчика программного обеспечения по выживанию
в безнадежных проектах". Скорее всего, сейчас она покажется мне наивной и где-то даже смешной, но мне зелёному она подсветила тёмные углы всей этой ИТ-кухни и действительно помогла избежать нескольких заманчивых, но мертворождённых проектов.
Я вообще очень сомневаюсь, что ретро даст хоть какое-то вменяемое решение хоть какой-то мало-мальски сложной проблемы.
У меня, как у инженера-технолога, ушедшего в ит, перманентное охуевания от херни, выдумываемой в ит разными безграмотными личностями, не знающих элементарных правил управления.
Это ретро - какой-то детское пионерское собрание.
Первое правило управления - группой управляет руководитель. Где в этой схеме руководитель? Что он делает? Каковы его задачи? Или все друг на друга орут, перебивая?
Второе правило - раздачу пиздюлей и пряников, разбор работы руководитель ДОЛЖЕН проводить индивидуально в отдельном кабинете. Иначе упадёт атмосфера в коллективе.
Третье правило - ответственность за работу коллектива несёт руководитель. Он же и обязан проводить разбор и анализ работы коллектива за отчётный период. ОН должен определять методы решения проблем и методы воздействия на подчинённых. Он же и должен определять запрашиваемые у верхов ресурсы, необходимые для работы. У него нужные рычаги, а не у пионерского собрания. Большинство проблем в команде - п. 2.3, недостаток ресурсов, который автор стыдливо обошёл. Или же неправильная оценка ресурсов, необходимая для решения задачи. Ваше же ретро превращается только в скандал со спихиванием ответственности за проёбы накосячивших друг на друга.
Проблема ит в том, что оценка ресурсов, необходимых для решения задачи, производится исполнителем. Это уровень управления допетровских времен, средневековье с подмастерьями. В современном машиностроении оценка ресурсов производится руководством (при помощи специалистов - экономистов и нормировщиков). И ответственность за неверную оценку несёт руководитель.
Задача исполнителя - качественно сделать свою работу. То, что требует и руководитель и так, как требует руководитель. А не так, как решит комсомольское собрание. Комсомольские собрания ему в этом не помогут. Не опиздюливать друг -друга - это работа начальства.
Товарищи руководители! Не занимайтесь хернёй! Изучайте физику, пардон, науку управления.
Коллега, кажется, у вас ровно как в описанном кейсе никогда не было ретро в том виде, в котором оно задуман в Scrum, и похоже, что Scrum-а тоже не было.
Ретро - точно не место где нужно раздавать пряники и звездюли, а место где команда находит решение насущных проблем. Когда инженеры думают над проблемой - менеджеру вообще лучше не мешать, а стоять в сторонке.
Проблема, что в ИТ не особо то и любят авторитарных менеджеров, которые указывают профессионалам, как делать их работу, а, кроме того, системы настолько сложные, что одному человеку, какой бы опытный он не был, ни за что не найти хорошего решения. Потому во многих проектах, хотя далеко не во всех, подходить Agile-процесс, когда команда инженерные и процессные решения принимает коллективно, и отвечает получается тоже коллективно. Руководитель лишь даёт крупноблочные задачи
Пока командой руководят менеджеры, а не специалисты - бардак так и будет продолжаться. Это раз.
Тысяча дураков никогда не придумают решение проблемы лучше, чем один умный и грамотный человек. Это два.
"Системы настолько сложные" - не смешите. Сложные системы - это ракеты и космические аппараты. И там такой херни, как в ИТ, скрумы и ретро - даже в страшном сне не приснятся. А в ИТ элементарные приложения на десять формочек растягиваются на год.
И даже если сложные системы - их можно и нужно дробить (все инструменты и возможности что языков, что технологий, хотя бы микросервисов) на простые части. Ровно также, как и делается в машиностроении и космонавтике. Простые детали и узлы давать инженерам послабее. Для решения сложных проблем и узлов надо искать и обучать сильных инженеров, а не собирать в одной комнате десять безграмотных людей, не имеющих даже инженерного образования.
Программист тебя на 3 буквы пошлёт если ты ему будешь говорить как код писать)
На этот случай есть QA отдел, а не руководство. Руководство ставит ТЗ. Программист исполняет по ТЗ на своё усмотрение. QA отдел бьёт его по голове, если реализация сильно отличается от требований. Всё. Кодинг дело тонкое и творческое. Если давать таким как вы волю и задрачивать погроммистов, получается лютое говно. Потому-что у QA инженера квалификация и профильные знания есть, а у манагера нет. Вот и вся история.
Нет, уважаемый. За работу подразделения ответственность несет руководитель (ну, в нормальных успешных коллективах). Не манагер, а руководитель отдела. Он несет ответственность за сроки и качество. Руководитель выбирает инструменты, стандарты и подходы работы, стиль и качество кода (если это не стандартизована на уровне предприятия).
Я потому и говорю, что ИТ на уровне допромышленного производства - на уровне мастеров, которые "дело тонкое и творческое". Как у них душа захотела, так они и делают. Страдивари, блджад.
В промышленности же дело уже другое. Руководитель отдела у конструкторов - это самый лучший спец. Такой херни, что "у манагера профильных знаний нет" - там такого в страшном сне не может быть. Королев был суперспециалитом по ракетам. Глушко был суперспециалистом по двигателям. И так далее. И поэтому запускали ракеты.
А когда в ИТ руководят "манагеры" - это, извините, п...ц. Поэтому в ИТ провалы за провалами, просеры сроков за просерами. Обычное дело.
И только в Сбербанке, судя по постам "испуганных программистов", сбежавших оттуда, дела начинает двигаться к нормальному промышленному производству. Результаты, кстати, налицо.
Сказал прямо в душу. Смело могу нотариально подписаться под каждым абзацем и отвечать за это в суде.
Интересное наблюдение:
Люди, которые приходят в "большое ИТ" с производств наиболее адекватны и наиболее нацелены на результат. С ними приятно работать, они никогда не подведут. Если что-то начинает идти не так, они не будут рефлексировать, плакать в подушку и дожидаться ретро. Они просто громко заявят о проблеме.
Люди, которые попали в "большое ИТ" сразу, принимают весь этот скрам-бред как должное, они просто не видели другого. И вот с ними работать очень сложно: хнык-хнык, плак-плак, к моему мега-реквесту написали аж пять замечаний, значит, меня здесь не любят, вот дождусь ретро и заявлю об этом...
Второй пункт, конечно, не про всех. Как и первый. Но моя личная статистика такова.
Что делать если команда не хочет проводить Ретро? (Часть 1)