Иногда мне кажется, что шутки о том, что руководство внедряет Agile, чтобы успеть больше при меньших затратах, не так уж и далеки от истины. Я редко видел, чтобы команды разработчиков понимали Agile как что-то большее, чем просто набор церемоний, чаще всего ассоциируемых со Scrum.
Проекты связаны с ограничениями. Три фундаментальных из них это сроки, стоимость и содержание.
Немного подробнее про "треугольник компромиссов"
Связку этих ограничений — сроков, стоимости и содержания — называют треугольником компромиссов. Где-то его даже называют инструментом. Я бы предложил относиться к нему как к иллюстрации зависимости между этими тремя ограничениями.
Представьте, что вы можете тянуть за углы треугольника, но изменение одного угла неизбежно влечет за собой изменения в остальных двух. Если мы хотим сделать больше работы (содержание) за меньшее время (сроки), это, скорее всего, приведет к увеличению стоимости. Если мы стремимся сократить стоимость, то либо сроки увеличатся, либо объем работы придется уменьшить. Это постоянная борьба и балансировка, с которой сталкиваются все команды и менеджеры проектов.
Проект, у которого есть шанс на успех, начинается с фиксации одного ограничения, например, бюджета. Затем, исходя из бюджета, рассчитывается и фиксируется срок, и, в случае необходимости, корректируется объем функционала.
Бизнес часто готов докинуть ресурсов, людей в команду, чтобы сократить сроки. Только сделать это бывает очень сложно и не всегда возможно. В лучшем случае срок останется прежним, а может и увеличится.
Экономия на качестве – это тоже не про Agile. Обычно, говоря о качестве, многие понимают баги или дефекты. Но есть техническое качество, которое выражается в том, насколько продуктивно команда сможет работать над задачами в будущем. Чем хуже внутреннее качество, тем больше времени команда тратит на добавление нового функционала. Если техническое качество высокое, то на короткой дистанции можно взять у продукта в “долг”. Главное помнить, что это в будущем будет стоить бизнесу сокращением производительности команды. А ещё, вернуть технический долг потом будет дороже, чем сделать без "долга" сразу. Технический долг можно воспринимать как кредит в банке: возвращать придётся больше, чем взял. Поэтому важно понимать зачем это делается и откуда потом этот “долг” будет “оплачен” (рекомендую почитать статью о том, что технический долг, это не только проблема команды разработки). Если этим подходом пользоваться бездумно, то ситуация будет не лучше, чем когда люди берут кредиты, чтобы покрыть кредиты, которые были взяты, чтобы покрыть кредиты. В конце продукт будет ждать техническое банкротство.
Тем не менее, компании стремятся к оптимизации. Они хотят больше функционала и быстрее. Поэтому кто-то отправляет сотрудников на курсы и тренинги, а при наличии средств нанимает коуча из консалтинговой компании. В то же время, действительно продвинутая внешняя консалтинговая организация не гарантирует результат, а обещает двигаться итеративно. С возможностью завершить сотрудничество оплатив последний этап. По сути, вы покупаете время без гарантии результата. Они понимают, что продают стандартизированный процесс, который без изменения мышления ключевых руководителей, команды, ценностей компании и бизнеса не принесет ожидаемых результатов. Они расскажут, как все круто и легко, но не упомянут, что это не главное. Точнее упомянут, чтобы потом сказать, "Ну мы же говорили, вы сами виноваты!"
Но свою работу они сделают: введут короткие спринты, установят регулярные стендапы, на которых каждый строго рассказывает, что сделал, что планирует сделать и с какими проблемами столкнулся. Запланируют даты демонстраций, ревью спринтов, рефайнмент бэклога и другие модные артефакты. Однако, менеджмент вряд ли прислушается к рекомендациям консультантов меняться самим. Ведь проблема не в них, а в команде. Верно? Конечно, будет наведена некоторая прозрачность в процессах, что тоже неплохо. Но в целом, руководство не останется недовольным результатами команды, и, не видя других вариантов, будут вынуждены мириться с существующим положением вещей. Как только они наиграются в Agile и ослабят контроль над процессом, в команде появится "Agile собственного приготовления".
Так где же та магия "делать больше за меньше"? Её нет. Можно управлять содержанием работ. Но бизнес не согласится. Потому что, когда уже заранее кто-то продумал как делать и спустил это в команду разработки в виде набора спецификаций с декомпозицией на user stories, всякое управление содержанием воспринимается как просто отказ от выполнения тех или иных элементов бэклога.
Бизнесу кажется, что ему нужно всё. На самом деле это не так, но ему кажется что нужно.
В продукте была разработана небольшая функция выбора региона. Она прошла через разработку автоматических тестов, было приемочное тестирование. Выпустили и были довольны. Однако, когда проанализировали телеметрию, выяснилось, что за год функцию выбора региона использовали только тестировщики. Пользователям она была не нужна, хотя изначально функция считалась необходимой для выпуска самой первой версии продукта.
При таком подходе разработчикам предоставляется свобода выбора, но только в рамках деталей реализации. Например, они могут решить, сделать ли простое всплывающее окно с текстом об ошибки или добавить к нему дополнительные свистелки и что-нибудь еще. Затем, следуя принципам Agile, команда совместно приходит к выводу, что достаточно будет стандартного сообщения. Создается впечатление, что решение принято всеми вместе – вот он, Agile в действии! Однако, Владелец Продукта изначально склонялся к более простому варианту, который потребует меньше времени. Но поскольку коуч настаивает на Agile, была предложена "гибкость", чтобы он не мешал работать.
Если же команда разработки предлагала вариант автоматической обработки ошибки вместо сообщения, Владелец Продукта начинал согласование изменений со своим руководством и другими заинтересованными сторонами. И поскольку Agile-коуч требовал не определять заранее требования, а обсуждать их с командой, он просто не делился заранее подписанными и прибитыми к стенке гвоздями требованиями.
Когда в компании произошли организационные изменения, поддержанные CEO, которые предоставили команде и владельцу продукта реальное право решать как будет выполнена та или иная задача, процессы стали более гибкими, и работа наладилась. Это позволило владельцу продукта полностью реализовать свой потенциал в новых условиях, где структура и подходы компании стали способствовать более эффективной работе.
Бизнес будет хотеть видеть реализацию как можно быстрее. Но если кто-то влиятельный держит содержание жёстким, разработчики более или менее поддерживают качество на приемлемом уровне и не увеличивают технический долг, то страдают именно сроки (вместе со стоимостью). Работа идёт своим чередом, разработчики прилагают усилия, но не успевают.
Ну не придумали, как поменять этот треугольник компромиссов и создать какую-то червоточину, чтобы обойти эти ограничения.
Начнём с того, что, как мы обсудили ранее, очень сложно что-то менять, если у представителей бизнеса мышление в формате водопада. Оно интуитивно проще, понятнее, привычнее. Иногда по-другому и не сделаешь, например, когда приходится аутсорсить разработку (на самом деле это не всегда так, но допустим). Но если есть возможность, то скорректировать содержание можно, не отказываясь от функционала, а пересматривая идеи и подходы к решению. Одну и ту же проблему можно решить множеством способов. Когда разработчики вовлечены в обсуждение решения проблемы и понимают, какую пользу они хотят принести пользователю, шансы на нахождение неожиданного и эффективного решения возрастают. Таким образом, проблема будет решена, и сроки будут сэкономлены.
Программисты (хорошие программисты) по своей сути ленивы и, если найдут простое решение проблемы, будут только рады его предложить.
Продавцам было необходимо видеть в CRM контактные данные потенциальных клиентов, которые можно было найти во внешней системе. Команде разработчиков была поставлена задача доработать CRM для синхронизации данных из этой системы. Однако, после общения с продавцами и понимания их реальных потребностей, команда решила отказаться от первоначально предложенного плана и разработала расширение для Google Chrome. Это расширение позволяло автоматически отображать необходимые данные прямо в формах CRM без манипуляции с данными, упрощая процесс и сокращая время на разработку в несколько раз.
Итак, чтобы внедрение Agile/Scrum не превратилось в водопад с частыми итерациями, необходимо вовлечь команду в решение проблем бизнеса. Следует исключить из должностной инструкции владельца продукта пункт о необходимости согласования требований с заинтересованными сторонами и предоставить ему полномочия для самостоятельного согласования этих требований на основе диалога с командой. Для бизнеса, не так важно, как будет решена та или иная проблема. Бизнес существует благодаря решению проблем, которые либо приносят доход, либо сокращают расходы. Задача – решить проблему максимально экономично, чтобы решение приносило значительно больше денег, чем зарплата команды и прочие расходы на ее содержание. Желательно, в несколько раз.
Если требования согласовываются до того, как команда разработки о них узнает, то это точно не Agile. В этом нет ничего плохого; важно просто правильно относиться к данной ситуации и не создавать неверные ожидания. Короткие итерации сами по себе не делают команду Agile. Если требования определены заранее, не удивляйтесь, что один спринт уходит на проработку фичи, затем три спринта – на разработку, после чего следует фаза стабилизации и тестирования. И, конечно же, даже в эти рамки не удается попадать.
Комментарии (19)
clarifyingman
03.06.2024 11:22Если требования согласовываются до того, как команда разработки о них узнает, то это точно не Agile.
А можете объяснить почему?
Выглядит как карго-культ: "Чтобы был Agile, необходимо ознакомить команду разработки с требованиями до согласования требований. И тогда фичу получиться реализовать за один спринт, а не за 4 (или даже больше, если считать стабилизацию и тестирование)."
Что это за магия такая?
funca
03.06.2024 11:22+1Что это за магия такая?
Agile это не про разработку, а про управление ожиданиями клиента. Разработчики здесь выступают в роли дрессированных животных. Але-оп, и все бросаются пилить важную-срочную-дешевую фичу. Але-оп - и уже пилят другую. Рассказывают, что сменились бизнес приоритеты, хотя по правде - просто зрители что-то заскучали или перестали доверять.
clarifyingman
03.06.2024 11:22Agile это не про разработку, а про управление ожиданиями клиента.
У меня другая точка зрения. Agile - это тот процесс, без которого эффективная разработка невозможна в принципе.
Как без налаженного конвейра сложно собирать автомобили, так без налаженного Agile сложно пилить задачки.
Я бы даже сказал, что вся наша жизнь - Agile. Только в сфере личных проектов, которая гораздо шире сферы разработки ПО.
dididididi
03.06.2024 11:22+1Знаю я людей у которых жизнь аджайл)
Женился, родил ребёнка, тут требования поменялись - развёлся, купил абонемент в спортзал - сходил два раза, ещё него естесна есть весь комплект для сноуборда хай класса, но кататься е у нельзя из-за коленки, купил хату в ипотек и через три месяца переехал в Австралию.
netleon Автор
03.06.2024 11:22Аджайл в жизни – это скорее о гибкости и адаптации, а не о хаотичных изменениях без ретроспективы. Возможно, таким товарищам стоит ввести в свою жизнь роли Product Owner и Scrum Master, чтобы задачи и изменения были более осмысленными и приводили к устойчивому развитию, а не к вечному циклу "спринтов" без достижения "инкрементов" счастья.
funca
03.06.2024 11:22+3Как без налаженного конвейра сложно собирать автомобили, так без налаженного Agile сложно пилить задачки
Конвейер (manufacturing) это серийное производство, где каждая последующая деталь, выпадающая с конвейера, будет точно такой же как и десятки тысяч предыдущих.
Разработка (development) - штучное производство под конкретные нужды. Здесь требования сильно варьируются и каждое приложение по-своему уникально.
Agile это зонтичный термин. Он декларирует набор ценностей из расчета, что любая проблема может быть решена на уровне коммуникации между участниками проекта. Но без конкретики, что и как - это удел конкретных методологий.
Говоря про Agile, часто имеют ввиду Scrum, который пытается натянуть процессы управления конвейером на разработку. Фактически он сводит любую интеллектуальную деятельность к некоему общему знаменателю - таскам, story points, и дедлайнам.
Где-то на уровне здравого смысла люди осознают, что разработка лендингов, машинное обучение и поиск лекарства от рака - это по сути довольно разные вещи, которые требуют разных подходов и в управлении. Но на практике внедряют то, что проще внедрить, а не то что лучше подходит.
netleon Автор
03.06.2024 11:22+1Лучше и не скажешь. Хотят прелести одного инструмента, но не учитывают, что он подходит тоже не для всего. И, как пишут в комментариях, натягивают сову на глобус.
netleon Автор
03.06.2024 11:22+2Согласен с тем, что Agile тесно связан с управлением ожиданиями клиента. Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей, а затем их передают команде с предложением "давайте в Agile-формате найдем способ сделать это подешевле". Естественно, команда что-то придумает, но не сможет сделать функционал дешевле, чем это возможно в принципе. Ситуация бы изменилась, если бы команде дали возможность предлагать изменения в функционале, чтобы решить проблему иным, более эффективным с точки зрения баланса функционала и технологий. Это не гарантирует нахождение решения, так что магии нет. Но если требования заранее зафиксированы, шансы решить проблему "побыстрее" стремятся к нулю.
clarifyingman
03.06.2024 11:22Часто вижу следующую картину: в рамках водопадной модели все требования прорабатываются до мелочей, а затем их передают команде с предложением "давайте в Agile-формате найдем способ сделать это подешевле".
Побуду занудой: в таком процессе предлагаемое вами изменение не изменит сути процесса разработки. Как процесс не был Agile-ом, так он им и не станет.
Agile - это не про поиск самого дешевого решения. Он больше про гибкость (менять продукт в соответствии с новыми требованиями) и возможность добавлять функционал небольшими порциями.
Есть ощущение, что вы по одному случаю (который специфичен для вашей схемы работы, и вам встречается довольно часто), пытаетесь натянуть сову на глобус.
netleon Автор
03.06.2024 11:22Существуют необходимые и достаточные условия. Детализация требований командой является необходимым, но не достаточным условием. Так что с вашим комментарием полностью согласен.
Batalmv
03.06.2024 11:22+2Итак, чтобы внедрение Agile/Scrum не превратилось в водопад с частыми итерациями, необходимо вовлечь команду в решение проблем бизнеса.
Ну попробуйте :) Только есть одна проблема, мааааленькая. Команда на 99% вообще не в курсе даже мало мальских деталей бизнеса. А чтобы быть в курсе, иногда надо проработать в домене не один год, и не разработчиком.
Все, приехали. Или вы реально думаете, что взяв условного програмиста, вы мгновенно (ну "тыжпрограмист") получите бизнес-процесс, который подходит всем участникам и не нарушает требования "регуляторов"? Тогда я вас рассстрою. Это часто не так.
Просто есть мир "небольших" коммерческих приложений, там наверное да. А есть мир, где надо сделать решение для большой конторны, в которое снаружи будет ломиться куча разных пользователей, а изнутри это будет поддерживать (не систему, а итоговое решение) штук 10 департаментов
--------------
А еще есть более чудесные ситуации, когда у вас еще не определено, какая система чем занята сейчас и в будущем. И тогда чудное решение
Продавцам было необходимо видеть в CRM контактные данные потенциальных клиентов, которые можно было найти во внешней системе. Команде разработчиков была поставлена задача доработать CRM для синхронизации данных из этой системы. Однако, после общения с продавцами и понимания их реальных потребностей, команда решила отказаться от первоначально предложенного плана и разработала расширение для Google Chrome. Это расширение позволяло автоматически отображать необходимые данные прямо в формах CRM без манипуляции с данными, упрощая процесс и сокращая время на разработку в несколько раз.
будет выброшено на помойку, так как завтра окажется, что таких систем через месяц будет 5, а через полгода еще дюжина. И тогда чудесный виджет в одну из них будет маленьким уроком тем, кто решил посоветоваться с командой
--------------------
Пример
В продукте была разработана небольшая функция выбора региона. Она прошла через разработку автоматических тестов, было приемочное тестирование. Выпустили и были довольны. Однако, когда проанализировали телеметрию, выяснилось, что за год функцию выбора региона использовали только тестировщики. Пользователям она была не нужна, хотя изначально функция считалась необходимой для выпуска самой первой версии продукта
тоже вызывает вопросы. А с чего бы команда помогла как-то в этой ситуации? Понятно, что можно поговорить, тем более что UI/UX часто рисует выделенный дизайнер, который обязательно советуется с фронт либом. Но я вот не могу понять, причем тут Agile либо его отсутствие. Если дизайн система не очень - это просто потому что она такая, а не потому что методология неверная. Вот и все
----------------
При таком подходе разработчикам предоставляется свобода выбора, но только в рамках деталей реализации. Например, они могут решить, сделать ли простое всплывающее окно с текстом об ошибки или добавить к нему дополнительные свистелки и что-нибудь еще.
Это вообще прекрасно. Давайте каждый раз для фичи решать, какой вариант дизайна компонент использовать.
netleon Автор
03.06.2024 11:22Я внимательно прочитал ваши замечания и хочу отметить, что приведённые иллюстрации в статье, на которые вы ссылаетесь, служат лишь для пояснения основного текста и не должны рассматриваться как отражение сути статьи. Они немного утрированы и представлены без всего контекста, который мог бы раскрыть более глубокое понимание ситуации.
Тем не менее, я добавлю чуточку информации.
Что касается программистов и аналитиков, то действительно, не каждый программист стремится быть аналитиком, и это нормально. Главное – уметь принимать и учитывать обратную связь от разработчиков. Когда они указывают на невозможность реализации того или иного решения, необходимо вести диалог и быть готовым к изменениям требований, а не оказывать давление. К тому же, в команде всегда найдутся те, кто хочет и может влиять на требования, и это ценно.
Пример с расширением для Google Chrome иллюстрирует, что команда может предложить альтернативные решения, которые могут быть более эффективными, даже если они не имеют долгосрочной перспективы. В мире быстрых изменений и неопределённости бизнес-процессов, решения с коротким жизненным циклом могут быть более предпочтительными, чем дорогостоящие и сложные системы, требующие значительных ресурсов для поддержки и модификации. В том примере был именно такой случай: писать дорого или быстро. Время жизни - несколько месяцев. Причем ценность была именно в скорости получения первого результата. Владелец продукта пришел с идеей сделать как в прошлый раз, т.к. технически даже не задумывался о варианте с расширением. Но команда преложила свое, Владелец продукта, хоть и бы не совсем уверен изначально, но в итоге поддержал команду.
Что касается примера с ненужным функционалом выбора региона, он опять же иллюстрирует предыдущий абзац, не более. То, как такое не допустить - отдельная тема и вы немного упомянули.
Batalmv
03.06.2024 11:22Так у вас выводы, скаже так, не очень верные :)
Ну смотрите
Итак, чтобы внедрение Agile/Scrum не превратилось в водопад с частыми итерациями, необходимо вовлечь команду в решение проблем бизнеса. Следует исключить из должностной инструкции владельца продукта пункт о необходимости согласования требований с заинтересованными сторонами и предоставить ему полномочия для самостоятельного согласования этих требований на основе диалога с командой. Для бизнеса, не так важно, как будет решена та или иная проблема.
Суть не вовлечение команды, это очень абстрактный посыл
Есть product, которые отвечает за успешность продукта на рынке перед спонсором. Он определяет общее направление куда, согласовывает с внешними игроками. Если его нет - у вас проблема.
Есть аналитик. Он помогает строить продукт, пишет сторьки или как оно там у вас построено, контролирует скоуп. Если его нет - у вас проблема.
Есть архитектор/тимлид, который отвечает за выполнение нефункционалыных требований. Он "не вовлекается", а делает свою работу. Если его нет - у вас проблема.
Есть дизайнер, который определяет дизайн систему, и макеты конкретных экранов. Если его нет - у вас проблема.
Нет команды. Есть конкретные люди и роли, которые должны быть закрыты. Или у вас проблема.
--------------------
Если же коммуникация где-то построена по принципу "я начальник - ту дурак", ну такое - это скорее свойство конкретных людей
-------------------
Про "исключить из должностной инструкции владельца продукта пункт о необходимости согласования требований с заинтересованными сторонами" - даже сказать нечего. Попробуйте что-то выпустить в большо enterprise без согласования, а я посмотрю
Дело не в примерах, а дело в ваших советах. В большинстве случаем они будут скорее вредніми, чем полезными :(
netleon Автор
03.06.2024 11:22Я думаю, как я не старался сделать и просто и емко, где-то не совсем очевидны все посылы. Вот смотрите:
"Иногда по-другому и не сделаешь, например, когда приходится аутсорсить разработку (на самом деле это не всегда так, но допустим). Но если есть возможность, то скорректировать содержание можно, не отказываясь от функционала, а пересматривая идеи и подходы к решению."Это именно то, о чем вы говорите. Где-то нельзя. А что касается "Попробуйте что-то выпустить в большо enterprise без согласования, а я посмотрю", то я работал с PO, которые умеют даже в таких случаях проявить гибкость и даже на госзаказах гибко (причем реально закрывать, что не придерешься) закрыть требования. Мы с таким, закрыли гос заказ который все считали провальным. Причем заказ делался не под нас, так что к проверке подходили со всей строгостью. Конечно, главный функционал у нас работал как надо, а вот "заградительные" требования, которые пишутся, чтобы не допустить других участников, мы закрыли. И заказчику пришлось их принять. Опять же, не везде и не всегда такое возможно.
Встречный вопрос к "Если его нет - у вас проблема.". Допустим, проблема. Вот все остальные роли ок, а с PO, проблема. Что делать? Вопрос открытый. Я думаю, если вы напишите об этом статью и поделитесь своим опытом, то с удовольствием почитаю. И, думаю, не только я буду благодарен, если раскроете вопрос.
Batalmv
03.06.2024 11:22Допустим, проблема. Вот все остальные роли ок, а с PO, проблема. Что делать? Вопрос открытый
Есть практический опыт, когда PO был заменен по причине своей неадекватности. Да, понадобилось определенное время, но оно того стоило.
Секрет успеха был в том, что ПМ обладал внушительным кредитом доверия спонсора и смогла доказать, что PO - главный тормоз прогресса. Понятно, без этапа сбора доказательств это не работает, так как голосовно обвинять бесперспективно
Но также надо понимать, что любой конфликт - это продукт взаимодействия двух сторон, и, возможно, перед тем как пытаться идти на крайние меры, стоит проверить, а может "корона" на собственной голове требует обработки напильником
ManGegenMann
03.06.2024 11:22+1Хочу вам предложить один манифест. Это очень качественная и, что главное, рабочая методология. Ей пользовались многие успешные компании и даже топы вроде IBM и Apple с Google. Она появилась давно, но и сейчас дает ощутимые результаты при правильном применение.
https://programming-motherfucker.com/
Boethiah
03.06.2024 11:22Автор забыл, что а) для формирования требований есть бизнес аналитики (иные специалисты) + маркетологи, которые и обсуждают с заказчиками/продакт оунерами, что можно, что не можно, что нужно, что не нужно. Люди, которые не имеют соответствующих знаний и опыта (в данном случае команда, разрабатывающая продукт), не могут сами решать, как делать, какие требования там должны быть - как предлагает автор сей статьи. Если что-то сделать технически не возможно или можно сделать лучше/проще, то это все обсуждается на пленнингах/рифайнментах - то бишь, команда в некоторой степени может "управлять содержанием"; б) продакт оунер это не мальчик на побегушках, ему не нужно каждый раз бегать к своему руководству, чтобы одобрить те или иные требования.
netleon Автор
03.06.2024 11:22Вы абсолютно верно подметили, что даже в крупных структурах, где продакт-оунеру необходима поддержка аналитиков и маркетологов, можно наладить процесс таким образом, чтобы команда не только выполняла задачи, но и активно влияла на проект, внося свои предложения и получая возможность для обсуждения. В статье я действительно акцентирую внимание на ситуациях, когда требования предъявляются как непреложные истины, "прибитые гвоздями к стенке". Это противоречит не только принципам Agile, но и общепринятым методикам управления разработкой. Например, PMI ясно указывает на необходимость обсуждения требований с командой, что подтверждает важность совместной работы и гибкости в процессе разработки.
А то, что вы пишете про продуакт-оунера, это верно. В моём примере человека наняли, но по факту руководитель этого PO ввёл какой-то неадекватный менеджмент и жёсткие процессы, где не предоставлял PO необходимых полномочий. Собственно, мы c CEO это и исправили впоследствии.
sshmakov
Шутки? Так это все было шуткой?!
Это не так, но объяснить это бизнесу если не невозможно, то очень трудно. Проще забить и двигаться по вновь намеченному плану.
Всего-то? Дать номинальному "владельцу продукта" все полномочия по созданию продукта? Эх, мечты...