Комментарии 24
Всё верно. У нас Agile часто навязывают как стандарт, да ещё с применением русского максимализма.
Например, нельзя русскому человеку говорить про "продукт важнее документации". Он слышит только первую часть фразы и выбрасывает всю доку.
А что еще я должен слышать, если команда загружена на 120% высокоприоритетными задачами?
По факту так и есть - я доку делаю только когда уже память/поиск по почте/конфлюенсу не справляются. И не со зла, а потому что некогда, над пожары тушить.
Соглашусь, что так обычно бывает, но пожары - следствие плохо настроенных процессов. У меня был следующий опыт: время на написание доки закладывалось на каждую фичу дополнительно. Хоть и не полностью, но от части это решало проблему. И время на пожары тоже закладывалось. В итоге на одного разраба в неделю закладывалось менее 20 часов эффективных. Остальное на пожары, созвона, доки, помощь суппорту и прочее
Про документацию прям отдельно больно стало. Если серьезно, то удивляюсь порой тому, как люди начиная работать по агилу думают, что все их проблемы развеятся, разработка полетит со скоростью Тысячелетнего Сокола, а клиент будет плакать от счастья, видя как быстро выходят фичи. Проблема в том, что методология - не панацея, а приоритезация процессов, и выпуск фич не является главным приоритетом.
По своему опыту могу сказать, что если команда, а в частности руководитель команды, не готовы к компромисам, то все эти проблемы не решаемы. И для решения каждой проблемы необходимо время. Хотите докинуть требований? В порядке очереди, оформляем тикет, проводим груминг и планируем. Или убираем тикет из стринта и доделываем. Хотите документацию? Выделяем сотрудника, выделяем время, и тратим его на документацию. Хотите поговорить о проблемах? Выделяем время, планируем встречи, ищем и пробуем инструменты для ретро, фиксируем и прорабатываем проблемы.
А зачем все это, если можно написать разрабу, и попросить доделать тикет на этапе тестирования? Зачем писать документацию, если можно по коду посмотреть что там и как? Зачем нам ретро? Вы просто работать не хотите.
Агил не равно успеху. Иногда нужно чем то жертвовать, и чаще всего это время.
Любой рабочий процесс - это сущность в виде гномика, которая постоянно преобразовывается в зависимости от окружающей среды, коллег, других команд, требований, клиентов и прочего. Рабочий процесс не должен быть хаотичным, и постоянно должен подстраиваться. Нужно палками бить тех, кто эти процессы злостно и целенаправленно нарушает. вообще, есть хорошее правило: есть жалоба => фиксируем проблему => обсудить и найти решение => решить => проверить. Работает как с клиентами, так и с деревянными руководителями.
Согласна на все 100%
Я сейчас плотно работаю с командой, в которой и Product Owner и Delivery Manager понимают значимость выстроенных процессов в команде. И как раз грамотная связка (важно, что именно связка) владельца продукта и деливери помогает эти процессы выстроить.
Тогда и продакт лояльно относится к тому что "вот эта маленькая задачка" только в следующую итерацию может попасть, потому что провели регресс только что
И деливери может ожидать от продакта адекватной приоритизации например. Тоже важный элемент без которого далеко не поедешь
Agile ради Agile'а — ужасная практика кучи компаний
"после ряда неэффективных встреч руководитель решит просто отменить планирование, ретроспективу" - волевое решение, чувствуется характер
Я с таким встречалась, когда руководителя команды долго убеждаешь, что нужны процессы, планирование, ретро. И он такой - нуууу оооок, давайте.
Начинает это все делать, делает как умеет или не умеет, а потом говорит - да толку нет, давайте так же в телеграме задачи ставить и там же распределять, удобно же!
Так что если начинать, то начинать надо правильно
Да, часто "Мы же по agile работаем" используют как оправдание на любые проблемы
По тому, чем занимается менеджер.
Он контролирует производительность и процесс достижения цели спринта. В ответах на стандартные вопросы "что сделал?", "что буду делать?", "что мне мешает?" можно найти много информации, в том числе и о белом пушном зверьке, который находится в стадии подкрадывания
Он контролирует бюджет и сроки, так как у него контракт. Это как бы важно :) И как следствие он может выставлять стратегические приоритеты и задачи
Он доносит инфу власть предержащим, у которвх деньги и приносит оттуда важные посылы
Он решает вопросы за пределами зоны полномочий команды. Об этом сказано в части "создания атмосферы", но на многих проектах в "большом ентерпрайзе" таких моментов овердофига
Аналитик может сделать ПМа своим союзником и проводником своих идей
Agile в первую очередь - это про культуру осознанности команды, как единой атомарной единицы, которая самостоятельно работает над своими процессами, гибко ими управляет фокусируясь на бизнес-цели.
Команда обладает властью сказать «нет». Но очень важна именно продуктовая осознанность, не меньше чем техническая.
Где-то можно отложить работу с документаций, где-то забить на техдолг. Где-то наговнокодить. Но делать это управляемо: есть мы «занимаем» время у других процессов сейчас, то придется им возвращать потом.
Agile - это не про процессы, фреймворки, итерации и карго-культ. Agile - это про гибкость. Именно это подразумевается, когда говорят «культура». И эта культура должна выстраиваться сверху: бизнес. А уж как её построить - это вопрос к бизнес-процессам.
самостоятельно работает над своими процессами
А такое возможно в более-менее крупной организации?
Возможно, если руководство этой крупной компании захочет. И если бизнес-процессам в этой компании подходит именно agile, а не что-то еще.
По факту, аджайл с позиции идеологии есть у очень не многих (спотифай, семраш).
А остальные занимаются итеративной разработкой. Это не плохо. Но большинство менеджеров вообще не понимают о чем пишут, чем пользуются, как оно работает.
Начали вы хорошо про "Изменение потребности или решения в момент реализации", но дальше все равно скатились в кашу. Попробую быть объективным, хотя за такое, да по такой теме здесь обычно отхватывают.
Вы, наверное, раз 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 с двухнедельными спринтами. Потом мы осознали, что физически не успеваем поставить релиз в такой срок. Тогда мы сначала увеличивали длину спринтов, но всё равно было неудобно. Даже строили сложные конструкции в виде: спринт на разработку + спринт на стабилизацию релиза.
А причины искать не пытались? И устранять их потом? Явно нет, раз первым решением было увеличение "длины" спринтов, да еще и какие-то разные типы этих самых спринтов.
В общем ИМХО, навязываться не буду, минусующим рекомендую курить практиковать скрамбан)
Спасибо большое за такой развернутый комментарий, некоторые мысли я сохранила себе на подумать!
Но я вообще не рассуждаю "что не так с Agile". Наоборот, я очень привержена ее ценностям и в идеальном мире хотела бы наблюдать, как круто эти ценности реализуются в командах.
Вы пытаетесь вычленить определенную методологию "которую нельзя называть", но на самом деле в основном статья как раз таки про команды, которые не работают по определенному фреймворку/методологии, например Scrum/Kanban или Lean.
Чаще всего в больших компаниях таких чистых методологий не бывает. И в итоге признаки команд, о которых я пишу такие:
а) команды работают итеративно;
б) команды заявляют о гибкости (например могут по потребности запилить новую фичу);
в) организационно это что-то между продуктом и проектом.
Именно с этим связана лексика, которую я использовала ("работают по Agile", "руководитель команды", "менеджер команды", "менеджер продукта" и т.д.), чтобы не относить к определенному фреймворку.
По поводу 10 оттенков менеджера: обычно у таких команд, которые застряли где-то в середине определения своего производственного процесса и методологии, есть некий административный лидер, например тот кто коммитится за бюджет или набирает команду. И он и не совсем Product Owner, и не некий Scrum менеджер, который поддерживает команду, и не Delivery Manager, который отвечает за доставку реализации, а что-то между всем этим и еще разными вариантами. Вот я как раз писала о том, как понять, что этот "менеджер" застрял где-то в середине определения, а с ним и вся команда.
А по поводу жесткой привязки к методологиям, отвечу так: не вижу ничего плохого в том, чтобы набрать инструментов из разных фреймворков. Например взять принцип наполнения релиза, как спринта из Scrum, визуализацию и сервисную модель из Kanban для определенной части команды (для аналитиков например). Важно, чтобы инструмент мог закрыть потребность команды потребности команды в текущем состоянии.
Возьмем например Scrum. Круто, если фреймворк закрывает потребности команды и клиента полностью. Но, при работе с большим бизнес-заказчиком, попробуй ему скажи, что перекраска кнопки пойдет только в следующий спринт, потому что у вас Scrum. Задача ведь - закрыть потребности бизнеса.
Та же ретроспектива несет ценность получения обратной связи и применима как в Scrum, как в Kanban так и в Waterfall в каком то изощренном виде. Основная задача - отслеживание проблем, тюнинг процессов и состояния команды. Ретроспектива - хороший инструмент для этого.
А без нее я даже не знаю как тюнить процесс, разве что ходить на 1-1 встречи с каждым из команды. Поэтому в том числе внесла отсутствие такой механики в список ошибок.
Если бы в реальном мире все было так прозрачно и все работали по прозрачной методологии, которая описана в книжках, было бы очень круто, но так бывает редко, к сожалению
Понимаю вас, здесь скорее претензия к тому, что не попробовав сделать правильно то, что проверено и обосновано (в свою очередь потому, что никто не хочет вникать как именно оно должно правильно работать - и это именно так и есть), начинаются попытки изобрести велосипед и подстроить его под свои процессы, вместо того, чтобы изменить, в первую очередь, свое мышление и за ним и выстроить правильный подход. Как говорится, вы даже не попытались сделать правильно, вникнуть и понять, а потом говорите, что оно не работает (это не вам).
Такой комментарий тянет на статью!
Я уточнила у аналитика, в чём дело. Оказалось, что на регулярных встречах приоритизация выглядит примерно так: «Займись интеграциями»
Что мешает аналитику подойти к продакту и уточнить, что он хотел? Кажется, это прямая обязанность аналитика собирать требования.
Agile гарантирует быструю доставку?
Таки да, идея в том, что аджайл гарантирует быструю доставку. Но имелось в виду, быструю по сравнению с вотерфолом, где заказчик полтора года ждёт софт, который к моменту релиза уже как бы и не нужен.
Вы верно говорите.
Но если система требует суммарно разработку в полтора года, то и по фреймворкам Agile команда суммарно потратит полтора года, а то и больше.
Просто через месяц команда уже выпустит 1/20. Но это будет та самая 1/20 первоочередная фича для пользователя, как я привела в примере декомпозиции.
То есть мы быстрее выпустим первый инкремент, но это не значит что команда будет работать быстрее и быстрее сделает весь «проект».
Так что тут действительно зависит от того, что мы имеем в виду под «быстрой доставкой» - скорость разработки или скорость закрытия первичных потребностей
Просто через месяц команда уже выпустит 1/20. Но это будет та самая 1/20 первоочередная фича для пользователя, как я привела в примере декомпозиции.
Может, мне так не везло, но по моей практике крайне редко видимые для пользователя фичи линейно соотносятся с затраченным трудом на разработку. И запросто может оказаться, что 1/20 видимых фич будет составлять 80% от всей разработки.
10 признаков недопонятого Agile, или почему ваш Agile не работает