Agile *

Привет, Хабр.

Меня зовут Михаил, я технический автор, работаю с инструментами тестирования в команде ТестОпс. В какой-то момент мне стало интересно — а как получила распространение мысль о том, что разработчикам тоже надо писать тесты?

У меня было смутное представление о некотором тёмном «раньше», и условно-ограниченно-просвещённом «сейчас», когда мысль о том, что тестирование не должно жить отдельно от разработки, кажется, стала нормальной.

Мостик между этими двумя мирами — автотесты, они нужны и тестированию, и разработке. Фреймворк 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 для расстановки приоритетов, а только потом положить задачи на дорожную карту.

Вопрос выбора системы управления продуктовой командой перестал быть теоретическим упражнением. Jira больше не обновляется, техподдержка молчит, а требования к импортозамещению никуда не делись.

Тысячи команд одновременно столкнулись с необходимостью искать альтернативу, причём желательно не методом научного тыка.

История с Jira — это не просто уход очередного западного вендора с российского рынка. Это идеальный шторм из трёх факторов, которые делают дальнейшее использование системы проблематичным даже для тех, кто готов работать на старых версиях.

Для понимания меня, наверно нужно знать мой путь разработчика.

Закончен университет Имени Ярослава Мудрого в Великом Новгороде по специальности радиотехника.
Практика в КБ Планета, диплом считыватель R-FID меток. защита на 4, кажется никто не понял с моих слов сути устройства и каков был мой вклад.

первая работа:
2010 год сентябрь трудоустройство в НПК СПП в отдел систем видеорегистрации

мы делали видеорегистраторы полетной информации для Сухих и других крутых КБ

дальше меня после 9ти лет стажа и отсутствия перспектив из-за карьерных косяков закинуло в Diakont в 2020 году мы переехали с женой под рождение сына в Алмазово но это отдельная история...

Началась разработка средств доставки и диагностики бесконтактным методом ЭМА и другими...
Роботы были разные, все внутритрубной диагностики. Самый пик и интерес был робот для Малазийцев в проекте стоимостью в 300+ мультов русских. И даже некоторые из команды побывали в Куала-Лумпур, но не я...

Когда я решил выстроить систему планирования в Obsidian, я начал документировать: что я делаю в течение рабочего дня, с какой информацией работаю, где её ищу, как принимаю решения.

Когда у команды большой бэклог задач, как решать, в каком порядке их делать? Привет, я Владимир Князев, Agile-коуч трайба HR Tech в ОТП. Сегодня я кратко расскажу, как трайб HR Tech использует приоритизацию ICE.

У нас в трайбе всё как у всех: заказчиков много, запросы сложные и разные, а задач больше, чем мы можем физически сделать. Чтобы упростить работу команды над ними, мы решили внедрить приоритизацию по методу ICE.

Последние 2 года я выстраивал и непрерывно улучшал собственную систему планирования в Obsidian. За это время я обнаружил кое-что важное, что решил разделить с сообществом.

И вот что я заметил: почти все, кто пытается выстроить систему управления, начинают с одного и того же вопроса — «Какой инструмент мне взять?» Notion? Jira? Obsidian? Linear? Асана?

Тут я всегда отвечаю одно: выбор инструмента — это последний вопрос, а не первый.

Управление целями нужно не ради красивых слов, а чтобы соединить долгосрочные планы с ежедневной работой. Когда понятно, ради чего ставятся задачи и как их выполнение влияет на общий результат, команда чувствует, что двигается в одном направлении. Руководители при этом видят реальную картину, а не набор несвязанных отчетов.

В статье мы разложим по полочкам четыре ключевые методологии целеполагания — MBO, KPI, OKR и BCS — покажем, как они помогают связать стратегию с повседневной работой, и дадим полезные инструменты управления целями, чтобы бизнес шел по курсу, а не дрейфовал. 

Выбираем архитектуру по кайдзен: на что обратить внимание

Я часто замечаю одни и те же ошибки в различных решениях — как по работе, так и в жизни. Зачастую многие думают, что сейчас сделают прототип, а потом допилят, но не учитывают, как будет развиваться решение и что лучше взять за основу. Поэтому эта статья будет полезна не только архитекторам при выборе основы, но и разработчикам для понимания более важных и ценных задач. А также проектным менеджерам — чтобы создать верную стратегию развития.

Предлагаю разобрать на примере подход выбора архитектуры для продукта!

В последнее время тема лидерства в IT компаниях потерялась в потоке энтузиазма, вызванного безграничными перспективами отрасли. Лидерство, конечно, фигурирует в современных методологиях типа Agile и DevOps, но при этом не наделяется достаточной силой, чтобы выполнить свою трансформационную роль. Лидерство выглядит как Золушка с неочевидным для всех королевским потенциалом. Эта статья возвращает лидерство на пьедестал, обосновывая его уместность именно для IT. Речь здесь идет о таком лидерстве, которое одержимо незаурядным результатом в равной степени, как и опорой на смыслы и человеческое достоинство и не имеет ничего общего с расхожим «лидерством», которое практически равнозначно понятию «руководитель». За таким подлинным пониманием лидерства, стоят хорошо известные с 70-х годов принципы трансформационного лидерства Джеймса Бернса и Бернарда Басса. В период индустриальной эпохи эти принципы использовались факультативно, хотя и с большим успехом. Лидерство в компаниях стало притчей во яцызах , но не возобладало в традиционном менеджерском управлении. Эра информационных технологий делает трансформационное лидерство в IT компаниях безальтернативным. Эта статья не про теоретические изыскания на будущее, а про достижение незаурядных результатов в настоящем.