Agile *

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

Это мой второй перевод и я позволю себе в этом предисловии пару предложений о том, зачем я потратил свое время на этот перевод:

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

Полезные борды и другие приёмы из личной практики.

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

Вместо предисловия

Agile. Кругом Agile. Наверное не осталось людей, команд и организаций, которые работают не по Agile. Слово «SCRUM» прочно вошло в жизнь разработчика. Я уже и не помню, была ли разработка иной. А когда спрашиваешь, почему у вас в организации насаждается Agile, в ответ получаешь либо цитату из эпиграфа, либо, если человек более откровенен, слова "так все делают". Ну не может же быть, чтобы миллионы мух ошибались то, что делают все, было ошибочным?

Но, как известно, есть некоторые особенные люди, которые могут попытаться проверить, ошибаются ли мухи верно ли то, что делают все? Приятно, черт возьми, ощущать себя особенным!

Для начала попробуем подсчитать стоимость ритуалов SCRUM

Я, как руководитель команды разработки, имею возможность видеть время, затрачиваемое командой на все активности. Вообще-то это одна из обязанностей руководителя разработки – контролировать командные затраты времени. И я могу довольно точно посчитать, во что обходятся команде ритуалы SCRUM. Можем посчитать вместе:

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

- планирование работ на будущий спринт. Тот самый процесс, где мы всей командой весело играем в карты. Обычно это занимает минимум 2 часа в спринт. Включает в себя декомпозицию задач из беклога, оценку и распределение. Да, в моей команде распределение проводится на планировании, нет такого, что на доске висят задачи, и сотрудники берут какую хотят.

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

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

Привет, Хабр! Я Ирина Бобрихина, один из скрам-мастеров IT-компании RDP. Хочу поделиться подробным кейсом проведения PI-планирования в крупной компании с помощью сервиса Kaiten.

Ещё больше интересных материалов читайте в нашем блоге.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

А с использованием методов линейного программирования.

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

В статье я поделюсь основными тезисами моего доклада, представленного на конференции Analyst Days #16. В нём я постарался показать, как методы линейного программирования могут быть применены в работе команды, живущей спринтами. Под катом вас ждет альтернативный взгляд на планирование спринта.