В ноябре выйдет новая версия TeamLead Conf 27.28.11.2024. Предпродажи уже идут! Проведём небольшой обзор предстоящего мероприятия и поговорим о звёздных докладчиках, которые подготовили для нас разборы самых насущных проблем. Например, как тимлиду добиться признания в команде? Или что делать с командой, когда тимлид ушёл? Как обучать взрослых людей? Как навыки тимлида видит СТО? И на сладкое — вся правда о биохакинге.
Эта статья для тебя, если ты когда-нибудь задумывался о том, сколько получают IT-специалисты в Германии и как это всё сравнить с зарплатами в России. Я расскажу про реальные цифры и поделюсь своим личным опытом переезда.
Я живу третий год в Европе. В апреле 2024 года я начал работать на позиции scrum master в компании ALDI SUD int в городе Мюльхайм на реке Рур.
Мой профессиональный опыт в роли scrum master на апрель 2024 составлял 5 лет.
Сравнивать будем на основе позиции на которой я работал и работаю - скрам мастер.
Цифры и порядок на этой позиции и на других в ИТ в целом соизмеримы.
Привет, Хабр! Меня зовут Светлана Болсуновская, я стратегический коуч-консультант в YADRO. Многие компании перешли на гибридный формат работы, где команды нуждаются в особом подходе для поддержания самоорганизации — процесса, при котором люди выполняют задачи без постоянного контроля руководителя. Я поделюсь своими наблюдениями, почему в современных условиях самоорганизация не происходит «магически» и что должен (и не должен) делать тимлид, чтобы помочь команде достичь этой цели.
Давайте посмотрим на выбор между Agile и классическим управлением проектами на примере постройки дома с участием козы, осла и муравья (добавим немного сарказма).
Пример: Постройка дома
👀 Классика:
Коза, осел и муравей решили построить дом. Они создали подробный план: где будет стойло для козы, спальня для осла и уютный уголок для муравья. Весь процесс расписан до мельчайших деталей, сроки строго установлены, и ничего не должно нарушить этот идеальный порядок.
Строительство началось по расписанию. Осел, конечно, сразу захотел бассейн, но муравей сказал: «Подожди, осел, сначала закончим крышу, потом — бассейн». Коза решила, что ей нужен балкон, чтобы наблюдать за закатом, но муравей снова был непреклонен: «Балкон только в следующем проекте. Сейчас у нас дом по плану!»
В итоге, дом был достроен. Осел получил спальню, но без бассейна. Коза — стойло, но без балкона. Муравей был доволен своим уголком, но коза и осел ворчали. Зато всё по плану! К сожалению, унитаз оказался в стойле осла.
👀 Agile:
Теперь представим, что коза, осел и муравей строят дом по Agile. Начали они с одной комнаты. Коза въехала в эту комнату и сразу заявила: «Мне тут тесно, хочу балкон!» Муравей записал это в задачи следующего спринта. Осел посмотрел на всё это и сказал: «Мне нужен бассейн, а то я вообще не перееду!»
Каждую неделю они что‑то достраивали и переделывали. Осел получил свой бассейн, но на крыше, потому что коза настаивала на балконе. Коза наконец‑то получила свой балкон, но из-за этого муравей потерял свой уголок и переехал в кладовку.
Представьте ситуацию: ваша команда только что выпустила новую версию продукта, а через неделю техподдержка завалена тикетами от недовольных пользователей. Знакомо, не правда ли? Сегодня недостаточно просто разрабатывать качественное ПО — нужно уметь эффективно поддерживать его и оперативно реагировать на изменения потребностей пользователей.
В этой статье рассмотрим, как интеграция подходов IT Service Management (ITSM) и Software Development Life Cycle (SDLC) может помочь создать цикл непрерывного совершенствования продукта. Разберемся, почему объединение этих практик — не просто модный тренд, а необходимость для компаний, стремящихся быть на шаг впереди конкурентов.
Этот список вряд ли является сборником моих собственных оригинальных мыслей. Он начинался как способ представить ценности и принципы Agile Manifesto более понятным и современным способом, хотя я и добавил в него несколько мыслей от себя. Он представляет собой снимок моего образа мышления в определенный момент времени, а не набор неопровержимых истин.
При выборе подхода к управлению процессами разработки многие задаются вопросом: какой метод лучше — Scrum или Kanban? Оба подхода популярны, но они различаются по своей сути и применению. Давайте разберёмся, как их правильно использовать и можно ли комбинировать.
Всем привет!
Сегодня я хочу обсудить важную тему, которая касается всех нас в сфере разработки ПО — методология Agile и ее влияние на тестирование. Внедрение Agile произвело революцию в процессе разработки, и тестирование не осталось в стороне. В этой статье я расскажу об основных принципах Agile, как они меняют подход к тестированию и какие преимущества это дает командам.
Надеюсь, эта информация будет полезной и вдохновит вас на внедрение Agile-подходов в свою практику!
Привет! Меня зовут Мария Болдырева, и я уже пять лет возглавляю проектное бюро WildTeam. До этого я работала главным конструктором в различных строительных компаниях. Ежедневно я сталкивалась с проблемами менеджмента в проектных компаниях и мечтала его изменить. В итоге взялась за дело и смогла, так что коллеги из отрасли смотрят на нас с завистью.
Здесь рассказываю о своем опыте, команде, принципах, результатах и факапах.
В прошлых колонках я говорила, как мы шли к новым принципам работы и Agile и к чему пришли. А сегодня расскажу, как мы функционируем и как Agile помогает добиваться успехов как командных, так и личных.
Предлагаю познакомиться с нашим опытом по внедрению метрик по JIRA для измерения продуктивности команды разработки 1С в компании Moex.
— Итак, скорость нашей команды - 100sp по результатам статистики нескольких прошедших спринтов. Все время мы берем в спринт задач по сумме больше нашей скорости. И все время в конце спринта у нас остаются задачи, которые мы пообещали выдать, но не закончили работу над ними. Давайте подумаем, как мы можем сделать так, чтобы мы успевали выполнять все, что заявляем в начале спринта?
Привет, Хабр!
В свободное от основной работы время за последние 4 месяца я разработал инструмент для управления продуктами без использования принципов Agile и Kanban. Вместо доски и тикетов разработка ведется вокруг фич и их итераций.
Мне очень интересно ваше мнение. Изначально я сделал продукт платным, но после того, как мне в клочья слили карму на Реддите за попытку прыгнуть на Канбан, я решил, что метод слишком радикальный. Поэтому я сделал сервис бесплатным, чтобы люди могли посмотреть и высказать свое мнение.
В разработке я руководствовался принципом бритвы Оккама, и отсек все, что могло бы отвлекать разработчика непосредственно от разработки. Поэтому в этом инструменте нет тикетов, эпиков, тасок, спринтов и так далее. Только фичи и их итерации.
Я также ввожу понятие технического урона вместо технического долга в качестве эксперимента, возможно, вам будет интересно.
Посмотреть можно здесь (только на английском): https://www.swinlanes.com, в том числе там есть ссылка на Handbook, в котором объясняется новый подход. Веб-приложение не заработает на телефоне, нужно будет зайти с десктопа.
Буду ждать вашего мнения.
Привет! Я Лена, ИТ-лидер 1С в Moex. Хочу поделиться историей, как я внедрила ретро в своей команде, не знакомой с ней и какие инструменты для этого я использовала.
Надеюсь, что мой опыт будет полезен как пошаговое руководство для начала проведения встреч Ретро в вашей команде.
Сегодня мы поговорим о таком интересном вопросе, как переход от Agile, к анти‑Agile. С течением времени команды часто сталкиваются с ситуациями, когда идеалы Agile начинают давать сбой, и приходит осознание, что работа по старым лекалам уже не приносит тех результатов, на которые мы рассчитывали.
Agile, безусловно, является одним из наиболее популярных подходов. Его суть заключается в гибкости и способности быстро адаптироваться к изменениям, что делает его идеальным для стартапов и ранних стадий продукта. Наверное, вы уже знаете эти принципы наизусть: взаимодействие с клиентом, работающие итерации, непрерывная поставка ценности.
Но давайте честно: Agile не идеален. На поздних стадиях разработки он может превращаться в настоящую головную боль. На этом этапе проект становится сложнее, требования начинают накладываться друг на друга, а команды, вместо того чтобы работать слаженно, часто начинают сталкиваться друг с другом. Сложно сосредоточиться на техническом долге, когда у тебя в голове только «первый спринт», «планирование» и «обсуждения».
Привет! Меня зовут Мария Болдырева, и я уже пять лет возглавляю проектное бюро WildTeam. До этого я работала главным конструктором в различных строительных компаниях. Ежедневно я сталкивалась с проблемами менеджмента в проектных компаниях и мечтала его изменить. В итоге взялась за дело и смогла, так что коллеги из отрасли смотрят на нас с завистью.
Здесь рассказываю о своем опыте, команде, принципах, результатах и факапах.
В прошлой колонке я говорила, как мы шли к новым принципам работы и Agile. А сегодня расскажу про принципы работы команды, общение с клиентами и мотивацию сотрудников.
Привет, меня зовут Никита, я — продуктовый дизайнер в Effective Technologies. На работе ищу и внедряю наиболее эффективные способы решения проблем бизнеса и пользователей, учитывая технические ограничения и имеющиеся ресурсы. В итеративном улучшении продуктов компании мне помогают CustDev, UX-тесты и исследования, валидация метрик. А ещё я занимаюсь социологией, тема моей кандидатской — трудовая мотивация. О ней мы и поговорим в этой статье. Как Agile влияет на мотивацию сотрудников? Спойлер: положительно, но при определённых условиях. Я остановлюсь на каждом из них и подкреплю свои выводы научными данными.
Современные компании стремятся повысить оперативность и гибкость в управлении ИТ‑услугами, чтобы быстрее реагировать на запросы бизнеса и улучшать клиентский опыт. Традиционные подходы ITSM (управление ИТ‑услугами) с их жесткими процессами и бюрократическими барьерами часто не справляются с этими задачами. Работа по Agile позволяет трансформировать управление ИТ‑услугами, делая его более эффективным и адаптивным.
Представьте концерт. Тысячи зрителей наслаждаются любимыми песнями, качественным звуком, впитывая энергию живого выступления. Но знаете ли вы, что звук, который слышат на сцене музыканты, совсем не похож на тот, что доходит до зрителей? Это результат работы системы сценического мониторинга — специального оборудования, которое позволяет каждому участнику группы слышать именно то, что нужно ему для идеального исполнения.
Привет! Нас зовут Катя Черных и Маша Вострикова, мы бизнес-аналитики в Х5 Tech. Мы любим инструмент User Story Map (карта пользовательских историй или USM), проводим по нему воркшопы в X5 и хотим поделиться своим опытом.
В статье рассказываем, как на этапе Discovery (начальный этап проработки задачи, на котором выявляются основные требования и анализируются поставленные бизнес-цели) прорабатывать большие инициативы, используя USM.
Фокус делаем на практическом использовании карты и на что обращать внимание при построении USM. Мы собрали возможные сложности, разобрали конкретные кейсы и описали варианты взаимодействия с заинтересованными лицами.
