Agile *

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

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

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

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

Кому из нас не знакома ситуация, когда «горит» вообще всё и сразу? Кажется, что каждая задача кричит: «Сделай меня первой!» И вот тут‑то и возникает ступор: за что хвататься, с чего начать? Методик приоритизации существует великое множество — от простой и понятной матрицы Эйзенхауэра до запутанных фреймворков вроде WSJF. Но как во всем этом разобраться и не утонуть в бесконечных таблицах и формулах?

Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT‑отделом 8. Я работаю в компании Софтонит. В этой статье я постараюсь простым языком рассказать о самых популярных подходах к приоритизации задач. Мы разберем их плюсы и минусы, посмотрим на реальные примеры и, надеюсь, вы найдете тот инструмент, который будет вам полезным и поможет навести порядок в бэклоге, а также сделать процесс приоритизации четким и понятным.

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

SP создали, чтобы уйти от тирании часовых оценок, но в итоге без понимания принципов превратились в бессмысленный ритуал. Команды тратят рабочее время на пересчет баллов в дни, менеджеры требуют «увеличить velocity на 20%», а разработчики — тихо ненавидят планирование.

Разбираемся, что такое Story Points, как их считают, в чем их проблема и как их используют разные команды.

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

Перевод статьи подготовлен редакцией итеративно-функционального метода, новейшей альтернативы Agile и Kanban. Дисклеймер: эта специализированная статья подходит для продуктовых менеджеров и энтузиастов продуктовых методологий и продуктового тулинга.

Джейсон Фрайд (Jason Fried), CEO компании 37signals — создателей Basecamp и HEY — недавно опубликовал в своих запрещенных в России соцсетях два демо видео нового продукта Fizzy, который представляет собой новый взгляд на трекер идей, задач и багов. Представление задач реализовано в виде коллекции (аналог доски в Канбане) с двумя колонками — «В рассмотрении» (“Considering”) и «В работе» (“Doing”). Карточки в обеих колонках содержат заголовок, имя автора карточки и исполнителя, а также информацию о дате создания и последнего обновления. В колонке «В работе» есть переключатель стадий («Изучение», «В процессе», «Блокировано»). Последовательность стадий определяется одним из выбранных рабочих процессов (workflow), который настраивается в параметрах коллекции. В зависимости от выбранной стадии меняется цветовая схема карточки. Завершённые карточки отправляются в подвал страницы, где каждая карточка проштампована большой печатью с причиной закрытия.

Прежде всего хочу подчеркнуть, что с большим уважением отношусь к Джейсону Фрайду и СТО 37signals Дэвиду Хайнемайеру Ханссону (DHH) и к их работе. В эпоху бездушных аджилистских монстров вроде Jira, ClickUp, Asana и десятков их безликих клонов, Джейсон и Давид создали оригинальный подход под названием Shape Up, который во многих аспектах лучше адаптирован под современную разработку для мобильных и веб-платформ, чем Agile, Scrum, SAFe и иже с ними.

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

Это статья не про тех менеджеров, кто таски в джире двигает и статусы собирает. И не про тех, кто просто ретранслирует запросы сверху вниз и держит в поле только календарь. Здесь пойдёт речь о людях, которые по-настоящему держат на себе команду, бизнес и продукт. О тех, кто в небольших компаниях или стартапах становится точкой сборки: принимает решения, управляет продуктом, координирует разработку, тащит финансы и договаривается со стейкхолдерами. И всё это одновременно.

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

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

Бро, если ты хоть раз руководил командой — ты это проходил. На стендапе всё звучит красиво: «делаю задачу, осталось чуть‑чуть», «почти готово», «просто баг странный». А потом проходит неделя, ты заглядываешь в код — и там либо ничего, либо половина сделано, либо вообще не туда копали.

Нет, это не обязательно саботаж. Иногда это банальная прокрастинация, страх ошибиться, потеря мотивации, или просто неумение сказать: «я застрял». Но проблема‑то реальная. Если не ловить и не разруливать — команда тонет в самообмане, а ты — в вечных переносах.

Разберёмся, почему разработчики врут (осознанно и не очень), какие признаки надо замечать раньше, и как перевести разговор из «всё нормально» в «честно, я залип». С кейсами, приёмами и без розовых очков.

Представь, Бро. У тебя в команде есть один человек, который держит в голове все тонкости проекта. Архитектура - его. Сборки - его. Логика в бекенде, деплой, связи между модулями - тоже он. Всё работает идеально, пока он рядом. Но стоит ему уйти в отпуск, заболеть или, как говорится, попасть под автобус - и всё, команда в ауте, сроки летят, клиенты в шоке.

Это и есть тот самый bus-фактор. В этой статье разберём, почему это не круто, как он возникает, почему так распространён, и главное - как его снизить. Поделюсь личными кейсами, проверенными практиками и нетривиальными приёмами, которые реально работают. Без воды, честно и с примерами из боевого менеджмента.

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

Гибкость (agility) — это, без сомнения, полезная вещь, и Манифест Agile не выглядит необоснованным. В сравнении с устаревшей практикой, известной как «Waterfall», Agile безусловно имеет свои преимущества. Тем не менее, многие аспекты Agile на практике оказываются весьма вредными, и я не считаю, что дихотомия «Agile/Waterfall» вообще является полезной концепцией.

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

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

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

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

— Что делаешь? Ботаешь?
— Нет, учусь.
— Что учишь?
— ООП
— А зачем?

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

На встречах они не обсуждали функциональность продукта, а говорили о «пользовательских историях» – маленьких повествованиях, описывающих фичи. Каждой такой истории присваивались «story points» — условные единицы, оценивающие объём усилий, необходимых для выполнения задачи. Каждое утро они проводили «стендапы» – короткие собрания, на которых все стоят. В центре их офиса стояла доска, на которую они клеили стикеры и передвигали их по колонкам в зависимости от статуса задачи. Они работали «спринтами» – двухнедельными циклами, посвящёнными определённым задачам.

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

Так я и узнала, что такое Agile — метод управления разработкой, который получил колоссальную популярность в технической среде и, всё чаще, за её пределами (один TED-спикер даже рассказывал, как внедрил Agile дома, в семье).

Честно говоря, я была впечатлена. В своей работе я часто чувствовала себя потерянной: не до конца понимала, продвигаюсь ли я вперёд или делаю что-то действительно важное. А разработчики, казалось, точно знали, что делают. Если возникала проблема — ничего страшного, они просто с ней разбирались. Они понимали, что требования будут меняться, и двухнедельные спринты позволяли гибко перестраиваться: заменить одну фичу на другую или перейти на другой фреймворк.

Сегодня мы расскажем о внедрении кросс-командной приоритизации во всей компании Спортмастер Лаб, и о том, как мы:

- сократили время планирования разработки в 9 раз (с 18 до 2 недель).

- увеличили количество значимых для бизнеса функций в 5 раз без роста команды разработчиков.

Собственно, краткая суть истории в том, что господин Деминг, светило науки в области управления организациями, на своём семинаре наглядно показывал пример того, как работает мотивация.

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

Логично предположить, что подопытный это сделать не мог. Тогда Деминг подключал «мотивацию»:

Waterfall, Agile, Scrum, Kanban — от выбора методологии зависит то, как команда будет справляться с разными типами задач, уложится ли она в сроки и будет ли вносить бесконечные правки. Если вы хотите четко понять, чем отличаются эти подходы, какие у них сильные и слабые стороны, и в какой ситуации каждый из них действительно эффективен — эта статья для вас.  

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

— Голдстейн. 

— Да, мистер Старк. 

— Дай мощный бит, под который я буду бить лучшего друга, писать эту статью. 

©Железный человек

Привет, Хабр! Меня зовут Дмитрий Сушков, последние 5 лет работаю железным человеком бизнес-аналитиком. Сегодня поговорим про одну из самых важных задач бизнес-аналитика (BA) — сбор и приоритизацию требований. Эта область довольно мутная, ибо редко бывает единый правильный подход. На каждом проекте есть свои «острые углы»: как договориться с заказчиком, прояснить его реальные потребности, оформить требования так, чтобы их поняли все участники, и при этом успеть всё в срок. Это как разжигать костёр в ливень, в открытом поле, пробовали?) И не стоит. 

Именно поэтому, иногда можно сравнить себя с железным человеком. Потому что ты не сдаёшься и достигаешь цели имея всё железное от железной воли до железных...(пофантазируйте =) ). 

Эта статья будет полезна: