Agile *

Привет, Хабр!

Меня зовут Максим, и я более 6 лет работаю Frontend-разработчиком в IT-проектах и продуктах. За это время я насмотрелся на разные подходы к управлению задачами — от полного хаоса до сверхжёсткого контроля. И знаете что? Ни одна из крайностей не работает хорошо.

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

Но давайте начнем с типичной ситуации в мире разработки...

Когда на новом проекте менеджер попросила меня провести эстимацию тестирования, я сначала растерялась, ведь это вроде как задача менеджера или старшего тестировщика. А потом вспомнила, что я – единственный тестировщик на проекте.

Привет! Меня зовут Артём Коньков, я тимлид команды продуктовой разработки в Купере. У меня в команде шесть разработчиков, по два на каждый стек: мобилка, фронтенд, бекенд и два QA. В статье расскажу о том, как, став тимлидом в уже почти сложившейся команде, менял систему оценки задач и переводил абстрактные сторипоинты в конкретные.

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

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

Что для нас качественный бэклог? Под самим словом бэклог будем понимать список задач, в частности пользовательских историй, которые должна реализовать команда разработки в определенные сроки. Как правило, появляются они в результате декомпозиции функциональности. Что касается качества, то его основным критерием здесь будет результат выполнения этих задач. Другими словами, если мы достаточно точно, с учетом рисков и приоритетов, можем спрогнозировать сроки и результаты выполнения разрабатываемой функциональности, то бэклог можно назвать качественным. О нем и поговорим. На связи Владислав Филимонов, инженер-аналитик КОМПАС-3D.

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

Меня зовут Ирина Васильева, и я старший Agile-коуч в МТС Live. В этой статье я расскажу, как мы провели Agile-трансформацию билетного оператора Ticketland. В процессе реорганизации мы навели порядок в задачах, сохранили команду и обеспечили сервису дальнейшее развитие в экосистеме МТС. На нашем примере я покажу, что любые изменения возможны, если декомпозировать основную задачу, наладить общение между командами и придерживаться выбранного роадмэпа. «Глаза боятся, а руки делают» — об этом я и расскажу под катом.

Всем доброе утро!
На связи вновь Крылов Александр и сегодня я решил поделиться мыслями по тому, как можно применить опыт DevOps Governance в Enterprice, который я ранее описывал в в этой статье. Прошло время и опыт был переиспользован для разработки продукта на примере компании Bimeister. А началось это аж в августе 2023 года.

Что тут важно сказать - нет, это не будет детальной расшифровкой с уточнениями доклада с DevOops 2023, с которым так же можно будет ознакомиться по ссылке выше. В данной статье я расскажу ряд аспектов отличия Governance в Enterprice и то, как он может выглядеть в компании разработчике своего продукта. Помимо этого, я так же расскажу, какие работы удалось провести за год в компании, а какие нет.

Начнем с того, что тема команды в целом, довольно сложный и многогранный вопрос, Который требует развития разных граней человека каждого члена команды, и в особенности, её лидера. От Эмоционального интеллекта и эмпатичности, до самокритики и самообладания.

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

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

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

Привет всем! Меня зовут Кирилл Ларьков, я Скрам-мастер банка ВТБ и работаю с сервисными командами. В этой статье я хотел бы поделиться опытом по прогнозированию задач в сервисных командах, которым ранее и в страшных снах не снилось слово "прогнозы". Формат для данной статьи я выбрал сторителлинг, так как подобный пошаговый гайд будет полезен начинающим командам, которые пытаются справиться самостоятельно с прогнозированием задач.

Привет, Хабр! Я Владимир Князев, Agile-коуч ОТП Банка. В этой статье хочу рассказать про нейромедиаторы, и как они влияют на нашу мотивацию.

Когда вы достигаете какой-либо большой и сложной цели, что обычно чувствуете? Радость, удовлетворение, или, может быть, состояние опустошенности?

В феврале 2024 года началось объединение Хоум Банка с Совкомбанком. Наши стримы стали интегрироваться в процессы СКБ, поэтому развитие текущей модели работы Хоум Банка стало не актуальным. В конце мая мы завершили все активности 4,5 летней SAFe-трансформации, в которой приняли участие более 1000 сотрудников, и готовы подвести итоги.

Меня зовут Олеся Мойса, я экс-RTE/Agile-коуч в Хоум Банке и совместно с Максимом Захаровым, ex-руководителем Agile-трансформации, мы коротко расскажем про наш путь и поделимся выводами. А в конце статьи будет анонс нашего выступления на конференции FlowDays, которая пройдет 13 сентября 2024 года.

Итак, ты решил сменить работу и исследовать для себя новые карьерные возможности на международном рынке. Английский на уровне В1+/В2, что уже само по себе заставляет тебя нервничать, ведь во всех вакансиях написано fluent English, а ты впадаешь в ступор от непонимания как правильно ответить на самый первый вопрос на собеседовании “Tell me about yourself”. А еще нужно создать достойное резюме и уметь рассказывать о своем опыте, чтобы повысить свои шансы. Всё это становится супер overwhelming, ты хватаешься за голову и понимаешь что не существует one-size-fits-all решения. 

Здесь я уже рассказывала как структурно отвечать на вопросы рекрутера, но данная статья посвящена именно self-pitch. Я поделюсь 2 способами создания эффективной самопрезентации, а в конце статьи ты можешь забрать шаблон и использовать его для создания ответа на вопрос “Tell me about yourself”. Если ты уже сделал всё по шаблону или у тебя есть другая версия рассказа о себе, ты можешь написать лично  автору и показать свой результат для обратной связи. 

Как рассказать о себе? Способ 1.

Self-pitch - это продающая самопрезентация о себе. Самое важное что нужно запомнить - Product managers tell stories. Навык рассказывать истории (сторителлинг) просто необходим для эффективных ответов на вопросы собеседования. 

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

Недавно методика планирования на нашем проекте изменилась. И жизнь команды тоже:) Что получится, если объединить «Тетрис» и 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. Выявление реальной проблемы

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

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

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