«Я понимаю, какое у тебя сейчас серьёзное нервное и психологическое потрясение из-за смерти близкого человека. Наверное, тебе сейчас трудно сконцентрироваться и потому ты можешь допускаться какие-то ошибки. Давай обсудим, что мы здесь можем сделать».
Главное вот это возьми на вооружение! Работает идеально!
Рекомендую!
После этого чистейшая, холодная, ненависть гарантирована.
#NoEstimates (термин возник из хештега в Твиттере) предполагает, что любая фича в продукте разрабатывается быстрее, чем заинтересованные в ней лица успевают спросить про оценку трудозатрат.
Мдааааа.
Как говориться твитер он всему голова.
А то что это описано тут: Том ДеМарко и Тимоти Листер «Человеческий фактор. Успешные проекты и команды».
И тут: Фред Брукс «Мифический человеко-месяц».
Конечно же нет.
Автор, перечитай книги.
Да, спасибо за советы, они на самом деле полезные. Цель прочитал не так давно и сейчас осознаю, что когда регрессионное тестирование тормозило релизы, мы пользовались этими знаниями, чтобы ускорить наши релизы.
Регрессионное тестирование не может тормозить релиз. Оно не для этого сделано.
Например, освободили тестировщиков от любой работы не связанной с тестированием релизов, ввели правило Stop The Line когда разработчики не могли создавать новые задачи, чтобы не копить очередь. У нас об этом есть статья.
Я ее прочел. Применяйте пять почему и почитайте про релизный менеджмент. Есть общепринятый набор терминов, лучше следовать им. И вы не очень поняли зачем делается код фриз…
А что касается грамотного QA, если поделитесь контактами, будет очень здорово. Мы бы с удовольствием его наняли. А пока приходится через боль и страдания проходить по всем граблям.
Напишите Сергею Мартыненко
Его сайт: blog.shumoos.com
Настоятельно рекомендую к ознакомлению
Коллеги, очень советую использовать метод пяти почему и прочитать книгу: Теория ограничений Голдратта. Системный подход к непрерывному совершенствованию.
Они вам помогут организовать процессы в вашей компании.
А еще найдите грамотного QA, я думаю вы уже стали большими и вам уже нужен отдельный специалист по качеству.
Человека уволили за то, что он пошел не по процессу, а не за то, что натворил с базой. Мне это тогда так объяснили. На ошибках надо учиться. Лучше на чужих.
Вот этого в статье нет совсем, где он пошел про процессу, почему он это сделал, кто ему приказал. Это основные вопросы. Акценты расставлены совершенно не там.
В нашей компании все рабочие процессы были выстроены безупречно. Проверки, тесты, ревью. Снова проверки, тесты и ревью. Но даже такая система может дать сбой, и ты должен быть готов, что тебя словно солдата-срочника, поднимут утром по тревоге.
В компании практически полностью отсутствовали процессы обеспечения качества.
Понятное дело, что qa специалиста в компании не было. Но говорить о том, что если есть код ревью! То процесс выстроен безупречно! Смешно!
К 7 утра мы все починили. В 8 часов компания уволила человека, который все это заварил.
Вот это просто насмешило. А этот человек то тут при чем. Если архитектор так криво базу спроектировли.
В целом реклама хороша. Но если смотреть сухо, то подпускать автора к руководству нельзя, он ничего не понимает в разработке. В кодинге да, разработки нет.
А я с ЕЕЕ и не спрыгнул, почему вы так решили, я не понял.
И почему вы решили, что Микрософт как то поменяла отношение к Open Source, ну да раньше открыто ненавидела, теперь стала гибче… Я пока не вижу изменений к лучшему. Поглядим, на длинном плече. И пока что все очень укладывается в ЕЕЕ.
По поводу модель изменилась… Рад за них. Прекрасно, они решили свои проблемы. Наверно. Но для меня эта их политика означает что такая вещь как сопровождаемость стала потреблять денег больше. А лишние расходы меня не радуют…
И добавлю. У каждого свое понятие свободы.
Кто то любит неотключаемую и не контролируемую телеметрию, кто считает что это посягательство на свободу и частные границы.
Отвечу так, обучение использованию гиту должно идти в консоли, для понимания процесса.
Это помогает, согласен.
Использовать же консоль при работе на большом проекте, с нормальным уровнем версионного менеджмента, и со сложной версионной политикой. Это себя не любить, банально не удобно и черевато ошибками
А уже разбор полетов…
Тут порекомендовали гит кракен, примкну к рекомендации, годная вещь, в сложных вещах не заменима.
Насчет пул реквеста не понял в чем проблема, у атласиона он нормальный, размер ревью не шибко на что влияет
Боже, какой бред. Мне вот интересно, когда появиться статься в стиле ISO vs Agile vs DevOps где автор воообще напишет про розового единорога в облачках.
А самое фиговое, что люди читают статьи и потом доказывают, что это лучшие практики!
Нет конечно, есть миф, что среда оооочень неопределенная. Определенная она вполне. Более того выполняя анализ, матрицы влияния в помощь, можно четко сказать где будет узкое звено. Собственно планирование релиза как раз в этом состоит, а не в том, что мы на демо покажем
Ответ достаточно простой и сложный. Управляйте работой, а не людьми.
Что еще, в зависимости от релизов, узкое горлышко может быть в разных местах системы. PERT диаграммы вам в помощь.
И да это внезапно работа менеджера заниматься такими вещами и держать их в голове.
И не выдавать вот это:
Специально выделил жирным для mapron, flancer
Ошибки, видели допускать
Главное вот это возьми на вооружение! Работает идеально!
Рекомендую!
После этого чистейшая, холодная, ненависть гарантирована.
Мдааааа.
Как говориться твитер он всему голова.
А то что это описано тут: Том ДеМарко и Тимоти Листер «Человеческий фактор. Успешные проекты и команды».
И тут: Фред Брукс «Мифический человеко-месяц».
Конечно же нет.
Автор, перечитай книги.
Регрессионное тестирование не может тормозить релиз. Оно не для этого сделано.
Я ее прочел. Применяйте пять почему и почитайте про релизный менеджмент. Есть общепринятый набор терминов, лучше следовать им. И вы не очень поняли зачем делается код фриз…
Напишите Сергею Мартыненко
Его сайт: blog.shumoos.com
Настоятельно рекомендую к ознакомлению
Они вам помогут организовать процессы в вашей компании.
А еще найдите грамотного QA, я думаю вы уже стали большими и вам уже нужен отдельный специалист по качеству.
Сомневаюсь, я не тестировщиков имел ввиду.
Вот этого в статье нет совсем, где он пошел про процессу, почему он это сделал, кто ему приказал. Это основные вопросы. Акценты расставлены совершенно не там.
В компании практически полностью отсутствовали процессы обеспечения качества.
Понятное дело, что qa специалиста в компании не было. Но говорить о том, что если есть код ревью! То процесс выстроен безупречно! Смешно!
Вот это просто насмешило. А этот человек то тут при чем. Если архитектор так криво базу спроектировли.
В целом реклама хороша. Но если смотреть сухо, то подпускать автора к руководству нельзя, он ничего не понимает в разработке. В кодинге да, разработки нет.
и стараться избегать их
Тут картинка Дорофеева про горшки и говно.
И почему вы решили, что Микрософт как то поменяла отношение к Open Source, ну да раньше открыто ненавидела, теперь стала гибче… Я пока не вижу изменений к лучшему. Поглядим, на длинном плече. И пока что все очень укладывается в ЕЕЕ.
По поводу модель изменилась… Рад за них. Прекрасно, они решили свои проблемы. Наверно. Но для меня эта их политика означает что такая вещь как сопровождаемость стала потреблять денег больше. А лишние расходы меня не радуют…
И добавлю. У каждого свое понятие свободы.
Кто то любит неотключаемую и не контролируемую телеметрию, кто считает что это посягательство на свободу и частные границы.
Каждому свое.
Это помогает, согласен.
Использовать же консоль при работе на большом проекте, с нормальным уровнем версионного менеджмента, и со сложной версионной политикой. Это себя не любить, банально не удобно и черевато ошибками
А уже разбор полетов…
Тут порекомендовали гит кракен, примкну к рекомендации, годная вещь, в сложных вещах не заменима.
Насчет пул реквеста не понял в чем проблема, у атласиона он нормальный, размер ревью не шибко на что влияет
Где? Подводный дата центр? Планшет с двумя экранами? Это изменения?
Когда тебе обновление винды сносит так пол винта, тебе как то не до подводного дата центра! Это изменения к лучшему?
Тотальная телеметрия — это изменение к лучшему?
Обновление и начинаться проблемы с печатью. Понятно, что виноваты пользователи, надо каждый месяц покупать новый принтер…
Итого, изменилось то что?
Просто оставлю это тут
Боже, какой бред. Мне вот интересно, когда появиться статься в стиле ISO vs Agile vs DevOps где автор воообще напишет про розового единорога в облачках.
А самое фиговое, что люди читают статьи и потом доказывают, что это лучшие практики!
Нет конечно, есть миф, что среда оооочень неопределенная. Определенная она вполне. Более того выполняя анализ, матрицы влияния в помощь, можно четко сказать где будет узкое звено. Собственно планирование релиза как раз в этом состоит, а не в том, что мы на демо покажем
Умеете предсказывать где узкое звено, значит понимаете где должен быть один буфер
Управляйте работой, а не людьми.
Что еще, в зависимости от релизов, узкое горлышко может быть в разных местах системы. PERT диаграммы вам в помощь.
И да это внезапно работа менеджера заниматься такими вещами и держать их в голове.