Ух, очень развернуто объяснили зачем нужно ретро. Зашел вам плюсик в карму поставить, а столько минусов. Видать те, кто прячется в кокон от проблем, накидали :)
Ретроспектива — это часть процесса разработки. Не бывает, что все прошло гладко, это точно.
«Если вы ничего не сделаете, я уверяю вас, ничего и не произойдёт» ;)
Спасибо за развернутое мнение. Это действительно аргументировано. Я думаю, что где-то есть золотая середина и мы как раз в поиске ее.
Многое зависит от процессов и от компании. Если это органично встроено, то хождения по мукам сводятся к минимуму. Хотя я настроения, подобно вашим, иногда наблюдаю. Вероятно, еще зависит от отношения к ретро.
Если обсуждать сразу, то это не выдергивание из потока?
Ретроспектива проходит тогда, когда спринт закончен. По его итогу идет разбор полетов. Это помогает каждый следующий этап работы сделать лучше.
Что касается ретро отделов — проводим их раз в два месяца. Разбираем, что было за это время. Это не значит, что остальное время все молчат, как рыбы :)
Важно, чтобы они знали тему. Ты не должен быть разработчиком, но понимание уровней архитектуры, каких-то принципов должны быть, чтобы обсуждать какие-то моменты, нюансы без: «Ой, я сейчас тимлида позову».
Не вижу ничего плохого, если на каких-то моментах или нюансах, которые касаются архитектуры или кода приглашают лидов. Тут же речь не про просто «поговорить», а какие-то технические детали обсуждаются? Не «а вот наш стэк такой-то» :)
Полезный материал, особенно последние абзацы. Общаться в любом случае нужно уважительно и решать проблему, а не доказывать, что ты прав.
У нас есть заказчик, который затянул с оплатой (прилично затянул) и мы уже входили в стадию конфликта. Но затем вдохнули-выдохнули, прикинули варианты и предложили ему рассрочку платежей.
Про доску перед началом спринта интересно, надо попробовать)
Вроде я так и написал, а вы сказали другими словами)
Запасаюсь попкорном :)
Вот вы говорите про дейлики — так стендап, как и ретро — часть скрама.
На стендапе принимают решения, как лучше сделать именно сейчас, а на ретро вносят изменения в процесс.
Это я сильно упростил, чтобы не писать портянку.
Ух, очень развернуто объяснили зачем нужно ретро. Зашел вам плюсик в карму поставить, а столько минусов. Видать те, кто прячется в кокон от проблем, накидали :)
Ретроспектива — это часть процесса разработки. Не бывает, что все прошло гладко, это точно.
«Если вы ничего не сделаете, я уверяю вас, ничего и не произойдёт» ;)
Неистово плюсую!
Ретроспектива — это не сколько пожурить, а отметить хорошие моменты :)
Спасибо за развернутое мнение. Это действительно аргументировано. Я думаю, что где-то есть золотая середина и мы как раз в поиске ее.
Многое зависит от процессов и от компании. Если это органично встроено, то хождения по мукам сводятся к минимуму. Хотя я настроения, подобно вашим, иногда наблюдаю. Вероятно, еще зависит от отношения к ретро.
Есть такое мнение, да. Многое зависит от процессов и от того, как проходит сама организация.
Если команда не видит изменений и улучшений, то будут поддакивать и давить из себя хоть что-то :)
А кто сказал про пол года?
Если обсуждать сразу, то это не выдергивание из потока?
Ретроспектива проходит тогда, когда спринт закончен. По его итогу идет разбор полетов. Это помогает каждый следующий этап работы сделать лучше.
Что касается ретро отделов — проводим их раз в два месяца. Разбираем, что было за это время. Это не значит, что остальное время все молчат, как рыбы :)
Хорошая идея, мы так тест-кейсы прописываем для проектов на этапе разработки. По сути это тоже чек-листы)
Не совсем понял ваш комментарий. Что имеете ввиду?
Вырубаем минусометы, все по делу!
Здесь речь идет о типовых элементах. Например, если есть в мобильном приложении «Профиль», то должна быть функция «Удаление профиля».
Какие-то неизведанные функции чек-листом не покрыть :)
Не вижу ничего плохого, если на каких-то моментах или нюансах, которые касаются архитектуры или кода приглашают лидов.
Тут же речь не про просто «поговорить», а какие-то технические детали обсуждаются? Не «а вот наш стэк такой-то» :)
Добавим себе такой пункт, спасибо)
Все верно. Мы закладываем риски. В статье речь именно про оценки разработчиков и попадание в них.
Что-то похожее на правду)
Поделитесь обязательно и сами используйте :)
Может есть чем дополнить чек-лист по дизайну?
Интересное дополнение) В целом они во все сферы просочились, да
Верно подметили)
Полезный материал, особенно последние абзацы. Общаться в любом случае нужно уважительно и решать проблему, а не доказывать, что ты прав.
У нас есть заказчик, который затянул с оплатой (прилично затянул) и мы уже входили в стадию конфликта. Но затем вдохнули-выдохнули, прикинули варианты и предложили ему рассрочку платежей.
О, чудо, и платежи пошли)
Выздоравливайте)