Многие компании, успешно работающие по Agile в одной команде, сталкиваются с проблемой масштабирования. Когда число команд растет, а Agile-принципы не адаптируются на более высокий уровень, начинается хаос. Команды теряют синхронность, задачи не выполняются в срок, и возникают проблемы с прозрачностью процессов.
Чтобы справиться с этими вызовами, были созданы фреймворки масштабирования, такие как LeSS, SAFe и Nexus. В этой статье мы рассмотрим их основные принципы и рекомендации по применению.
В этой статье я поделюсь своим опытом адаптации стандартов Agile к реалиям своего текущего проекта；перечислю решения, которые продвинули мою команду вперед, призывая мыслить шире и проявлять креативность.
"Для них ты просто псих, как я. Сейчас ты им нужен, а надоешь — они тебя выкинут, как прокажённого. Их принципы, их кодекс — всего лишь слова, забываемые при первой опасности. Они такие, какими мир позволяет им быть."
В сфере IT, где ключевая роль отведена техническим навыкам и знанию инструментов, часто недооценивают soft skills, которые способны существенно повысить эффективность работы тестировщика и улучшить качество продукта.
Хочу рассмотреть, какие soft skills являются наиболее ценными для тестировщика. Ниже опишу, что выделяю для себя, как проактивный QA, в формате: качество – для чего нужно – как навык прокачать.
Кто-то может подумать, что «Звездная карта» — это список работников-звезд в команде. На самом деле, это эффективный инструмент руководителя для оценки компетенций сотрудников. Инструмент не новый и схож с матрицей компетенций, но при этом функциональный — отражает текущую действительность в режиме онлайн. Подготовили для вас лаконичный, но информативный обзор этого инструмента.
Привет, с вами команда “Инферит Клаудмастер”. Сегодня мы хотим рассказать вам о нашем опыте практического применения Канбан-метода в разработке. Для этого мы пообщались с Лилей Ермаковой, Service Delivery Manager, которая своими руками лидировала внедрение нового процесса.
Несколько дисклеймеров:
Мы все еще продолжаем наш путь в Скрамбан и не претендуем на завершенный и идеальный результат.
Мой рассказ в основном прикладной, поэтому Закон Литла, формулы и большую науку я затрагивать не буду. В конце статьи размещу ссылки, на ресурсы, наполненные хардкор статистикой и аналитикой.
Канбан, как замечают коллеги, — очень перегруженное слово. Задам координаты теории, на которую я ориентируюсь, — это материалы Канбан Университета и ProKanban.org.
Исходная ситуация
Мы одновременно тестировали две продуктовые гипотезы. Как иллюстрация к закону Конвея, у нас выросли две кросс-функциональные команды с разными культурами и практиками. В каждую команду включены бэкендеры, фронты, дизайнеры и тестировщики. Отдельно команды сопровождали системные инженеры, а также команды развития бизнеса и маркетинга.
Модули продукта завязаны на общие компоненты, при этом имеют собственную специфику и область применения: один модуль для аналитики, другой для автоматизации инфраструктуры.
Из этого вытекало два следствия: взаимозависимость работ в командах и специализация команд на задачах с разной спецификой.
Как был организован процесс?
У каждой команды своя культура, правила, длина спринта и свой продакт. Посередине — человек, который все объединяет в одно — Technical Product Owner. Если вы скажете, agile солянка, то будете правы. Релизы получалось делать раз в месяц (в лучшем случае). Помимо разработки, необходимо было объединить результат обеих команд и провести общее регрессионное тестирование.
Привет! Меня зовут Мария Болдырева, и я уже пять лет возглавляю проектное бюро WildTeam. До этого я работала главным конструктором в различных строительных компаниях. Ежедневно я сталкивалась с проблемами менеджмента в проектных компания и мечтала его изменить. В итоге взялась за дело и смогла, что коллеги из отрасли смотрят на нас с завистью Здесь буду рассказывать о своем опыте, команде, принципах и результатах, которые мы добились и по-прежнему добиваемся, ну и про факапы, тоже, конечно.
Когда я впервые предложила использовать Agile в инженерных проектах, коллеги смотрели с недоумением.
Зачем конструкторам, инженерам, архитекторам и проектировщикам Agile? Ответ для меня очевиден — чтобы лучше работать, не выгорать, расти скиллами и карьерно. Зачем это бюро? Чтобы делать крутые проекты, собрать крутую команду, где все на месте и счастливы, и делать еще больше крутых проектов.
Типичное проектное бюро это — иерархия, проблема с коммуникацией и вечно горящие … дедлайны. Например, босс ходит на встречи с клиентами, доносит мысль заказчика до исполнителей, и не факт что верно. Младшему инженеру нужно что-то сделать, а он ведь мог и не понять, а может ему и не верно передали, но спрашивать ему нельзя. Да и клиента переспрашивать неудобно. В итоге что-то делается, потом показывается, в итоге правки, дедлайны, стресс и ужас.
Понимая проблемы, я стала искать способы их решения! Вдохновения черпала из IT и идеи продуктовых команд с их уровнем эффективности.
Привет, Хабр!
Меня зовут Максим, и я более 6 лет работаю Frontend-разработчиком в IT-проектах и продуктах. За это время я насмотрелся на разные подходы к управлению задачами — от полного хаоса до сверхжёсткого контроля. И знаете что? Ни одна из крайностей не работает хорошо.
Сегодня хочу рассказать вам историю о том, как в одном проекте мы с командой пришли к методу работы с задачами. Он не только нас удовлетворил, но и дал понять что, как и когда мы будем делать ещё до этапа реализации.
Но давайте начнем с типичной ситуации в мире разработки...
Когда на новом проекте менеджер попросила меня провести эстимацию тестирования, я сначала растерялась, ведь это вроде как задача менеджера или старшего тестировщика. А потом вспомнила, что я – единственный тестировщик на проекте.
Привет! Меня зовут Артём Коньков, я тимлид команды продуктовой разработки в Купере. У меня в команде шесть разработчиков, по два на каждый стек: мобилка, фронтенд, бекенд и два QA. В статье расскажу о том, как, став тимлидом в уже почти сложившейся команде, менял систему оценки задач и переводил абстрактные сторипоинты в конкретные.
Дисклеймер: понимаю, что тема холиварная, и с точки зрения строгой методологии нужно выбрать между оценкой по времени или по сторипоинтам и не пытаться поженить одно с другим. У нас в компании допустимы разные варинты и я, как тимлид, очень рад, что такие решения даются на откуп юнитов и отдельных команд — можно настроить процессы под свою команду и свои задачи.
Здесь хочу поделиться своей логикой и тем, как искал аргументы, чтобы реализовать свой эксперимент. Любые менния по теме приветствую в комментариях.
Что для нас качественный бэклог? Под самим словом бэклог будем понимать список задач, в частности пользовательских историй, которые должна реализовать команда разработки в определенные сроки. Как правило, появляются они в результате декомпозиции функциональности. Что касается качества, то его основным критерием здесь будет результат выполнения этих задач. Другими словами, если мы достаточно точно, с учетом рисков и приоритетов, можем спрогнозировать сроки и результаты выполнения разрабатываемой функциональности, то бэклог можно назвать качественным. О нем и поговорим. На связи Владислав Филимонов, инженер-аналитик КОМПАС-3D.
Всем привет! Когда команды давно работают вместе по своим устоявшимся привычным процессам, любое вмешательство вызывает настороженность, а иногда и сопротивление. А уж интеграция крупного продукта в экосистему со сложившимися стандартами — всегда рискованное мероприятие. Эта задача усложняется еще больше, когда ей ставят сжатые сроки. Но нет ничего невозможного.
Меня зовут Ирина Васильева, и я старший Agile-коуч в МТС Live. В этой статье я расскажу, как мы провели Agile-трансформацию билетного оператора Ticketland. В процессе реорганизации мы навели порядок в задачах, сохранили команду и обеспечили сервису дальнейшее развитие в экосистеме МТС. На нашем примере я покажу, что любые изменения возможны, если декомпозировать основную задачу, наладить общение между командами и придерживаться выбранного роадмэпа. «Глаза боятся, а руки делают» — об этом я и расскажу под катом.
Всем доброе утро!
На связи вновь Крылов Александр и сегодня я решил поделиться мыслями по тому, как можно применить опыт DevOps Governance в Enterprice, который я ранее описывал в в этой статье. Прошло время и опыт был переиспользован для разработки продукта на примере компании Bimeister. А началось это аж в августе 2023 года.
Что тут важно сказать - нет, это не будет детальной расшифровкой с уточнениями доклада с DevOops 2023, с которым так же можно будет ознакомиться по ссылке выше. В данной статье я расскажу ряд аспектов отличия Governance в Enterprice и то, как он может выглядеть в компании разработчике своего продукта. Помимо этого, я так же расскажу, какие работы удалось провести за год в компании, а какие нет.
Начнем с того, что тема команды в целом, довольно сложный и многогранный вопрос, Который требует развития разных граней человека каждого члена команды, и в особенности, её лидера. От Эмоционального интеллекта и эмпатичности, до самокритики и самообладания.
Но современная культура корпоративного обучения и управления начала использовать это явление (команды), исключительно для манипуляций людьми.
«Мы же команда» заявляет ктоугодновышестоящий с целью вовлечь вас в решение задач компании, без уточнения, а нужно ли вам это, вообще. Особенно если задачи и начинания, о которых говорят, выходят за рамки должностных обязанностей.
Так вот ответственно заявляю, – нифига мы не команда, пока мы её не построили. Кто этим должен заниматься, и как? Этим должен заниматься руководитель, он же, по совместительству, лидер команды. Как конкретно этим заниматься, это тема для отдельной статьи, сегодня расскажем некоторые инструменты которые можно использовать и внедрять в рабочие процессы и правила команды, чтобы начать повышать эффективность коммуникации, и очерчивать границы командной работы.
Привет всем! Меня зовут Кирилл Ларьков, я Скрам-мастер банка ВТБ и работаю с сервисными командами. В этой статье я хотел бы поделиться опытом по прогнозированию задач в сервисных командах, которым ранее и в страшных снах не снилось слово "прогнозы". Формат для данной статьи я выбрал сторителлинг, так как подобный пошаговый гайд будет полезен начинающим командам, которые пытаются справиться самостоятельно с прогнозированием задач.
Привет, Хабр! Я Владимир Князев, Agile-коуч ОТП Банка. В этой статье хочу рассказать про нейромедиаторы, и как они влияют на нашу мотивацию.
Когда вы достигаете какой-либо большой и сложной цели, что обычно чувствуете? Радость, удовлетворение, или, может быть, состояние опустошенности?
В феврале 2024 года началось объединение Хоум Банка с Совкомбанком. Наши стримы стали интегрироваться в процессы СКБ, поэтому развитие текущей модели работы Хоум Банка стало не актуальным. В конце мая мы завершили все активности 4,5 летней SAFe-трансформации, в которой приняли участие более 1000 сотрудников, и готовы подвести итоги.
Меня зовут Олеся Мойса, я экс-RTE/Agile-коуч в Хоум Банке и совместно с Максимом Захаровым, ex-руководителем Agile-трансформации, мы коротко расскажем про наш путь и поделимся выводами. А в конце статьи будет анонс нашего выступления на конференции FlowDays, которая пройдет 13 сентября 2024 года.
Итак, ты решил сменить работу и исследовать для себя новые карьерные возможности на международном рынке. Английский на уровне В1+/В2, что уже само по себе заставляет тебя нервничать, ведь во всех вакансиях написано fluent English, а ты впадаешь в ступор от непонимания как правильно ответить на самый первый вопрос на собеседовании “Tell me about yourself”. А еще нужно создать достойное резюме и уметь рассказывать о своем опыте, чтобы повысить свои шансы. Всё это становится супер overwhelming, ты хватаешься за голову и понимаешь что не существует one-size-fits-all решения.
Здесь я уже рассказывала как структурно отвечать на вопросы рекрутера, но данная статья посвящена именно self-pitch. Я поделюсь 2 способами создания эффективной самопрезентации, а в конце статьи ты можешь забрать шаблон и использовать его для создания ответа на вопрос “Tell me about yourself”. Если ты уже сделал всё по шаблону или у тебя есть другая версия рассказа о себе, ты можешь написать лично автору и показать свой результат для обратной связи.
Как рассказать о себе? Способ 1.
Self-pitch - это продающая самопрезентация о себе. Самое важное что нужно запомнить - Product managers tell stories. Навык рассказывать истории (сторителлинг) просто необходим для эффективных ответов на вопросы собеседования.
Секрет классных историй позаимствуем у литературы/кинематографа. В оригинале это выглядит вот так, но мы немного модифицируем картинку.
Недавно методика планирования на нашем проекте изменилась. И жизнь команды тоже:) Что получится, если объединить «Тетрис» и Kanban, расскажу в этой статье.
В последнее время быстрыми темпами набирает популярность Agile, Scrum, Kanban, SAFe, LeSS и прочие гибкие «звери», о которых раньше, по крайней мере я, только слышал, и то в ключе «какой‑то там». Сегодня попробую разобраться, почему же это становится настолько популярным
