Agile *

Последние двадцать лет привели к серьезной трансформации технологического ландшафта и работы архитекторов, которые за ним должны следить. Архитекторы работают с технологиями и людьми. Компьютерные технологии за последние десятилетия значительно изменились и продолжают это делать. Люди меняются не так быстро. Однако, для работы с людьми выделяются новые роли: продакт-менеджеры, прожект-менеджеры, тимлиды. Роль и влияние архитекторов не так велико, как раньше, они становятся прерогативой больших компаний.

В статье попробуем разобраться действительно ли роль архитектора незаменима, для чего она нужна, как возникла и работает в реальном мире?

Более 10 лет я наблюдаю за процессом разработки программного обеспечения, как изнутри, так и со стороны. За это время я занимал различные должности, от джуниора до техлида, тимлида и менеджера продукта. Сейчас совмещаю всё понемногу.
Недавно менеджмент обратился ко мне с вопросом о том, как ускорить поставку ценности командой разработки.

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

Привет! Меня зовут Александр Апазиди, я руковожу в СИБУРе цифровизацией процессов головного офиса.

Сегодня я расскажу, как мы приводили IT-проекты в огромном нефтегазохимическом холдинге к одной модели, пытались примирить Agile и Waterfall, да и в целом, ускорить выполнение проектов.

С 2020 по 2022 количество наших IT-проектов увеличилось с 70 до 220, так что тема ухабистая. Приятного чтения!

5 методик, которые необходимо использовать продуктовому дизайнеру в 24-м

Практическое руководство по использованию фреймворков, которые помогут вам создавать лучшие продукты с разбивкой по этапам

Статья не претендует на научность, а просто рассказывает, как бывает в жизни, когда уже прошел все курсы, проверил разные гипотезы, но все еще получаешь новый опыт. На моем примере вы увидите как не нужно «впиваться» в конкретную фичу и биться с ней до конца, отпускать — это нормально, ошибки — это нормально.

• его изобрели на Тойоте;
• в нем есть доски и стикеры;
• там ограничивают количество незавершенной работы.

Что такое Agile? Как гибкие подходы могут помочь в работе, бизнесе или даже в обычной жизни? В этой статье вы узнаете, что Agile-принципам можно следовать даже при приготовлении новогоднего оливье. Будет полезно всем, кто хотя бы раз сталкивался с таким непростым делом, как подготовка новогоднего стола!

Всем привет! На связи снова Петрова Марина — QA Lead в Сloud.ru. Сегодня поделюсь опытом оценки и оптимизации процессов тестирования с помощью модели зрелости TMMi. Наша команда использует TMMi с третьего квартала 2022 года: за это время мы не раз оценили процессы и адаптировали модель для команд, которые работают в Agile-парадигме, но обо всем по порядку.

Привет! Это Дмитрий Гайдук, менеджер в АТОМе по корпоративным и онлайн-сервисам.

Каждое инженерное и программное решение в АТОМе – это отдельный продукт. Но если вырывать эти продукты из контекста, они останутся отдельными разрозненными решениями. Для нас крайне важно изменить само восприятие автомобиля и создать опыт, который задействует все сплетение новых технологий. Проекция дополненной реальности на лобовое стекло, голосовой ассистент, продвинутая система помощи водителю и множество других решений должны соединяться с эргономическими особенностями электромобиля, и только тогда они станут цельной экосистемой.

Как это работает?

Разберем на примере АТОМ-такси. Главная особенность этой модели – отсутствие переднего пассажирского кресла. Очевидное преимущество такого решения: у клиента больше места для ног. Менее очевидное: ничто не перекрывает обзор. Вид на город становится практически панорамным.

Ретроспектива. Новогоднее ретро. Как погрузить команду в Christmas mood?

Всем привет, это вторая часть статей о готовых шаблонах проведения ретроспектив. Эта статья посвящена новогодней рестроспективе. Новый год, декабрь месяц, подарки, глинтвейн, сугробы, «Гарри Поттер», «Один дома», селёдка под шубой…

Всё не перечислить, да и не нужно, ведь наша ретроспектива определит ваши планы на декабрь, январь и февраль. Да-да, это чистая правда.

Меня зовут Александр Шаповалов, я руководитель отдела разработки систем расчёта и доставки Mediascope. Количество людей и задач в нашем отделе росло постепенно. Когда в моей команде был только один сотрудник, было легко держать весь рабочий контекст на листке бумаги и в голове: аналитика, архитектура, стек, взаимодействие с заказчиком. Но когда нас стало больше 10, я заметил, что часть аспектов стала ускользать из фокуса. Любые ручные проверки для такого объёма задач не приемлемы, поэтому мы внедрили калибровку процессов с помощью метрик разработки.

У продуктового отдела нет выстроенных процессов? Задачи ставятся через почту? Приоритеты по задачам не очевидны и команда ощущает фоновый стресс? Руководство не устраивала скорость выполнения инициатив? Что же делать...? Об этом читайте в статье!

Как провести незабываемую ретроспективу с нуля? Нескучные ретроспективы. Ретроспектива, которую мы заслужили.

Часть 1 Packman. Пиксельное ретро.

Всем привет, меня зовут Иван. Сегодня я расскажу как подготовить тематическую ретроспективу на одном подробном примере. Из названия можно понять, что это первая часть и каждой следующей части будет уделяться разбор одной целой ретро-встрече, также вы по итогу сможете внести свои корректировки и даже я предложу несколько вариантов проведения одной тематической ретроспективы. Это статья подойдет для тех, кто только начинает свой путь как scrum-мастер, а также для тех, кто хочет повысить насмотренность и взять что-то интересное для проведения своих фасилитационных встреч.

Предлагаю занять чуть времени на определения и структуры ретро.

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

Меня зовут Дмитрий и я занимаюсь Agile трансформациями компаний и помогаю компаниям выстраивать процессы, а также являюсь основателем консалтингового агентства Smart units. Последние несколько лет выстраивал процессы заказной разработки, а также участвовал в крупных проектах реализации продукта вместе с вендором. И здесь набил много ошибок, а также сформировал набор правил того, как действительно нужно вести разработку продукта если вдруг вы являетесь либо Заказчиком, либо компанией которая предоставляет услуги по заказной разработки.

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

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

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

Спустя примерно два с половиной года и какое-то количество не самых удачных процессных экспериментов (например, OKR и квартальные цели) стало ясно, что что-то или сломалось, или изначально работало не очень хорошо. Вот примеры проблем, с которыми все четыре продуктовые команды (так мы называем ML-команды по разными направлениям - маммография, рентген лёгких, КТ лёгких, КТ мозга) регулярно сталкивались в пост-скрамной эпохе:

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

Меня зовут Артур Нек, я управляющий партнер Kaiten и Канбан-консультант. В статье на примере своей компании расскажу, как выстроить процессы в небольшой команде разработчиков, чтобы она оперативно обновляла продукт, но не выгорала.

Привет! Хочу поделиться парой мыслей о представлении нефункциональных требований в формате User Story. Вы наверняка помните самый распространенный шаблон для историй. В шаблоне есть три части «кто», «хочет что», «чтобы что». Чтобы соблюдать такой формат, важно выделить действующие роли и цели для каждой истории. Для нефункциональных требований это бывает непросто и я часто думаю: «А нужно ли?».

Майк Кон в своем блоге пишет, что нефункциональные требования хорошо ложатся в стандартный шаблон пользовательской истории и что такой шаблон позволяет не забыть, почему это требование появилось. В статье «Нефункциональные требования как пользовательские истории» (Non-functional Requirements as User Stories) приведены кейсы, среди которых есть несколько «синтетические». Например, на мой вкус странно выглядит история вида «Как человек, говорящий на одном из латиноамериканских языков, я, возможно, когда-нибудь захочу запустить ваше программное обеспечение». Как работать с такой историей в бэклоге? Сможет ли команда адекватно ее декомпозировать на атомарные задачи?

Обычно бывает интересно почитать не только саму статью в блоге, но и комменты к ней. В комментариях к статье Майка Кона как раз есть похожие вопросы:

Всем привет! Меня зовут Сергей Сжёнов. Более 15 лет я работаю в ИТ-индустрии, а сейчас отвечаю за развитие облачных продуктов в beeline cloud.

В этой статье хочу поговорить о product management, запуске цифровых продуктов, поделиться личным опытом и размышлениями. Материал будет полезен тем, кто только начинает свой путь в этом направлении, и тем, кто давно в деле.