Agile *

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

Меня зовут Антон Чижов и я руковожу Центром практик Agile в МТС. В этой статье я расскажу о том, что такое продуктовая трансформация и как мы ее проводили в МТС. А в конце статьи вас ждет анонс моего выступления на конференции True Tech Day, которая пройдёт 31 марта 2023 года.

Бытует мнение, что ретроспектива это скучная встреча без явной пользы. Если ставить цель, фиксировать прогресс и подбирать интересный формат ретроспективы, то польза от этой командной встречи не заставит себя ждать. В статье вы найдете 3 варианта эффективных ретроспектив, проводимых в командах разработки Ozon.

Всем привет! Мы - отдел бизнес-поддержки (БП) в Social Discovery Group. В этой статье расскажем, как мы повторили шестой подвиг Геракла, очистив доску от 1500 тикетов, которые накопились за 4 года. 1500 задач - это больно. Тикеты кочевали из спринта в спринт, заказчики ежедневно запрашивали статус по задачам, а мы испытывали стресс от переработок и от того, что не можем дать апдейты. Мы поняли, что нужно менять процессы в отделе и применили подход STATIK, который навсегда избавил нас от бесконечной очереди задач. 

Хабр, привет! Сегодня, в предпраздничный день, публикую статью Кирилла Евдокимова, директора практики Data Governance GlowByte. В области данных и аналитики он работает уже около 20 лет, последние 7 лет основной фокус – это Data Governance. Как говорит Кирилл, история с управлением данными всё еще остаётся terra incognita. В статье под катом он разбирает наиболее частые ошибки, проблемы, с которыми приходится сталкиваться компаниям, вступающим на тернистый путь управления данными.

«Управлять – это значит не мешать хорошим людям работать» говорил Сергей Петрович Капица. Некоторым кажется, что в этой цитате управление представляется в негативном свете, вроде активность менеджера больше препятствует достижению намеченной цели или же просто не добавляет ценности, а управление — это и не работа вовсе: хорошие люди - работают, а руководители, стало быть, нет. Я смотрю на это, как на конструктивный совет руководителям via negativа. Типа «первая заповедь менеджера – не мешай». Я кое-чего написал об этом ранее, но сейчас хотелось бы углубиться не в то, как не надо, а в то, как надо бы. Итак, ловите очередную упаковку magic pills, а уж там - сами разбирайтесь: какая из них синяя, а какая показывает глубину кроличьей норы.

Трудно утверждать, что методология Agile неэффективна. Практически все команды разработки программного обеспечения стараются ей следовать. Простой способ начать внедрять гибкую методологию — это добавить пару ее компонентов в рабочий процесс. Одним из самых популярных и при этом важных компонентов считается оценка в Story Points. Однако сколько команд оценивали ее реальное влияние? На самом ли деле оценка времени, затраченного на каждую задачу, приносит пользу? По моему опыту, это не так.

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

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

Привет! Меня зовут Елена, я недавно перешла работать в SM Lab руководителем продукта Портал поставщика. Портал – это рабочее место поставщиков товарной продукции в Спортмастер и Остин. Решение представляет собой трехслойную систему со множеством интеграций и витиеватым функционалом. Локализация интерфейсов, инструкций и обучающих курсов на трех языках, в миссии – простота и удобство пользования.

В SM Lab продуктовый подход, поэтому я зашла в готовую команду. Её особенность в том, что она достаточно большая – 17 человек. В этой статье я хочу рассказать о том, как мы внедрили относительные оценки работ и что получили в результате.

Меня зовут Наталья Кобякова, я Product owner и техлид клана аналитиков в Ak Bars Digital. В этой статье я расскажу, почему для проектирования функциональности наших продуктов вместо стандартных ТЗ мы используем методологию User Story Mapping и как это помогает нам вести разработку быстро и качественно.

Привет! Меня зовут Лёша Дидух, я тимлид команды личного кабинета в Skyeng. Это текстовая адаптация моего доклада про ретроспективы на DUMP-2022 в Екатеринбурге. 

Когда я пришёл в компанию пару лет назад, то немножко обалдел от разницы в подходах к управлению проектами и командами между моей прежней работой и Skyeng. Такой скачок между диаметрально противоположными культурами заставил меня переосмыслить и собрать воедино всё, что я знаю о ретроспективах. Будет полезно и тимлидам, и юным скрам-мастерам, да и вообще любому, кто хотя бы раз сидел на ретроспективе и думал: «Что я здесь делаю?».

В конце статьи можно найти запись доклада по теме.

Начнем издалека (но не просто так)

В 2000 году влиятельные ребята из мира IT, среди которых были Роберт Мартин (автор принципов SOLID и огромного числа книг про программирование) и Джеф Сазерленд (один из авторов Scrum), встретились, чтобы, как говорит сам дядя Боб, лучше узнать друг друга в надежде, что тесное общение приведет к чему-то интересному. 

Всем привет! Есть такое понятие, как I-shaped специалист — человек, который является экспертом в какой-то области и развивает свои знания в ее рамках. А еще есть понятие дженералист — этот человек уже разбирается во многих областях, но при этом не является ни в одной из них экспертом. В восьмидесятых-девяностых годах появилось понятие “T-shaped специалист”, тот, кто является экспертом в какой-то одной области и имеет поверхностные знания в одной или нескольких других. Сразу оговорюсь, что мы в продукте Кошелька под областями понимаем платформы разработки — бэкенд, QA, IOS, Web и так далее. 

С Вами снова Владимир и меня все еще зовут девопс.

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

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

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

С одной стороны, система менеджмента качества (СМК) основывается на стандартах серии ISO 9000 (ГОСТ ИСО), её привычно видеть там, где есть жёсткий технологический цикл. Например, на машиностроительном, металлургическом предприятиях или предприятии обрабатывающей промышленности.

С другой стороны, все, кто хотя бы прочёл AgileManifesto, знают, что «люди важнее процессов», а «работающий продукт важней документации».

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

Поэтому, при кажущейся парадоксальности вопроса из заголовка, тема внедрения СМК для ИТ-компаний может оказаться весьма актуальной.

Как же часто мне приходилось слышать от рекрутеров одну и ту же фразу:

Мы работаем по Agile. Спринты по 1-2 недели

Под "Agile" они, конечно же, имеют в виду Scrum. Но я с уверенностью могу сказать, что ни в одной компании, что я работал, Agile'ом даже и не пахло. И тут я даже не говорю о том, что Agile каким он был задуман в принципе не дошел до массовой разработки (о чем рассказывал один из создателей Agile Дейв Томас на конференции GOTO 2015). Я говорю об Agile в общепринятом значении этого слова.

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

По некоторым причинам команде разработчиков либо не получается наладить работу по Agile, либо руководство знает, как лучше, и навязывает собственное видение методологии разработки. Эту проблему адресовал в своей статье Рон Джефрис (вот перевод на русский), дав красноречивое название подобным практикам — "Dark Scrum". Существует и более мягкая формулировка для тех, кто считает подобное положение вещей скорее фичей, а не багом — "Pseudo Agile" или "Post Agile".

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

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

Привет! Меня зовут Хусен Гапурхаев, я скрам-мастер в Beeline Казахстан, и в работе часто сталкиваюсь с необходимостью делать одновременно большое количество задач (причем как своих, так и в работе наших продуктовых команд).

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

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

Данные события часто проводятся как механические упражнения и ритуалы, что является одной из дисфункций фреймворка. Дают ли такие события пользу без других важных основ? Ответ очевиден. Давайте разберёмся, что должно стоять за событиями.

Фрейморк Scrum в представлении не нуждается, и его преимущества многократно описаны. Однако о недостатках подхода говорят реже, и успешно применять его получается далеко не у всех. Зачастую после первых неудач команда разочаровывается в подходе и начинает считать его полностью бесполезной пустышкой. Но может быть дело не в самом Скраме, а в том, где и как его применили?

Попробуем рассмотреть, какие есть ограничения и допущения в применимости этого подхода, какие риски и предварительные условия нужно учесть.

Перевод статьи Лукаса Ф. Косты "Why your daily stand-ups don't work and how to fix them" с некоторыми размышлениями переводчика (выделены курсивом).

Ежедневные стендапы — классический пример выученной беспомощности. Мы все знаем, что они отстой. Тем не менее, мы ничего с этим не делаем. В наши дни мы проводим стендапы потому что нам так говорят, а не потому что они решают какие-то конкретные проблемы.

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

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