Задача agile-коуча — сделать работу организации эффективнее. Если он сталкивается с сопротивлением, это может быть звоночком: кто-то в компании не хочет становиться прозрачнее. Важно узнать у человека причину его сопротивления — возможно, в нём есть рациональное зерно: например, у специалиста есть удобный инструмент для автоматизации рутины, и ему кажется, что новый подход всё сломает. Поговорив, можно создать условия, при которых человек сам захочет менять привычки, или же работать с ним постепенно — внедрять одну небольшую перемену за другой.
- Люди важнее процессов и инструментов.
если так, то оставье программистов в покое. пусть планово работают по уже утверждённым стандартам и выпускают качественный продукт, а не скачут по веткам изменений. зачем вы их убеждаете программистов не сопротивляться изменениям? Вы как оцениваете затраты на переходные процессы при изменении подходов?
- Работающий продукт важнее исчерпывающей документации.
А как вы понимаете, что он "работаюший"? Ведь документации акиуальной нет. Докоучились до того уже, что вот сейчас приходится маяться с сервисом у которого "документация" для галочки. половина указанных методов не работают, примеров нет только километры непонятной спецификации и тд и тп
- Взаимодействие с заказчиком важнее согласований условий контракта.
Конечно. Посадим аккаунт менеджера, который будет вместо решений проблем тянуть кота за что-то.. и при каждом конфликтном случае ссылаться на пункт договора. Весьма удобно.
- Готовность к переменам важнее следования первоначальному плану.
Вот вот... Постоянные скачки. Сегодня бежим туда завтра сюда. Ведь только менеджеры и коучи понимабт смысл работы. Программисты это так.. аналог чатгпт... ввёл новый промпт и вуаля..
ну и шляпа.
Как PM полностью с вами согласен. Здесь работает принцип "заставь дурака богу молиться - он лоб расшибет".
Чтобы какой-нибудь скрам эффективно заработал в команде, надо очень много допущений иметь.
Дух договора выше буквы? Расскажите это клиентам, которые теряют любые ограничения в своих хотелках, принимая лояльность партера за слабость, и которые при этом последствия своих неудачных решений сваливают на исполнителей. Дух договора должны обе стороны соблюдать, чтобы это работало. Да и то, втихаря подглядывая на договор, чтобы не отходить от него в вольных интерпретациях его пунктов.
Скачки туда сюда или готовность к переменам. Ха, не каждому разработчику, даже если он в продуктовой разработке, можно объяснить что такое эмпирический подход в бизнесе, когда постоянно приходиться экспериментировать, чтобы нащупать верные бизнесовые решения. И это конечно отражается и на разработке. Сегодня пилим одно, завтра отказались от этого, пилим другое. Команда подгорает из-за сжатых дедлайнов и резких изменений в перечнях задач. И тут речь не про то, что задачи каждый день меняются, а скорее про то, что уже описанный и реализованный функционал приходиться переделывать, раз за разом. А если новый владелец продукта ещё придет....это вообще ахтунг! Тут надо понимать, что решения владельцев продуктов не всегда профессиональны, а мнение команды может и не учитываться.
Люди важнее процессов. Конечно, если это продуктовая команда, где каждый участник чуть ли не универсал в компетенциях. Где приходит владелец продукта и говорит, что ему надо, а все остальное решает команда сообща. При этом владелец продукта прислушивается к команде и даёт ей достаточно самостоятельности. Много ли вы таких команд знаете? Где разработчик сам задачу опишет, а потом закодит ее, и протестит если надо? А если у тебя за полгода состав команды уже второй раз обновился? (спецов перетасовыают внутри компании, кто-то увольняется, новые приходят). Это ещё цепляет следующий постулат про документацию, когда работающий продукт важнее. А ведь продукты и команды могут быть немаленьким, состоят из сотен человек.
Без нормальной документации новые разработчики будут тыкаться наугад. Решать задачи в 3-5 раз дольше, чем могли бы, сроки погружения в проект вырастут кратно и т.д.
В общем, нельзя сказать что гибкие методологии это плохо. Отдельные методики и ритуалы очень полезны. И они не новы! Дейли - это те же летучки на советском производстве с утра, ретроспектива - это собрание по наболевшим вопросам и т.д. В СССР в свое время тоже свой аджайл придумывали, типа НОД - научная организация труда.
Поэтому, я считаю, что все это лишь новояз. Который нельзя слепо копировать. Нельзя в это фанатично верить. И применять стоит очень осторожно. Только то, что действительно помогает. Есть академические теории управления, которые куда богаче и глубже описывают многие важные вещи. У тех же японцев можно многому научится (tps, кайдзен), голдрата почитать. В профессиональном мире скрам выглядит как игрушка
На самом деле вы и правы, и неправы одновременно. В ваших примерах много боли от неграмотного управления. Я вас понимаю.
Менять надо всё: и подход к управлению, и мышление инженера и его отношение к ограничениям.
"Постоянные скачки. Сегодня бежим туда завтра сюда. Ведь только менеджеры и коучи понимабт смысл работы" — пример нездоровой работы. Менять приоритеты каждый день — это не эджайл. Это противоречит нормальному процессу создания качественного продукта. Так и подрывающиеся жопы членов команды — это проблема. Люди важнее процессов. Людям должно быть комфортно, и они должны понимать одинаково, что выбранные приоритеты и приципы принятий решений и их пересмотра не мешают создавать качественный продукт, а наоборот способствует этому.
Суть "гибкости" эджайла не в смене приоритетов хоть каждый час, а в умении подстраиваться под изменения (рынка, понимания ЦА и её требований, бюджетных ограничений) и делать хороший продукт. Это "ловкость" и "проворность". Но никак не "сумбурность" и "хаотичность". Эджайл — это про здравый смысл, а не дикость.
"Посадим аккаунт менеджера, который будет вместо решений проблем тянуть кота за что-то.. и при каждом конфликтном случае ссылаться на пункт договора". Это как раз и противоречит идее "взаимодействие важнее согласования условий контракта". Если менеджер не способен заблаговременно выявить потребности клиента или в процессе понять, что он ошибся на старте, и перестроиться в том числе по условиям работы, это не лучший менеджер, и ему нужно развиваться как управленцу.
Суть идей эджайла в том, что не отрицается важность того, что справа. Речь про более высокий приоритет того, что слева. Например идея "работающий продукт важнее исчерпывающей документации". Документация не "не важна". Важнее появление работающего продукта.
В вашем примере "сейчас приходится маяться с сервисом у которого "документация" для галочки. половина указанных методов не работают, примеров нет только километры непонятной спецификации", кажется, продукт не рабочий. Какой смысл в документации, если половина методов не работает? Документация должна соответствовать тому, что есть и работает. Нужно в целом делать "хорошо и качественно". Это в двух словах не объяснить. Вы бы апеллировали к некачественной или отсутствующей документации, если бы сервис, который вы приняли в работу, работает как часы, спроектирован интуитивно, понятно, код его чистый и сам себя документирует?
На самом деле, идеи эджайла — это картина идеального мира, некая утопия, к которой неплохо стремиться. Но достигнуть её непросто, если не невозможно. Чтобы соответствовать этим идеям, нужно много слушать, думать и доверять. С этим много проблем как у команд и руководителей, так и у заказчиков, спонсоров и их менеджеров.
Аджайл - это кошмар программистов.
Комментарий недоступен
Сами 4 принципа нормальные, как мне кажется, то во что это превратили сейчас - жопа. Всё из разряда "хороший тамада и конкурсы интересные" с коучами, а не нормальная работа.
1. Скрам и в какой то степени аджайл - это набор проектов длиною в спринт. А все про проекты уже описано и изучено. В случае с аджайлом просто не применяется ничего с лозунгом: "мы же гибкие". Хуибкие.
2. Проблемы в менеджерах. Не умеют управлять проектами в целом, не важно какими. Нужно ТЭО, бизнес анализ, rnd/НИОКР, эти вещи всегда будут в том или ином виде, а недоменеджеры просто перекладывают все это на разработчика: "программировай, дальше разберемся" разбираться надо до кодинга и не разработчику.
Мое мнение: можно итерациями, можно гибко, можно как угодно, но проект надо вести как проект. И у аджайла в этом ловушка - там не написано как поступать эффективно.