Agile *

Хабр, привет! Я Саша, Product Manager в Ozon. Хочу сегодня поговорить с вами об исследовании зависимостей между подсистемами проекта, в частности, и повышении прозрачности процессов в разработке в общем.

Обычное дело: в команду приходит заказчик, приносит суперзадачу — киллер-фичу, которая по приблизительным оценкам будет приносить не меньше N денег в секунду. Очень важная и нужная штука. Потом проходит 3 месяца, а фича так и не появляется на проде. Более того, команда к ней так и не приступала. 

Почему? 

– вместо суперзадачи команда занимается какой-то ерундой — проблемы с приоритизацией;

– команда не поняла, что фича принесёт реальные деньги и насколько это важно — сложности с коммуникацией с заказчиком;

– недостаточно описаны требования, команда отфильтровала задачу как «не готовую к взятию в работу» — продакт не доработал;

– задача потерялась в недрах бэклога — продакт проглядел.

Все эти варианты говорят нам о наличии рассинхрона команд, ожиданий и реальности, рассинхрона подсистем относительно общего процесса, вследствие этого команда(ы) делает «не то» «не так» или не делает вовсе.

Давайте разбираться — расскажу вам об инструменте, который поможет выявлять приводящие к подобным ситуациям серые зоны, нестыковки, зависимости между подсистемами проекта; поможет всё это дело визуализировать и анализировать. Инструмент я назвала картой зависимостей.

Всем привет! Меня зовут Анна Мозер, я работаю тимлидом системных аналитиков в X5 Tech. Мне удалось поработать и в корпорации, и в стартапе, и в качестве фриланс Delivery Manager на этапе запуска стартап команды. 

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

Периодически мои друзья, знакомые, коллеги в кулуарах делятся тем, что процессы в их командах напоминают хаос. Они говорят: "Мы только и занимаемся тем, что тушим пожары" или "Я не знаю, чем буду заниматься на следующей неделе". И моё самое любимое: "Мы начали делать задачу, а на полпути потребности поменялись, и теперь нужно совсем другое. Но это же Agile…".

Хотя многие менеджеры объясняют это стремлением к гибкости и следованием Agile-философии, чаще всего такие признаки указывают на неправильное понимание и применение гибких методологий. Цель моей статьи – подсветить типичные ошибки менеджмента команды и рассказать об индикаторах того самого "недопонятого" Agile (я насчитала таких 10 штук). 

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

Получилось забить гвоздь молотком – получилось. Давайте попробуем с помощью молотка почистить фарфоровую посуду от налета. Ну очевидно же!

Не избежал этой участи и пресловутый Agile. Так называемые гибкие методологии разработки. Сработало в узком сегменте простых IT проектов – давайте везде его применим! В промышленности, в обучении – всюду, куда фантазии хватит его вставить.

А по факту – любой инструмент имеет ограниченную среду применения, и гибкие методологии – не исключение.

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

Забегая вперед, могу сказать, что в итоге мы внедрили платформу в 18 странах присутствия заказчика, у нас на поддержке было около 10 тысяч касс в 379 магазинах. Мы выпустили 39 релизов, 82 патча и 73 хотфикса. И во всем этом нам очень помогал SAFe. Почему мы выбрали именно этот фреймворк, как внедряли в процесс международного проекта, что мы из него вынесли и при чем тут поезда, решил рассказать в этой статье.

Привет, меня зовут Дима, я ведущий ИТ бизнес-партнёр в Петрович-Тех. Сегодня расскажу вам историю о том, как мы запускали продуктовый подход в инхаус-разработке.

В 2020 году задачи бизнеса сыпались в «общий котел», коллеги из бизнеса буквально бились за ИТ-ресурсы по принципу «чьё важнее». Команды разработки формировались по принципу «кто делал что-то похожее», оценки делались примерные, с умножением на «пи» или на «е».

Эта статья о том, как мы разбирали 1С УТ на продукты и сервисы, запускали “почти что Scrum-подход с элементами Kanban”, учились отвечать на вопросы “сколько ждать хотя бы примерно?” и “когда уже будет готово?” через метрики и перцентили – и как в конечном итоге благодаря продуктовому подходу нам удалось удвоить пропускную способность команд.

Преодоление вызовов и максимизация выгод: история разработчика с SAFe

В современной сфере программной разработки методология SAFe (Scaled Agile Framework) выросла в нечто большее, чем просто структура. Она стала ориентиром для компаний, которые стремятся улучшить свои процессы и достичь масштабируемости. В этой статье я расскажу о нашем опыте перехода на SAFe и о том, как этот фреймворк изменил нашу парадигму разработки программного обеспечения для сетевого оборудования. Я, простой разработчик, поделюсь с вами историей, как SAFe повлиял на нашу компанию и почему я уверен в его огромном потенциале.

Всем привет! Меня зовут Дмитрий, я более 7 лет занимаюсь трансформациями компаний и построением процессов в области создания продуктов и управления проектами с помощью Гибких подходов управления Agile. Недавно меня пригласили в один развивающийся американский стартап, который делает SAAS B2B продукт.

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

1. Модели архитектуры программного обеспечения как код, построенные с использованием Structurizr Lite
2. Документация, созданная с помощью шаблона Arc42
3. Журнал решений, созданный с помощью ADR Tools

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

"Преимущество Scrum-команд — способность к обучению", — часто ли слышали такое? Звучит как суперсила из комиксов Marvel! Только представьте, вместо "человек-паук" у нас "человек-скрам", который вместо паутин метает стики-ноты и вместо борьбы с преступностью учит нерадивых разработчиков, не желающих понимать скрам-магию!

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

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

Всем привет, я Карим Аминов, Head of QA в компании Test IT. Цель моей статьи — помочь наладить вывод релизов качественно и в срок всем, кто так или иначе связан с обеспечением качества на проекте. Также я надеюсь, что мой рассказ найдет отклик у всех, кто занимается релизами. 

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

В системах управления проектами меня всегда интересовал один вопрос – почему растет система. В статье я попыталась связать рост с набором киллер-фичей: иногда они маленькие, совсем незаметные, но встречается, когда убойная фича — это сам продукт.

Для этого материала я опросила CPO, продакт-менеджеров и директоров по маркетингу российских систем – как они собираются съесть рынок, в чем их главная киллер-фича. Результаты смотрите ниже. А для тех, кто не хочет читать 15 страниц текста, подбила сводную таблицу в конце.

P/s 2022 год – это катализатор (ушли многие зарубежные системы), поэтому в статье привожу цифры, как каждая из систем выросла за этот год. Данные брала из системы “ЗА ЧЕСТНЫЙ БИЗНЕС”. Единственное, я не учитывала инфляцию.

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

В нашем новом интервью для блога Comindware на Habr.com, Алина Балашова, опытный Scrum-мастер из Comindware, раскрывает детали своего опыта.

Привет! СИБУР — не просто одна из крупнейших нефтехимических компаний мира, это в принципе довольно большая компания с кучей разных процессов, множеством людей (как штатных специалистов, так и постоянных внешних подрядчиков). А еще — с большим количеством разных продуктовых команд, которые трансформируются, масштабируются, обмениваются разработчиками и аналитиками, в общем, всё это весьма динамично, быстро и всегда затачивается под конкретную задачу.

В этом посте мы хотим побольше рассказать о том, как у нас всё устроено. Команд у нас много, как и используемых или стеков, так что говорить будет и верхнеуровнево, и на примере конкретной команды CRM.

Потому что CRM – это «скелет» сквозного процесса продажи и обслуживания клиентов. И там, как в едином котле смешиваются воедино и сложные задачи для разработчиков (попробуй всё интегрируй, как надо, и сделай так, чтобы работало), и для аналитиков, а сколько тут чисто бизнесовой части и тонкостей в процессах — вообще туши свет.

Под катом:

• как устроено взаимодействие между командами;

• что ждет новичка, пришедшего работать в СИБУР;

• какие есть пути развития карьеры в целом и своих навыков в частности;

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

• почему у тестировщика в целях вполне себе может быть конверсия интернет-магазина (и это нормально);

• почему B2B-рынок интереснее, чем пресытившийся B2C.

Слово «ретроспектива» произошло от латинского “retro” – «обратно, назад» и “spectare” – «смотреть, созерцать», то есть буквально оно означает «Взгляд в прошлое». 

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

Всем привет, меня зовут Саша Комбаров, я исполнительный директор в веб-студии. В материале расскажу, что такое ретро, зачем и как проводить ретроспективу и как мы проводим собрания по методу «Четырех Ч». А также расскажу, как мы внедрили ретро в отделы компании: управление, дизайн, маркетинг, продажи, тестирование и аналитика. И что это дало :)

«Архитектура с эволюционным развитием поддерживает управляемые, постепенные и последовательные изменения сразу в нескольких направлениях».

Из книги «Эволюционная архитектура. Поддержка непрерывных изменений»

Более 5 лет мы развиваем бесплатное мобильное приложение для работы с товарами. Проект растет и стабильно приносит прибыль, на прод поставляются новые фичи. Но мы заметили, что ежемесячно команда не успевала выполнить 100% из запланированного пула работ. Каждый раз, как по замкнутому кругу, мы пытались ответить на вопрос: «Как так получилось и когда, что мы опять одну фичу не допилили?». Но все встало на свои места, когда мы внедрили процесс капасити в работу и прозрачность загрузки команды стала явной.

Я менеджер проектов в SimbirSoft Светлана, и в этой статье поделюсь опытом подсчета капасити команды и предложу свой вариант работающей формулы, опираясь на свой опыт.

Все, кто занимается разработкой программного обеспечения, так или иначе слышали про Kanban или применяли его в работе. Это — инструмент методологии Agile, который подходит для своего круга задач.

Но Kanban придумали совсем не разработчики: еще 60 лет назад его внедрила компания Toyota на своем производстве. И он стал частью общей философии компании, которая получила название Lean Manufacturing — «бережливое производство». Успехи Toyota и ее подхода очевидны: на 2022 год компания занимает первое место в мире по числу проданных автомобилей — 10,48 млн, опережая Volkswagen AG на 2,22 млн штук.

И между производством автомобилей и разработкой ПО напрашивается параллель. Давайте попробуем разобраться, в чем же особенности TPS (Toyota Production System), откуда все это появилось и как применяется в современной разработке.

Всем привет, меня зовут Андрей Гирин, и я agile-коуч в РТЛабс. Десять лет назад я был руководителем проекта с небольшой командой, а сейчас помогаю строить команды другим.

Недавно я был с воркшопом, посвящённым star map, на профессиональной конференции для тимлидов Saint TeamLead Conf, о чём моя коллега Екатерина не так давно писала в посте.

Эта небольшая статья о том, как и почему эта идея вообще появилась.

Австралийский Atlassian, разработчик Trello и Jira, вынес последнее предупреждение: «Осталось 30 дней». Потом все данные пользователей из России и Беларуси будут удалены. Многие мои знакомые до последнего надеялись, что этого не случится, а сейчас срочно ищут, куда переехать. 

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

В современной IT-индустрии эффективное управление проектами и продуктами играет ключевую роль в достижении успеха. Два основных игрока в этой области - Product Owner и Project Manager - имеют разные задачи и ответственности, но тесно сотрудничают для достижения общей цели. Давайте рассмотрим различия между ролями Product Owner и Project Manager, а также их взаимосвязь в контексте IT-проектов.