В этой статье — о том, почему доверие в команде не возникает автоматически и что на самом деле меняется, когда QA Lead перестаёт быть формальной функцией и становится менеджером, на которого можно опереться.
Есть такой специфический момент в жизни любой IT-компании, обычно за неделю до закрытия квартала. Графики в дашбордах вдруг начинают выглядеть подозрительно хорошо.
Велосити команды растет, таски в Жира отлетают в "Дан" как горячие пирожки, а GitHub окрасился в здоровый зеленый цвет ежедневных коммитов. Менеджер смотрит на это, смахивает слезу умиления, открывает праздничное шампанское и думает: «Ну наконец-то процессы заработали!».
Но чаще всего это означает, что команда просто поняла правила игры и начала играть не в разработку продукта, а в разработку отчетности.
И мы все это делаем не со зла, просто это очень дорогой билет на историческую реконструкцию феномена, который называется «Эффект Хоторна».
Вы не просили, но я вам сейчас покажу откуда все пошло.
В этой заметке описана концепция организации производства ПО «Merge Request как транзакция изменения системы, и где в ней возникает eventual consistency». Описывается идея, что МР должен содержать полный список изменений по каждой таске, какие плюсы и минусы этой концепции свойственны а также как её внедрять.
Периодически слышу, как мне говорят: «В Jira неудобно управлять бэклогом, стандартный список задач мне не нравится». Дело доходит даже до выписывания задач в Excel. Тогда зачем нам таск-трекер?
Сегодня попробую рассказать о решении, которым сам пользуюсь, а именно про применение Structure.
Стартапы гордятся своей свободой и отсутствием жёстких правил. В свою очередь, чем крупнее становится компания, тем больше она нуждается в корпоративной культуре и правилах работы. Из первичного бульона хаоса, устных договорённостей и личных связей неизбежно формируются рельсы рабочих процессов в виде событийно-ролевой модели и рабочих артефактов. Другими словами, субъекты и объекты трудовых будней компании.
Меня зовут Евгений Иванов, я Agile Cluster Lead кластера Облачные технологии в компании MWS Cloud — команды, которая создала MWS Cloud Platform. И в этой статье я расскажу, почему мы считаем наш кластер анклавом процессных практик и какие плюшки и сложности мы с этого имеем. На тему наших процессов мой коллега Саша Стерлигов уже написал подробную статью. Почитайте.
Наверняка вы сталкивались с проблемой согласования фичи со службой безопасности. В большинстве случаев этот процесс превращается в головную боль для программиста из-за множества непонятных этапов и деталей.
Регулярно встречая подобные проблемы в своей работе, мы во Flowwow решили внедрить процесс, который помог не только снизить на треть количество времени на анализ корневых причин сложных инцидентов, но и значительно упростить согласование фич для программистов. Этот процесс получил кодовое название ADR.
В крупных проектах управлять качеством вручную — весьма нетривиальная задача: объем требований и фичей, уточнений и доработок, баков и фиксов растет нелинейно, а риски — экспоненциально. В таких условиях необходимо структурировать процесс обеспечения качества (QA), чтобы предотвратить эффект «снежного кома», который может «завалить» тестировщиков — сначала фрустрацией от рутины, а потом недовольством заказчика.
Привет, я Владимир Князев, Agile-коуч трайба HR Tech в ОТП. В прошлом году мы активно собирали новые команды. Наш трайб вырос почти в три раза: с 13 до 38 человек. У новых ребят в команде было много вопросов о том, кто за что отвечает и к кому идти, если коллега в отпуске или заболел.
Так мы пришли к внедрению RACI-матрицы. Это один из тех инструментов, которые сначала кажутся бюрократией, но после внедрения начинаешь удивляться, как раньше работали без него. В этом посте я расскажу о том, как матрица помогла нам организовать работу в команде.
Привет, Хабр.
Меня зовут Михаил, я технический автор, работаю с инструментами тестирования в команде ТестОпс. В какой-то момент мне стало интересно — а как получила распространение мысль о том, что разработчикам тоже надо писать тесты?
У меня было смутное представление о некотором тёмном «раньше», и условно-ограниченно-просвещённом «сейчас», когда мысль о том, что тестирование не должно жить отдельно от разработки, кажется, стала нормальной.
Мостик между этими двумя мирами — автотесты, они нужны и тестированию, и разработке. Фреймворк JUnit сознательно писали как можно более простым — в первую очередь для того, чтобы сделать его повседневным инструментом для разработчиков. Люди, работавшие с первыми фреймворками автотестирования, стали также авторами подходов экстремального программирования (XP) и разработки через тестирование (TDD) — т. е. подходов, настаивающих на том, что тестирование — это не «обязаловка», а интегральная часть разработки.
С учётом этого, я решил заняться «археологией» автотестирования: посмотреть на прародителя современных фреймворков xUnit, SUnit для Smalltalk. Я хотел потрогать его руками, а также понять, что двигало его автором. В результате получилось довольно интересное путешествие, которым я хотел бы с вами поделиться.
Вначале я посмотрю на то, что из себя представляло автоматизированное тестирование в 1990-е. Чтобы понять, что добавил SUnit, попробую запустить на нём несколько примитивных тестов. А потом посмотрю, что можно наскрести по сусекам интернета о мотивации создателей и пользователей. Как они пришли к тому, что барьер между разработкой и тестированием надо преодолеть? Сам я не был участником этого процесса (годами не вышел), так что придётся опираться на вторичные источники.
Trello долгое время был удобной и устойчивой основой для российских команд, но сегодня, по моему опыту, он всё реже воспринимается как надёжный элемент рабочего стека. Этап срочной миграции уже пройден, и в 2026 году ключевой вопрос — не куда переехать, а какой инструмент можно использовать в долгую без продуктовых и инфраструктурных рисков.
Решил поделиться одной точкой зрения, которую заметил на радарах уже давно, по поводу прокрастинации как на работе, так и в личных делах. Тема кажется мне актуальной, потому что сам подвержен подобному конфликту и многие команды в компаниях, с которыми провожу общение.
Представим: важная задача висит в списке, дедлайн маячит, ты понимаешь, что делать её надо прямо сейчас…
Именно в этот момент ты:
Представим ситуацию: команда управляет проектом на Agile-доске. Чем больше задач одновременно в работе, тем медленнее они завершаются. Без четких ограничений инструмент быстро превращается в полотно из заданий: сложно понять, что важно и приоритетно, а что застряло и требует вмешательства.
Разберем, что такое WIP-лимиты, как они помогают управлять нагрузкой и поддерживать предсказуемый темп работы.
Онлайн-календарь давно перестал быть простой сеткой с датами и превратился в полноценный инструмент планирования. Он помогает управлять расписанием, синхронизировать события между устройствами и работать вместе с командой.
В обзоре сравниваем десять популярных сервисов по ключевым критериям: функциональность, удобство, командные инструменты, интеграции, цена, платформы и доступность в России.
Материал помогает быстро определить, какой календарь лучше всего соответствует вашим задачам или рабочим процессам, и избежать ошибок при выборе.
Стабильность E2E-тестов: как добиться 100% успешных прогонов ?
Практика, проверенная на реальном проекте.
Флаки-тесты убивают доверие к автоматизации. В этой статье — проверенные подходы, которые помогают превратить нестабильные E2E-прогоны в надёжный инструмент проверки продукта.
Оценить проект «на берегу», когда требований почти нет, команды ещё нет, а ответ нужен к завтрашнему совещанию, — это не инженерия, а гадание с серьёзными последствиями. В статье разбирается практичный способ превратить туман неопределённости в расчёт: как декомпозировать работу по пользовательским функциям, считать оценки через PERT и показывать стейкхолдерам не «одну цифру», а диапазон с уровнем уверенности.
Привет, Хабр! Меня зовут Таисия Брезгина, я Enterprise Agile coach в МТС Web Services. У нас в компании выстроена система поддержки команд, и ее важная часть — регулярная диагностика. Мы используем много разных инструментов, для того чтобы выявлять слабые места и дисфункции и за счет их решения растить эффективность команд. Хочу поделиться инсайтами в работе своей небольшой команды скрам-мастеров и аджайл-коучей. Какие инструменты у нас действительно работают и почему важен комплексный и кастомизированный подход, а не бездумное внедрение инструментов и методов.
После 2022 года выбор системы управления проектами в России перестал быть вопросом цены или количества функций. На первый план вышли доступность, юридическая корректность и предсказуемость работы. Многие зарубежные сервисы требуют VPN, не принимают оплату, ограничивают функциональность или в любой момент могут перестать работать — а для рабочих процессов это критичный риск.
В этой статье мы рассматриваем только те инструменты, которые в 2026 году официально работают в РФ, доступны без обходных решений, позволяют легально оплачивать подписку, обеспечивают корректный документооборот и продолжают развиваться.
Фокус — не на «бесплатно или платно», а на том, можно ли на системе строить работу сегодня и через год, не опасаясь блокировок, санкций и инфраструктурных сюрпризов.
Привет, Хабр! Мы, Максим Соловьев, руководитель Эджайл-офиса Департамента корпоративного развития РСХБ, и Наталья Кушнарева, лидер стрима «Ипотека в цифровых каналах» РСХБ, в этой статье расскажем про производственные метрики эффективности работы команд и их применение в Эджайл-практике Россельхозбанка.
Привет, Хабр! Меня зовут Иван, я руководитель отдела тестирования фронт-офисных и интеграционных систем в РГС.
В этой статье я хочу посмотреть на ключевые ценности Agile не сквозь розовые очки, а через призму управленческой практики. Разобрать, как они на самом деле работают, где помогают, где ломаются и что с этим делать тем, кто отвечает за результат.
Всем привет! Меня зовут Артем — за последние 10 лет поработал в больших компаниях, стартапах, консалтинге на позиции продакта и проджекта. Сегодня расскажу про мой подход работы с бизнесом и технической командой и про то, как превратить хаотичный поток задач в предсказуемый фреймворк.
В моей профессии Roadmap — ключевой артефакт. И при правильном формировании он способен выводить продукты из хаоса в предсказуемость. Дорожная карта не про сроки, а про баланс интересов — прикладная часть этого тезиса как раз и будет раскрыта в статье ниже.
Поработав в разных доменных областях я видел десятки команд, которые работали в постоянном пожаре. И везде проблема была одна и та же: никто не понимал, что мы делаем завтра и почему именно это.
Тогда я пришел к фреймворку «Квотирование» — методу, который делает дорожную карту предсказуемой в любой среде: в стартапе, enterprise, консалтинге.
Лучше всего, перед формированием дорожной карты использовать RICE для расстановки приоритетов, а только потом положить задачи на дорожную карту.
