Agile *

Недавно методика планирования на нашем проекте изменилась. И жизнь команды тоже:) Что получится, если объединить «Тетрис» и Kanban, расскажу в этой статье.

В последнее время быстрыми темпами набирает популярность Agile, Scrum, Kanban, SAFe, LeSS и прочие гибкие «звери», о которых раньше, по крайней мере я, только слышал, и то в ключе «какой‑то там». Сегодня попробую разобраться, почему же это становится настолько популярным

Ценности Scrum из первых рук.
Джефф Сазерленд — один из создателей Scrum и авторов Agile‑манифеста — объясняет, что такое Ценности Scrum, и насколько они критичны для здоровых отношений внутри команды и достижения гибкости для бизнеса.

Получали когда‑нибудь от своих сотрудников подобные ответы? Особенно часто это бывает, когда речь идёт не о задаче в Jira, которая видна на доске, а о менее формальных договорённостях.

— прочитал доку к сегодняшней встрече? — не, не успел.

Если вы когда‑либо составляли резюме для работы в IT, вы наверняка слышали совет: пишите не о процессах (что вы делали), а о достижениях (что вы сделали и каких результатов добились). При этом достижения должны быть измеримыми, написанными по определенной формуле и содержать «сильные» глаголы.

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

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

Почему описание достижений вызывает сложности?

В статье хочу рассказать об оказавшемся полезном для нас решении — автоматизации внутрикомандных Stand-up созвонов. 

Привет. Я активно провожу собеседования с 2017 года на разные позиции. За период с 2022 по 2024 год провел больше 250 собеседований с scrum‑мастерами, agile коучами и руководителями agile трансформации. На прошлом месте работы кластер (на новом — домен) — это группа продуктов/платформ/сервисов. Они объединены вокруг пользовательского сегмента/индустрии или еще по какому‑либо принципу. В кластере/домене — от 300 до 1500 человек.

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

Вместо этих вопросов у меня сформировались другие: либо кейсовые (разбор реальной или вымышленной ситуации), либо блиц‑опрос на выравнивание. Многие кандидаты говорили, что такие вопросы как минимум интересны, а так же заставляют подумать, а не отвечать на автопилоте. Ниже я приведу примеры этих вопросов и расскажу, для чего их спрашиваю. Правильных ответов — нет. Важно понять, как думает кандидат и почему делает тот или иной выбор.

Этот опыт я описал для себя и напарников, и так же выкладываю кейсы в канал в telegram.

Сегодня мы рассмотрим методы формализации требований: Use Case и User Story. В статье рассмотрим оба метода, сравним их преимущества и недостатки. А также рассмотрим, когда и при каких ситуациях использовать каждый из методов.

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

Чтобы устранить этот пробел, лучше использовать системный подход, к примеру, ТРИЗ - теория решения изобретательских задач - для выработки более эффективных и инновационных ответов на вызовы.

Что такое ТРИЗ?

Про ТРИЗ можно рассказывать много. Но если коротко, то ТРИЗ - теория решения изобретательских задач, была разработана советским изобретателем и писателем-фантастом Генрихом Альтшуллером. Это инструмент решения проблем, анализа и прогнозирования, созданный на основе изучения закономерностей изобретательства. Основная цель ТРИЗ - создание алгоритмического подхода к изобретению новых и совершенствованию существующих систем. Он помогает выявить и разрешить противоречия и использует набор из 40 изобретательских принципов для поиска инновационных решений.

Давайте разберем, в чем преимущество метода ТРИЗ в достижении OKR.

Преимущество 1. Выявление реальной проблемы

ТРИЗ использует концепцию «идеального результата», чтобы сосредоточиться на том, чего команда действительно хочет достичь.

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

Определяя идеальное конечное состояние, команды могут выявлять и устранять коренные причины проблем, а не только их симптомы. Например, если команда стремится повысить удовлетворенность клиентов, ТРИЗ поможет определить, в чем заключается реальная проблема - в качестве продукции или в процессах обслуживания клиентов.

А в чем твой вклад как руководителя? ©

Как-то раз на перфоманс ревью был ошарашен отзывом одной из сотрудниц, назовём её Катя: не вижу вклад тимлида в работу команды.

На всякий случай, перфоманс ревью — процесс регулярной оценки сотрудников во многих компаниях, где учитывается мнение руководителя, коллег и подчинённых, если они есть.

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

В последнее время много обсуждаются разные новомодные методики управления проектами, Agile-методики, методики разработки продукта… Или не «методики», а «методологии»?.. Или «методы»?.. Как правильнее-то?

Вроде интуитивно разница чувствуется. И даже чувствуется, что в 90% случаев (в контексте управления проектами), эти термины полностью взаимозаменяемы. Но иногда, нет-нет, но все-таки вспоминаются слова из песни: «непонятно, что конкретно ты имела в виду»*…

Надо бы разобраться…

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

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

Мы привыкли жаловаться на бесконечные встречи и чаты, на то что не хватает времени на главное, всё занято текучкой. И даже воспринимаем это как данность, как необходимое зло, издержки профессии. Так ли это? Посмотрим, сколько рефально стоит коммуникация. Команде в целом, и руководителям лично. С помощью каких инструментов сократить эти расходы и какой выигрыш можно получить.

Друзья, привет!

Меня зовут Егор Пахомов, последние 3 года я работаю в Альфе: развиваю цифровые продукты в web- и mobile-каналах, управляю несколькими командами разработки. Ещё несколько команд собрал, организовал и бережно передал коллегам. Одновременно у меня в управлении было до 40 сотрудников: аналитиков, разработчиков, тестировщиков, дизайнеров.

Сегодня расскажу, что нужно, чтобы построить сильную продуктовую команду. После прочтения статьи вы будете чуть лучше понимать:

— На что обращать внимание на собеседовании и какие вопросы задавать кандидатам.

— С какими сложностями можно столкнуться при формировании команды.

— Как инженеры будут создавать продукт, а не просто выполнять таски.

— Как сформировать по‑настоящему сплочённый коллектив.

Будет полезно настоящим и будущим тимлидам, продактам, вникающие в Agile, тем, кто нанимает и собеседует или ищет работу в продукте и хочет понимать, на что смотреть в вакансии.

Теперь мы оцениваем баги через тг-бота, не тратим 2 ч. времени на встречи, фиксим самые критичные, но не теряем и минорные.

Современное развитие в области встроенной разработки и электроники с учётом бизнес-процессов ускоряется, часто следуя принципам Agile и Scrum. Применение этих методик требует осторожности из-за длительного производственного цикла встроенной разработки, который затрудняет быстрые изменения.

Меня зовут Арсентий Гусев, я руководитель группы embedded-разработки в отделе робототехники Яндекс Маркета. И мне бы хотелось рассказать об опыте, который приобрела наша команда в рамках работы над проектом складского робота. В этой статье определим критерии, предпосылки и предложим инструменты для ускорения разработки и снижения её стоимости.

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

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

Всем доброе утро! С Вами Крылов Александр, и мы продолжаем серию статей про DevOps as a Service, и как с помощью данного подхода возможно решить ряд распространённых проблем в организации работы подразделения. В прошлых статьях мы описали подход и показали пути решения часто встречающихся проблем. С данными материалами можно ознакомиться тут Часть 1, Часть 2, Часть 3, Часть 4, Часть 5. Сегодня мы обсудим создание площадки обучения DevOps в стенах компании для обмена опытом между коллегами разных подразделений, повышения компетенции и культуры обучения.

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

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

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