Agile *

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

Как правило, если мыслить категориями гибких методологий задачи имеют иерархическую структуру, самые крупные - эпики, своеобразные вехи продукта, которые задают направление развития. Далее идут истории / фичи - законченные фрагменты функционала представляющие ценность. Внизу иерархии располагаются уже задачи предназначенные для конкретных исполнителей (аналитиков, дизайнеров, разработчиков). С моей точки зрения наибольшую ценность представляют исторические данные от том, на сколько точно команда попадает в оценку той или иной фичи. Однако точно оценить фичу целиком очень сложно, поэтому мы оцениваем только задачи нижнего уровня.

Большинство современных систем ведения задач позволяют не только фиксировать оценки и трудозатраты по конкретным задачам, но и агрегировать оценки подзадач в задачах верхнего уровня.

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

Для ведения задач в компании используется продукт JetBrains YouTrack, поэтому для решения проблемы трудозатрат списываемых в верхнеуровневые задачи было решено воспользоваться механизмом пользовательских рабочих процессов (в YouTrack можно писать свои собственные рабочие процессы на JavaScript).

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

Я записал свои мысли и делюсь ими с вами. Это довольно распространенная проблема. Задачи висят без движения, их всё время откладывают. В статье поговорим о последствиях такого беспорядка, и как правильно с этим справляться.

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

Изначально публикация должна была называться "Гре****е управление временем", что должно символизировать боль и проблемы связанные с этой активностью. Неумение решать тучу задач это очень неприятный ком в горле, мешающий находится на волне развития. Собрал методики, статьи и материалы, которые помогают мне в моем маленьком старте исследования.

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

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

Однако вокруг массового перехода компаний на Agile сложилось поверхностное понимание и неправильная интерпретация Agile подходов и философии. 

Более того, у многих компаний Agile превратился в карго-культ, который не просто не приносит ценности, а мешает.

В данной статье мы рассмотрим то, какой фундамент должен закладываться в компании, чтобы ей извлечь реальную выгоду от Agile.

В моей жизни произошло несколько событий, которые смотивировали меня создать самоорганизованную команду, которая могла бы самостоятельно следовать Скраму, соблюдать все события, эффективно работать и выполнять все задачи инкремента, не привлекая Product Owner для решения текущих проблем. Вот в таком случае мы можем говорить о Скрам-мастере как о сервисе. То есть Скрам-мастер как сервис — это когда ты приходишь в команду по какому-то запросу, помогаешь и уходишь. А команда остается одна, совсем одна, и ей должно быть абсолютно нормально. Всё так работает в идеальном мире, по крайней мере, должно так работать.

Привет, меня зовут Анастасия, я руководитель проектов в команде разработки Ареал. 

Моя ежедневная среда для управления проектами — задачник, оперативник, баг-репорт, gitlab с описаниями задач программистов, kaiten с описанием задач дизайнеров и проектировщиков. Мои коллеги сталкиваются с таким же “зоопарком” площадок, поэтому мы решили поэкспериментировать и свести управление в один инструмент — gitlab. Большинство команды знакомо с gitlab — программисты работают с кодом, проджекты ставят задачи. 

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

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

Меня зовут Татьяна Сеземина, я директор по управлению проектами Холдинга Т1.

Я вырастила команду с 40 до более чем 150 человек и не потеряла управляемости.

Сейчас расскажу, как мне удалось этого добиться.

Привет, Хабр! Хочу рассказать вам сегодня об одном инструменте. Он помог мне когда-то понять как устроены сложные организационные системы, как с ними работать, и самое главное, как их менять. Можно сказать, этот инструмент - линза, через призму которой мы можем по-другому посмотреть на окружающий нас мир.

Инструмент называется Айсберг системного мышления, и сегодня поговорим о нем.

Scrum, Kanban и другие «‎эталонные» методы ведения проектов далеко не идеальны и многое упускают. Поэтому они редко применяются в чистом виде: как правило, проджекты меняют эти практики под себя. При этом легко сломать то, что работает, ничего не исправить и испортить жизнь всем участникам проекта.

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

Спойлер: многие затронутые вопросы спорные, и готовых решений у нас нет (как, наверное, у большинства PM). Так что заранее приглашаем всех желающих к диалогу и обмену опытом в комментариях.

Привет!

Меня зовут Михаил, и больше 7 лет я занимаюсь улучшением рабочих процессов для малых и средних IT-команд. И конечно, для того чтобы понять что происходит в этих самых командах и процессах нужны правильно подобранные метрики, а еще лучше единая приборная панель, взглянув на которую и члены команд, и менеджмент могут сразу понять ситуацию, могут сразу найти зарождающиеся проблемы.

Про метрики отвечающие за скорость и качество доставки ценности всем давно уже всё известно, и как правило все стараются их отслеживать. Но сегодня я хотел бы сфокусировать внимание на метриках благополучия команд (Well-Being metrics).

Меня зовут Курдюмов Дмитрий, я сертифицированный Agile коуч и Лидер по трансформации бизнеса, последние 7 лет помогаю компаниям трансформировать их процессы и структуру для достижения большей адаптивности и скорости. В этой статье хочу поделиться тем, как Agile поменял принципы регулярного менеджмента в компаниях. 

Всем привет! На связи Сергей Гончарук, менеджер проектов компании «Флант». 30 ноября и 1 декабря 2023 года прошла конференция TeamLead++ Conf 2023. Ниже — текстовый вариант моего доклада с конференции про опыт «Фланта» в построении процессов управления задачами для Dev-части нашей DevOps-работы. 

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

▍ Разработка ПО — это исследование

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

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

Вопреки расхожему мнению, далеко не все компании занимаются разработкой софта.

Во многих крупных организациях Dev и Ops – это всего лишь одно структурное подразделение, так называемый Cost Center (то есть напрямую компании доходы не приносит). При этом одной из главных задач в Agile является обеспечение прозрачности процессов для всех заинтересованных сторон (stakeholders).

Сегодня в методах разработки ПО исключения не подтверждают, а скорее заменяют правила. Чистокровный Аgile днем с огнем не сыщешь ни в одной компании. Зато плодятся разные гибридные методологии. Некоторые проджекты задаются совсем уж крамольным вопросом: зачем нужны эталонные системы, если на практике все работают по-разному?

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

Спойлер: многие затронутые вопросы спорные, и готовых решений у нашей команды нет (как, наверное, у большинства PM). Так что заранее приглашаю всех желающих к диалогу и обмену опытом в комментариях.

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

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

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

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

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

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

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

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

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