Всем привет! Меня зовут Анна Мозер, я работаю тимлидом системных аналитиков в X5 Tech. Мне удалось поработать и в корпорации, и в стартапе, и в качестве фриланс Delivery Manager на этапе запуска стартап команды.
Системный аналитик находится в центре между бизнесом и командой разработки и часто видит весь процесс целиком: от выявления требований до доставки реализации пользователю. Именно поэтому я всегда интересовалась тем, как устроены процессы в командах и принимала активное участие в их изучении и выстраивании.
Периодически мои друзья, знакомые, коллеги в кулуарах делятся тем, что процессы в их командах напоминают хаос. Они говорят: "Мы только и занимаемся тем, что тушим пожары" или "Я не знаю, чем буду заниматься на следующей неделе". И моё самое любимое: "Мы начали делать задачу, а на полпути потребности поменялись, и теперь нужно совсем другое. Но это же Agile…".
Хотя многие менеджеры объясняют это стремлением к гибкости и следованием Agile-философии, чаще всего такие признаки указывают на неправильное понимание и применение гибких методологий. Цель моей статьи – подсветить типичные ошибки менеджмента команды и рассказать об индикаторах того самого "недопонятого" Agile (я насчитала таких 10 штук).
1. Изменение потребности или решения в момент реализации
Пример из жизни. Вы бы видели глаза моей коллеги, которая пришла с 1x1 встречи и рассказала, что руководитель продукта прибежал с изменёнными требованиями в момент, когда задача была уже почти доделана.
Я часто слышу о том, что в Agile требования меняются каждый день, и это норма.
Но на самом деле это не так.
Задача Agile – прислушиваться к потребностям клиента и вовремя на них реагировать. Например, грянул COVID, и теперь магазины обязаны перейти на доставку, чтобы не потерять клиента. У клиента появилась новая потребность – бизнес должен на неё оперативно отреагировать.
Изменение требований к функционалу на ходу – другое дело.Такая ситуация означает не изменение потребностей клиента, а неправильное понимание, непроработанность этих потребностей. Это значит, что мы неправильно услышали, неправильно поняли, недостаточно экспертизы собрали, чтобы понять, какую функциональность нужно реализовать.
2. Отсутствие менеджмента
"Зачем менеджер? А как же самоорганизация?!", – часто слышно в разговоре об управлении командой.
Роль менеджера в Agile, особенно в контексте самоорганизованной команды – предмет жарких споров. Концепция самоорганизованности команд настолько привлекает владельцев продуктов, что становится оправданием отсутствия менеджера в команде. А зачем, если команда должна самоорганизоваться?
Пример. Недавно я общалась с менеджером продукта, который был недоволен работой системного аналитика. Он говорит: «Я ему выставил приоритеты, а он всё равно чем-то другим занимается». Я уточнила у аналитика, в чём дело. Оказалось, что на регулярных встречах приоритизация выглядит примерно так: «Займись интеграциями». При этом задача даже не заведена. По мнению менеджера продукта, аналитик должен был сам организоваться, завести себе задачу, определить смысл этих интеграций, наладить контакты с соседними командами и т. д.
В чём же роль менеджера в гибких методологиях? В традиционной структуре менеджеры часто являются "руководителями": принимают решения, распределяют и назначают задачи, контролируют сроки. Занимаются микроменеджментом, короче. Но динамика Agile команды трансформирует эту роль. Получается, что задача менеджера в Agile – создать комфортную, благоприятную среду для работы, помочь команде функционировать наилучшим образом.
Благоприятная среда в команде поможет участникам достичь той самой организации:
принимать решения, учитывая риски;
иметь возможность высказать идеи и подсветить проблемы;
работать работу, а не "самоорганизовываться" весь рабочий день.
"Роль руководителя состоит в том, чтобы поддерживать работу в рамках подхода, устранять преграды на пути к росту производительности и создавать среду, в которой команды смогут свободно взаимодействовать и отлично выполнять работу."
Саймон Хейворд (“Agile-трансформация. Готовый план перехода к гибкой бизнес-модели организации”)
3. Agile гарантирует быструю доставку? Серьёзно?
А вы тоже считаете, что гибкие методологии созданы, чтобы быстрее создавать продукты и выкатывать функциональность? Это заблуждение.
Гибкие методологии помогают быстрее доносить ценность. Основной фокус Agile и того, что строится вокруг него – качественная, сфокусированная работа, акцент на главном. В первую очередь команда реализует самый ценный функционал, и таким образом клиент быстрее решает задачу.
Эффективность, а не скорость. Гибкие методологии фокусируются на оптимизации процесса производства, а не на увеличении его скорости. Качественная коммуникация, выстроенные процессы, оптимальная слаженная работа команды способствуют скорости работы. Но скорость – это следствие, а не цель. А работа второпях запускает целый каскад ошибок и связанных проблем.
4. Замыкание экспертизы и процессов на одном человеке
Неправильная адаптация Agile-процессов в командах зачастую приводит к замыканию экспертизы и процессов на одном человеке.
В быстром темпе работы всегда кажется, что быстрее сделать самому, чем учить нового сотрудника, распределять задачи на команду, передавать экспертизу, настраивать процесс приёмки и передачи задачи по флоу. Это приводит к тому, что появляется гений-эксперт, который замыкает на себе значительное количество знаний о системе.
Единая точка знаний также приводит к замыканию процессов на этом человеке, потому что без него задачи уже не будут двигаться.
Пример, знакомый участнику любой IT команды. У вас есть инициативный разработчик, который пишет код, знает систему, распределяет задачи, общается с другими системами по интеграции и заведует техническим долгом и особенностями архитектуры. А потом он увольняется, и команда тратит пол года (хорошо, если столько, а не больше) на реверс-инжиниринг и на налаживание коммуникаций, которые сотрудник “забрал” с собой.
5. Постоянные итерации, которые не приводят к результату
Во фреймворках Agile работа разбивается на итерации, каждая из которых доставляет ценность и приближает продукт к цели. Однако, иногда команды попадают в цикл итераций, которые не приносят значимого сколь угодно финального результата с точки зрения ценности. Часто это происходит из-за неправильной декомпозиции требований.
Пример декомпозиции
Команда создаёт каталог товаров с фильтрами и поиском.
Примерный список требований:
поиск должен учитывать всевозможные "умные" подборки, предложения по вводу, искать на нескольких языках с переводом;
фильтры в каталоге должны быть взаимозависимые: при переключении цены изменяется список брендов;
в карточке товара можно листать картинки, открывать предпросмотр и открывать полную страницу товара.
Как может выглядеть декомпозиция на итерации: выпускаем минимально-необходимый функционал в каждом разделе, собираем скелет системы.
Первая итерация может выглядеть так:
- базовый поиск будет работать по совпадению подстроки;
- фильтры в базовом варианте будут независимы, но уже закроют 80% потребностей пользователя;
- карточка товара будет открываться на новой странице.
Это стандартная декомпозиция, при которой пользователь быстро получит базовые необходимые функции.
Другие опции декомпозиции могут быть такие:
1. Инкременты: выпускаем функции по очереди (как бы "едим слона по кусочкам"), но на 100% каждую.
- 4 месяца делаем каталог с предпросмотром (первая итерация);
- 3 месяца делаем поиск;
- 2 месяца доделываем фильтры.
Такая декомпозиция имеет место быть, но нужно учитывать, что пользователь получит работающий продукт нескоро. Наверняка, идеально работающий каталог практически бесполезен без минимального поиска.
2. Архитектурная декомпозиция проекта: делаем один микросервис, потом второй, потом третий, потом подключаем фронт, потом интегрируем.
С такой декомпозицией я тоже встречалась, и чаще всего это ошибка (при работе с продуктом).
Микросервисы – это, конечно, круто, но пока пользовательский сценарий минимально не выполняется, они практически бесполезны.
Чаще всего неправильная декомпозиция приводит к тому, что потребность клиента будет закрыта, но поздно, либо не закрыта вовсе. А как известно, 20% усилий приносят 80% результата. Это именно про итеративный подход к разработке.
6. Нет документации
Отсутствие документации в Agile – одно из моих любимых заблуждений. К счастью, большинство компаний уже осознали, что это ошибка, и написали большое количество статей, провели много митапов на эту тему.
К месту будет напомнить, как звучит ценность Agile:
«Работающий продукт важнее исчерпывающей документации»
«То есть, не отрицая важности того, что справа, мы всё‑таки больше ценим то, что слева»
Манифест Agile
Легко проигнорировать нижнюю приписку и попрощаться с любыми формами базы знаний.
База знаний о том, как работает продукт, нужна. Но это не то статичное ТЗ, которое пишется в проектном подходе. Эта база знаний должна быть динамичной, живой, удобной для использования и покрывающей необходимое и достаточное количество знаний для участников команды.
Пример. Представьте себе тестировщика, который пытается разобраться, правильно работает функционал или нет. Представьте себе сотрудника поддержки, который не понимает: пользователь что-то неверно ввёл или это система неправильно отработала? Представьте себе разработчика, который разбирает код при рефакторинге и не понимает, зачем накрутили столько интеграций и обращений в сервисы? А там, оказывается, где то закопано маааленькое бизнес-правило.
«Если этого нет в документах – этого не существует. Пока информация хранится у кого-то в голове – она легко теряется»
Луис Фрайд, автор книг об управлении командами в IT
7. Отсутствуют роль аналитика и этап проектирования
Роль аналитика в Agile командах – как кот Шрёдингера. Даже если её нет, то она как бы есть.
В чём суть роли аналитика:
Придумать, какая функциональность закроет потребность пользователя.
Придумать, как эта функциональность будет работать и зафиксировать эти требования.
Предусмотреть, чтобы функциональность была спроектирована так, чтобы её можно было расширить, если потребность пользователя изменится.
Даже если команда состоит из владельца продукта и разработчиков, так или иначе кто-то закрывает роль аналитика:
либо владелец продукта, когда ставит задачу разработчику;
либо разработчик, когда пишет код и выясняет мелкие детали.
Такое взаимодействие имеет место быть, но часто приводит к тому, что не понятно, что в итоге сделали, не понятно так ли хотели, это приводит к переделкам после реализации и прочим неприятным моментам.
Для снижения этих рисков команды часто выделяют отдельного сотрудника под роль аналитика, который снимает неопределённость требований до того, как они попадут в код.
Опять же, это не означает, что аналитик пишет ТЗ на 300 страниц и через пол года выдаёт требования. Аналитик также работает небольшими функциональностями (например, UserStory) согласно итеративному подходу. И все счастливы.
8. Слишком много встреч, недостаточно действий
Самоорганизованность команд во многом строится на коммуникации. Именно поэтому фреймворки Agile включают в себя ряд ритуалов-встреч, в рамках которых команда договаривается, решает, планирует, обсуждает и т. д.
Зачастую команды забывают, что на встречи нужно не только приходить, но и готовиться к ним. В таком случае они проходят непродуктивно, не приводят к результатам: команда много разговаривает и мало делает.
Пример, он же спойлер: после ряда неэффективных встреч руководитель решит просто отменить планирование, ретроспективу, сделает дейлики раз в неделю. Нет встреч – нет проблем по их проведению.
Спойлер 2: спустя месяц тот же руководитель будет удивляться, почему команда занимается не понятно чем.
9. Отсутствие ретроспективы и анализа процессов в команде
Первым делом, когда я слышу от коллеги, что в команде процессы идут чёрти как, я спрашиваю: есть ли у вас ретро? Когда оно было в последний раз? Обсуждался ли там этот вопрос?
К сожалению, чаще всего ответы бывают такие: “У нас нет ретро”; “Последнее ретро было 3 месяца назад”; “Ретро было, но не получилось озвучить проблему”.
Отсутствие ретро в основном связано со следующим:
руководитель команды считает, что ретро не нужно, либо чаще всего не получает обратную связь (причинно-следственная связь работает в обе стороны);
несколько раз команда провела ретро, потратили время, ни к чему не пришли, демотивировались, и в итоге отменили;
ретроспектива проходит неправильно по формату, не приводит к результатам.
Пример. Есть ещё одна команда, с которой я тесно общаюсь, частенько интересуюсь, как у них дела. И часто слышу, что все работают чисто на энтузиазме, на человеческом факторе, без процессов, с задачами в Телеграме и т. д. Ну я им и говорю: “Ребята, проведите ретроспективу, обсудите между собой. Видно же, что вы все устали и надо что-то делать с этим”. Скрам-мастера у ребят нет, поэтому они собрались на десятерых, полтора часа поговорили и разошлись. И так два раза. В итоге оба этих раза вся команда обсуждала релизный цикл системы, даже не узнав, какие ещё есть сложности в процессах и взаимодействии.
Ошибка этого кейса в том, что команда принялась решать проблему вместо сбора и изучения всего, что наболело. Правильнее было бы зафиксировать проблему, назначить ответственных, которые отдельно собрали бы встречу с рабочей группой и обсудили бы возможные решения. Так команда может выстроить процессы работы, снизить человеческий фактор, создать общие договорённости, снизить риски при каждом принятии решения.
Кстати, после обсуждения такого мало-удачного ретро, один из аналитиков вызвался самостоятельно провести ретро по формату, и у команды наконец-то появился список проблем, назначены ответственные и сроки по первым шагам для решения проблем.
10. Слишком жёсткая привязка к инструментам и методологиям
С одной стороны, Agile фреймворки включают в себя обязательные ритуалы, способы визуализации, правила коммуникации. Но с другой, основной принцип – это гибкость и адаптация.
Я очень радуюсь, когда слышу, что команда использует нечто под названием “скрамбан”. Для меня это означает, что команда изучила фреймворки, выбрала подходящие практики и адаптировала под свою работу.
Пример. Я сама работала в команде, в которой мы начали со Scrum с двухнедельными спринтами. Потом мы осознали, что физически не успеваем поставить релиз в такой срок. Тогда мы сначала увеличивали длину спринтов, но всё равно было неудобно. Даже строили сложные конструкции в виде: спринт на разработку + спринт на стабилизацию релиза. Но оставался ряд проблем, про которые можно написать отдельную статью, например, маленькие фичи надолго застревали в спринтах.
В итоге мы перешли на Канбан с релизными итерациями. И я не уверена, что это наше финальное состояние, потому что процесс должен развиваться и адаптироваться под потребность.
Основная моя мысль здесь в том, что Scrum и Kanban – это просто инструменты. Это исходник, с которым можно работать, приземляя его на свою команду.
«Сейчас многие руководители проектов стали забывать, что заполняемые ими формы, схемы и таблицы созданы, чтобы помогать, а не наказывать»
Mantel, Meredith, Shaffer, and Sutton, авторы книги «Project Management in Practice»
Если резюмировать: я ни в коем случае не топлю за то, что Agile – это зло. Наоборот: это полезный и эффективный подход, но только при его правильном, уместном использовании. Например, Agile вам подойдёт, если вы хотите делать качественный продукт, а не делать его быстро. При этом важно соблюдать баланс между самоорганизованностью команд и построением процессов.
Мне очень интересно услышать ваши мысли на эту тему. Делитесь в комментариях своими наболевшими примерами и как выходили из ситуаций.
Комментарии (18)
Ded_Letto
20.09.2023 08:05+1Про документацию прям отдельно больно стало. Если серьезно, то удивляюсь порой тому, как люди начиная работать по агилу думают, что все их проблемы развеятся, разработка полетит со скоростью Тысячелетнего Сокола, а клиент будет плакать от счастья, видя как быстро выходят фичи. Проблема в том, что методология - не панацея, а приоритезация процессов, и выпуск фич не является главным приоритетом.
По своему опыту могу сказать, что если команда, а в частности руководитель команды, не готовы к компромисам, то все эти проблемы не решаемы. И для решения каждой проблемы необходимо время. Хотите докинуть требований? В порядке очереди, оформляем тикет, проводим груминг и планируем. Или убираем тикет из стринта и доделываем. Хотите документацию? Выделяем сотрудника, выделяем время, и тратим его на документацию. Хотите поговорить о проблемах? Выделяем время, планируем встречи, ищем и пробуем инструменты для ретро, фиксируем и прорабатываем проблемы.
А зачем все это, если можно написать разрабу, и попросить доделать тикет на этапе тестирования? Зачем писать документацию, если можно по коду посмотреть что там и как? Зачем нам ретро? Вы просто работать не хотите.
Агил не равно успеху. Иногда нужно чем то жертвовать, и чаще всего это время.
Любой рабочий процесс - это сущностьв виде гномика, которая постоянно преобразовывается в зависимости от окружающей среды, коллег, других команд, требований, клиентов и прочего. Рабочий процесс не должен быть хаотичным, и постоянно должен подстраиваться. Нужно палками бить тех, кто эти процессы злостно и целенаправленно нарушает. вообще, есть хорошее правило: есть жалоба => фиксируем проблему => обсудить и найти решение => решить => проверить. Работает как с клиентами, так и с деревянными руководителями.
AnnaMozer Автор
20.09.2023 08:05Согласна на все 100%
Я сейчас плотно работаю с командой, в которой и Product Owner и Delivery Manager понимают значимость выстроенных процессов в команде. И как раз грамотная связка (важно, что именно связка) владельца продукта и деливери помогает эти процессы выстроить.
Тогда и продакт лояльно относится к тому что "вот эта маленькая задачка" только в следующую итерацию может попасть, потому что провели регресс только что
И деливери может ожидать от продакта адекватной приоритизации например. Тоже важный элемент без которого далеко не поедешь
David88
20.09.2023 08:05"после ряда неэффективных встреч руководитель решит просто отменить планирование, ретроспективу" - волевое решение, чувствуется характер
AnnaMozer Автор
20.09.2023 08:05+2Я с таким встречалась, когда руководителя команды долго убеждаешь, что нужны процессы, планирование, ретро. И он такой - нуууу оооок, давайте.
Начинает это все делать, делает как умеет или не умеет, а потом говорит - да толку нет, давайте так же в телеграме задачи ставить и там же распределять, удобно же!
Так что если начинать, то начинать надо правильно
ValeryBat
20.09.2023 08:05+1Да, часто "Мы же по agile работаем" используют как оправдание на любые проблемы
Batalmv
20.09.2023 08:05По тому, чем занимается менеджер.
Он контролирует производительность и процесс достижения цели спринта. В ответах на стандартные вопросы "что сделал?", "что буду делать?", "что мне мешает?" можно найти много информации, в том числе и о белом пушном зверьке, который находится в стадии подкрадывания
Он контролирует бюджет и сроки, так как у него контракт. Это как бы важно :) И как следствие он может выставлять стратегические приоритеты и задачи
Он доносит инфу власть предержащим, у которвх деньги и приносит оттуда важные посылы
Он решает вопросы за пределами зоны полномочий команды. Об этом сказано в части "создания атмосферы", но на многих проектах в "большом ентерпрайзе" таких моментов овердофига
Аналитик может сделать ПМа своим союзником и проводником своих идей
Ilusha
20.09.2023 08:05+1Agile в первую очередь - это про культуру осознанности команды, как единой атомарной единицы, которая самостоятельно работает над своими процессами, гибко ими управляет фокусируясь на бизнес-цели.
Команда обладает властью сказать «нет». Но очень важна именно продуктовая осознанность, не меньше чем техническая.
Где-то можно отложить работу с документаций, где-то забить на техдолг. Где-то наговнокодить. Но делать это управляемо: есть мы «занимаем» время у других процессов сейчас, то придется им возвращать потом.
Agile - это не про процессы, фреймворки, итерации и карго-культ. Agile - это про гибкость. Именно это подразумевается, когда говорят «культура». И эта культура должна выстраиваться сверху: бизнес. А уж как её построить - это вопрос к бизнес-процессам.
miksoft
20.09.2023 08:05самостоятельно работает над своими процессами
А такое возможно в более-менее крупной организации?
Ilusha
20.09.2023 08:05Возможно, если руководство этой крупной компании захочет. И если бизнес-процессам в этой компании подходит именно agile, а не что-то еще.
По факту, аджайл с позиции идеологии есть у очень не многих (спотифай, семраш).
А остальные занимаются итеративной разработкой. Это не плохо. Но большинство менеджеров вообще не понимают о чем пишут, чем пользуются, как оно работает.
AnnaMozer Автор
20.09.2023 08:05Как раз писала комментарий, что статья основана на командах, которые занимаются итеративной разработкой :)
в этом как раз основная идеологическая ошибка: думать, что работаешь по Agile, а по факту просто работать итерациями.
inscriptios
20.09.2023 08:05Начали вы хорошо про "Изменение потребности или решения в момент реализации", но дальше все равно скатились в кашу. Попробую быть объективным, хотя за такое, да по такой теме здесь обычно отхватывают.
Вы, наверное, раз 20 написали "Agile" — Agile там, здесь, так и эдак. Однако Agile (если быть точным, то Agile-манифест разработки программного обеспечения) — это лишь набор ценностей и принципов, а не что-то, что говорит как именно эти ценности и принципы можно использовать. То есть вы долгое время в статье очень старательно избегаете того, чтобы называть конкретные методологии, которые основаны на этих ценностях и принципах и о которых и должна идти речь здесь, особенно учитывая то, что все они очень отличаются друг от друга. Никакого другого Agile за пределами существующих методологий просто нет, кто бы ни называл свою работу "выполняемой по Agile". Но, давайте я угадаю слово, "которое нельзя называть".
Итак, есть только три методологии, которые можно предполагать для основной части вашей статьи, потому что остальные очень маловероятны. Это Scrum, Kanban и XP (Extreme Programming). Можно было бы добавить Lean, но это вряд ли, особенно с учетом того, что это не совсем методология. Зная ключевые особенности каждой, ищем ключевые признаки в вашем тексте (я не насчитал таких 10 штук, но достаточно, чтобы однозначно идентифицировать преобладающую в вашей статье методологию).
Что у нас есть по ключевым словам / терминам:
Scrum: "самоорганизованной команды" (правильно самоорганизующаяся, а не самоорганизованная); "владельцев продуктов"; "итерации"; "инкременты"; "ретроспективы"
Kanban: "самоорганизованной команды"; "итерации"; "ретроспективы"
XP: "самоорганизованной команды"; "итерации"Итак, Scrum — 5, Kanban — 3, XP — 2. Плюс из этих трех вы сами упомянули в конце первые две в примере. Таким образом, статья в основном повествует о Scrum. А теперь давайте пройдемся по некоторым вашим заявлениям, в том числе, с учетом этого.
Индикаторы того самого "недопонятого" Agile
2. Отсутствие менеджмента
Недавно я общалась с менеджером продукта, который был недоволен работой системного аналитика.Отсутствие менеджмента это недопонятый Agile, серьезно? Кто вообще такой этот "менеджер продукта"? В Scrum менеджмента нет. Менеджмент всегда есть в организации и его роль относительно Scrum в том, чтобы устранять препятствия, которые могут мешать Scrum Team to embrace (наверное, по-русски, это скорее принимать и воплощать) эту методологию, поддерживать Product Owner, обеспечивая его информацией о видении, миссии и целях компании, помогая (информацией) расставлять приоритеты (да, в беклоге), и вообще оказывать поддержку в целом и создавать соответствующую культуру. А не "менеджер продукта", который что-то там поручает аналитику.
Концепция самоорганизованности команд настолько привлекает владельцев продуктов, что становится оправданием отсутствия менеджера в команде.
Что? "Владелец продукта" у вас оправдывает (их же привлекает "идея") отсутствие "менеджера в команде", потому что одним из ключевых принципов является самоорганизующаяся команда? Тут даже комментировать нечего.
Пример, знакомый участнику любой IT команды. У вас есть инициативный разработчик, который пишет код, знает систему, распределяет задачи, общается с другими системами по интеграции и заведует техническим долгом и особенностями архитектуры. А потом он увольняется, и команда тратит пол года (хорошо, если столько, а не больше) на реверс-инжиниринг и на налаживание коммуникаций, которые сотрудник “забрал” с собой.
Хочется спросить, а остальные чем все это время занимались? Он что один за всех все делал в вашей "Agile" команде? Не знаю что вы там
куритепрактикуете, но коммуникация и командная работа это то, что вообще в основе лежит. Вы же сами манифест цитировали, давайте еще поцитируем: "Люди и взаимодействие важнее процессов и инструментов", нет? Ну, а на планировании ваших спринтов явно только один инициативный разработчик присутствует, потому он все знает, а остальные написанные им задачи просто выполняют.Однако, иногда команды попадают в цикл итераций, которые не приносят значимого сколь угодно финального результата с точки зрения ценности. Часто это происходит из-за неправильной декомпозиции требований.
Чаще всего неправильная декомпозиция приводит к тому, что потребность клиента будет закрыта, но поздно, либо не закрыта вовсе.Причем тут декомпозиция? Вы что делать собираетесь? Какую потребность пользователя удовлетворять? Если ваш Product Owner изначально неправильно определил и/или приоритезировал потребности этих самих пользователей, то как бы вы и в каких разрезах не декомпозировали это нечто, результат работы команды все равно никому будет не нужен.
руководитель команды считает, что ретро не нужно
Опять руководитель команды. Вы точно путаете понятия и после этого рассуждаете о том, что не так с Agile.
Индикаторы того самого "недопонятого" Agile
10. Слишком жёсткая привязка к инструментам и методологиямА, то есть чем более точно вы следуете методологии, тем больше Agile становится недопонятным? Ок, нет смысла обсуждать даже.
Я очень радуюсь, когда слышу, что команда использует нечто под названием “скрамбан”. Для меня это означает, что команда изучила фреймворки, выбрала подходящие практики и адаптировала под свою работу.
Нет, все ровно наоборот. Это значит, что они их вообще не изучали, раз начали следовать непонятно чему, придуманному непонятно зачем. Я искренне пытался понять зачем это было придумано и чего из этого нет в более популярных методологиях, но так и не смог, потому что там нет ответов на этот вопрос. Мало того, за этим термином может скрываться любая непонятная система, придуманная "как смогли".
Я сама работала в команде, в которой мы начали со Scrum с двухнедельными спринтами. Потом мы осознали, что физически не успеваем поставить релиз в такой срок. Тогда мы сначала увеличивали длину спринтов, но всё равно было неудобно. Даже строили сложные конструкции в виде: спринт на разработку + спринт на стабилизацию релиза.
А причины искать не пытались? И устранять их потом? Явно нет, раз первым решением было увеличение "длины" спринтов, да еще и какие-то разные типы этих самых спринтов.
В общем ИМХО, навязываться не буду, минусующим рекомендую
куритьпрактиковать скрамбан)AnnaMozer Автор
20.09.2023 08:05Спасибо большое за такой развернутый комментарий, некоторые мысли я сохранила себе на подумать!
Но я вообще не рассуждаю "что не так с Agile". Наоборот, я очень привержена ее ценностям и в идеальном мире хотела бы наблюдать, как круто эти ценности реализуются в командах.
Вы пытаетесь вычленить определенную методологию "которую нельзя называть", но на самом деле в основном статья как раз таки про команды, которые не работают по определенному фреймворку/методологии, например Scrum/Kanban или Lean.
Чаще всего в больших компаниях таких чистых методологий не бывает. И в итоге признаки команд, о которых я пишу такие:
а) команды работают итеративно;
б) команды заявляют о гибкости (например могут по потребности запилить новую фичу);
в) организационно это что-то между продуктом и проектом.
Именно с этим связана лексика, которую я использовала ("работают по Agile", "руководитель команды", "менеджер команды", "менеджер продукта" и т.д.), чтобы не относить к определенному фреймворку.
По поводу 10 оттенков менеджера: обычно у таких команд, которые застряли где-то в середине определения своего производственного процесса и методологии, есть некий административный лидер, например тот кто коммитится за бюджет или набирает команду. И он и не совсем Product Owner, и не некий Scrum менеджер, который поддерживает команду, и не Delivery Manager, который отвечает за доставку реализации, а что-то между всем этим и еще разными вариантами. Вот я как раз писала о том, как понять, что этот "менеджер" застрял где-то в середине определения, а с ним и вся команда.
А по поводу жесткой привязки к методологиям, отвечу так: не вижу ничего плохого в том, чтобы набрать инструментов из разных фреймворков. Например взять принцип наполнения релиза, как спринта из Scrum, визуализацию и сервисную модель из Kanban для определенной части команды (для аналитиков например). Важно, чтобы инструмент мог закрыть потребность команды потребности команды в текущем состоянии.
Возьмем например Scrum. Круто, если фреймворк закрывает потребности команды и клиента полностью. Но, при работе с большим бизнес-заказчиком, попробуй ему скажи, что перекраска кнопки пойдет только в следующий спринт, потому что у вас Scrum. Задача ведь - закрыть потребности бизнеса.
Та же ретроспектива несет ценность получения обратной связи и применима как в Scrum, как в Kanban так и в Waterfall в каком то изощренном виде. Основная задача - отслеживание проблем, тюнинг процессов и состояния команды. Ретроспектива - хороший инструмент для этого.
А без нее я даже не знаю как тюнить процесс, разве что ходить на 1-1 встречи с каждым из команды. Поэтому в том числе внесла отсутствие такой механики в список ошибок.
Если бы в реальном мире все было так прозрачно и все работали по прозрачной методологии, которая описана в книжках, было бы очень круто, но так бывает редко, к сожалению
lllamnyp
20.09.2023 08:05Я уточнила у аналитика, в чём дело. Оказалось, что на регулярных встречах приоритизация выглядит примерно так: «Займись интеграциями»
Что мешает аналитику подойти к продакту и уточнить, что он хотел? Кажется, это прямая обязанность аналитика собирать требования.
Gar02b
Всё верно. У нас Agile часто навязывают как стандарт, да ещё с применением русского максимализма.
Например, нельзя русскому человеку говорить про "продукт важнее документации". Он слышит только первую часть фразы и выбрасывает всю доку.
miksoft
А что еще я должен слышать, если команда загружена на 120% высокоприоритетными задачами?
По факту так и есть - я доку делаю только когда уже память/поиск по почте/конфлюенсу не справляются. И не со зла, а потому что некогда, над пожары тушить.
Ded_Letto
Соглашусь, что так обычно бывает, но пожары - следствие плохо настроенных процессов. У меня был следующий опыт: время на написание доки закладывалось на каждую фичу дополнительно. Хоть и не полностью, но от части это решало проблему. И время на пожары тоже закладывалось. В итоге на одного разраба в неделю закладывалось менее 20 часов эффективных. Остальное на пожары, созвона, доки, помощь суппорту и прочее
Gar02b
Вот именно. Без доки никто (через месяц - даже разрабы) не знает, как и где настроить все эти замечательные 120% высокоприоритетные фичи, потому что нет ни требований, ни инструкций.
Колхоз "Светлые Потёмки".