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

Всем привет! Меня зовут Максим, я тимлид деливери-менеджеров в Тинькофф Кассе. Расскажу, из чего состоят изменения, а также про одну методологию работы с ними. Будет кейс, как мы применяли ее на практике. Будет немного про провалы изменений, про структурный подход и факторы успеха любого изменения.

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

Привет, Хабр! Я Екатерина Колесникова, Agile Coach в inDriver. Когда я пришла в команду, заметила проблемы в процессе Product Backlog Refinement. Я предложила новый сценарий этой церемонии — и он сработал. В этой статье поделюсь опытом проведения PBR без скучной теории о «правильном» планировании. 

Эта статья по своей сути что-то вроде конспекта по вебинарам Ани Обуховой об эффективном использовании ресурсов нашего мозга, дополненного моими умозаключениями и рекомендациями.

Если хотите посмотреть оригиналы, то вот ссылки на её видео:
Как изменить mindset в Agile сторону
OKR изнутри — как мозг ставит цели

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

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

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

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

Статья, как и сам инструмент, подойдёт тимлидам, product‑ и project‑менеджерам, которые уже имеют опыт управления командами, набили шишки в запуске фич и ищут понятный и наглядный инструмент планирования, но не обладают большим техническим опытом.

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

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

Метод критической цепи: эффективное управление проектами с использованием буферов времени и ресурсов

Немного статистики

В работе с Incident Management-фреймворком мы в инжиниринге преследовали две основные цели: довести uptime до 99,99% (в API / SDK), и всегда знать о проблеме раньше пользователей.

В наши первые дни у нас не было всеобъемлющей системы оповещения и мониторинга. А если и была, то с кучей false-positive алертов и буквально одним-двумя графами в Kibana. Поэтому начать мы решили с создания команды Network Operations Center (NOC) - как стратегического базиса для работы с предотвращением и управлением инцидентами. Мы не только достигли показателя времени безотказной работы в 99,98%, но и увеличили нашу проактивность в выявлении инцидентов заранее: с 60% до впечатляющих 95% и выше. А все благодаря не только активному участию в улучшении платформы со стороны инженерки, но еще и благодаря метрикам First Time to Respond, Time to Acknowledge, Time to Assemble, Proactive Engineering Detection Rate, Number of Critical False Positives. В этом посте я расскажу про каждую из них, какие бывают антипаттерны, как измерять и как улучшать.

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

Если вы создавали свой стартап, занимались маркетингом ИТ продуктов или были частью продуктовой команды, то возможно знакомы с фреймворком планирования RICE для приоритизации продуктовых замыслов, идей и фич. Но сегодня речь не о нём. Будем обсуждать альтернативную версию этого фреймворка – «RIDE».

«Да кто такой этот ваш аджайл?! Мы же не продуктовая команда!», «И как меня угораздило в это вляпаться?!» — такие выражения (и много чего еще) я слышала на командных встречах архитекторов компании в роли агента изменений.

Всем привет! Я – Мадина, скрам-мастер в Департаменте управления технологиями МТС, у нас это подразделение называют Департаментом Technology Governance (TechGov).

Одно дело — внедрять скрам или канбан в командах разработки и совсем другое — внедрять гибкие подходы в Центрах компетенций или практик. Таких, например, как архитектура, управление производственным процессом, R&D или даже сам Центр практик Agile.

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

Этот материал для тех, к кому когда-то подошли и сказали: «Некогда объяснять, ты теперь тимлид (или начальник отдела)». Может быть, теперь вы уже профессионал своего дела, знаете кучу различных инструментов для решения своих задачи. Но давайте посмотрим чуть-чуть с другой стороны и разберем, как вы управляете потоком своих задач. Как справляетесь с работой, которая к вам приходит. Возможно, это поможет немного ее пересмотреть.

Меня зовут Алексей Пименов, я сертифицированный инструктор альянса  ICAgile, аккредитованный тренер и консультант Kanban University. Пионер Kanban-метода в России.  Моя цель — развить и поднять уровень менеджмента. Kanban многие сопоставляют с DevOps-культурой и практиками DevOps, но это всего лишь один из инструментов, который должен быть в вашем менеджерском ящике.

Больше 8 лет я использую Impact Map для аналитики IT-продуктов. Я довольно активно делился знаниями об этом подходе: писал статьи, выступал на конференциях с докладами и мастер-классами, рассказывал студентам в университетах и интернам в компании. Слушатели и участники мастер-классов легко улавливают, как создавать и использовать Impact Map, т.е. с теорией нет проблем. Тем не менее, я вижу большие затруднения с применением этого подхода в реальной практике, когда нужно придумать и описать идеи для сложного IT-продукта.

В этой статье я сделаю попытку объснить, каким образом формулируются идеи, которые являются самой сложной и самой ценной частью Impact Map, а также поделюсь своим видением, как наиболее эффективно воспринимать каждую из частей Impact Map.

День ото дня мы приближаемся к Agile-трансформации. Одна из самых важных целей для нас – увеличить velocity команд на X %. Слышали об этом? Слова Марка Андрессена о том, что «программное обеспечение пожирает мир», становятся отличительной чертой отраслей, которые раньше были менее автоматизированными.

Компания, занимающаяся разработкой Agile-продуктов, опросила более 18 000 клиентов и специалистов по разработке программного обеспечения.