Прийшов час осідлати справжнього Буцефала🏇🏻Приборкай норовливого коня разом з Newxel🏇🏻Умови на сайті
×Закрыть

Agile и fixed-price проект — совместимы ли?

Интересует мнение практиков: Кто сталкивался? На что это похоже? Чем кончается?
Мнение теоретиков или проповедников — не интересует.

LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Если у вас контракт Fixed all (price, date, scope) — Скрам внедрять не целесообразно. Да, вы сможете давать инкремент продукта каждые 2-4 недели, но менять скоуп после спринта вам по контракту нельзя. Так зачем тогда этот Скрам?

Если у вас Fixed-budget — по Скраму работать можно. Если заказчик захотел поменять скоуп — без проблем! Что то добавил, что то выкинул. Если что то ему приспичило добавить сверху, а урезать нечего — оплатил как add-on.

А, и главное — и там, и там очень важно в любой момент разработки знать ответ на вопрос "А было ли это (фича/реквест/"совет от эксперта") в обещанном скоупе? Или это уже add-on?"

Статья не закончена, но ответ прост — возможно, эффект положительный, кончается успехом:)
alex-lyashch.blogspot.com/...gile-ffp-1.html

Scrum is intended to be a place where enthusiastic people can work closely with their customers to derive the most valuable, creative products possible.
kenschwaber.wordpress.com/...an-and-scrum-2

Из опыта — нет, не совместимы, если под FP понимается классический треугольник budget-scope-quality с вершинами, фиксированными в контракте.

Пример Agile FP контракта можно посмотреть в презентации Джеффа Сазерленда. Лично я такую имплементацию Agile FP на практике (а аутсорсинге) не встречал, как правило, ограничиваемся промежуточными вариантами типа FP per story point. Так как в теории это красиво и классно, но для enterprise vendor management понятия FP и FS (fixed scope) неразрывно связаны, и такой контракт практически нереально будет протащить через project review board на стороне заказчика.

Ну почему все понимают этот треугольник именно как “budget-scope-quality” ?!
WIKI: Project management triangle

en.wikipedia.org/...gement_triangle

Так schedule-budget-scope в большинстве случаев неразрывно связаны. Т.е., нельзя, допустим, уменьшить бюджет, просто поменяв сроки и ничего не делая со скоупом. Или, наоборот, увеличить скоуп, оставив такой же бюджет и увеличив schedule. Зато качество можно варьировать (например, для увеличения scope или ускорения schedule). Опять же, часто schedule — величина не фиксированная жестко (т.е., при его провтыке проект все равно примут, пусть и со штрафами), а вот за оговоренные качество и скоуп в FP проектах будут драться до последнего..

Основной треугольник состоит из: Scope — Cost — Time. Предполагается что качество должно быть достаточным и отвечает за это именно подрядчик. Потому что заказчик не может сам «увидеть» качество а доверяет нанятым специалистам и их репутации. Более того: обычно контракт включает «гарантию» что если качество окажется ниже среднего по отрасли для данного типа проектов то подрядчик обязуется починить бесплатно.

Подход «качество можно варьировать» — в моем понимании означает халтуру.

Что такое «достаточное качество» в контракте (тем более, FP) имеет смысл фиксировать. Вы же не будете спорить, что уровень качества, вполне подходящий для игрушки, может не удовлетворять заказчика из аэрокосмической отрасли или инвестбанка? (впрочем, как и наоборот — смотря что делается для инвестбанка и что за игрушка)

Что такое «достаточное качество» в контракте (тем более, FP) имеет смысл фиксировать.

Оно как правило и фиксируется. Или как минимум есть фраза про среднее качество и гарантию как я написал выше.
Именно поэтому качество — это не переменная величина (не вершина треугольника). И манипулировать им по ходу проекта нельзя. В той же вики статье есть другой треугольник, где качество увязано с рисками — вот это имеет смысл. Т.е. если мы где-то все-таки пожертвовали качеством (например по требованию клиента) — то сразу же пишем риск и клиент с ним соглашается и отказывается от претензий.

Еще раз: я категорически против рассматривать качество как переменную. Так делают только жадные халтурщики, которые хотят взять fixed all (scope, cost, time) проект и получить побольше профита. Ведь даже если взяли fixed all и не укладываетесь, то есть еще честный вариант добавить ресурсов (за счет компании). А вот жертвовать качеством — это халтура.

если мы где-то все-таки пожертвовали качеством (например по требованию клиента) — то сразу же пишем риск и клиент с ним соглашается и отказывается от претензий

Я где-то говорил, что идти на компромиссы нужно без ведома клиента? Изначальный вопрос был не про «что делать, если не укладываемся», а «можно ли увязать Agile approach с fixed-everything». Собственно, мой месседж был о том, что это равносильно попытке использовать порш 911 для поездок на рыбалку — клиренс низкий, багажник маленький, да еще и фаркопа, чтобы лодку прицепить, нет. Словом — фуфло, а не машина.

Народ, огромное спасибо всем за ответы! А говорили — ДОУ не торт, ага. :)
Уже сейчас по этой дискуссии видно несколько рисков, промежуточных целей, а так же и вариантов маневрирования, которые можно было бы легко упустить.
Всё, что здесь написано, я собираюсь перечитать ещё несколько раз, и дать прочитать коллегам.

Alexander Kuznyak и Дима Лапшин — отдельное МЕГА спасибо!

якщо вимоги\специфікації\функіонал не змінюються під час фіксед-прайс проекта, то хоч скрум, хоч аджайл, хоч водопад, аби з людино-годинами не помилитися сильно, щоб можна було вписатися в бюджет

якщо вимоги\специфікації\функіонал не змінюються під час фіксед-прайс проекта

Утопия. ИМХО, по этому, собственно, автором и была создана тема.

Ти що ясновидячий?
А по моєму, ТС в ролі ПМа отримав FP проект із повним еджайлом, як результат — розрив шаблона

Ти що ясновидячий?

Иногда бывает.

проект із повним еджайлом

Это вообще что?

розрив шаблона

От вышенаписанной тобой фразы — да, таки разрыв.

таки разрыв.

спавжній розрив настає, це коли КуА джун із внутрішнім конфілктом просить мегабабла (оце і є «повний еджайл»), а його протежератор відкриває тему і починає поливати г-ном конкуруючу фірму.
п.с.

Я так і не зрозумів, де профіт?

Нет, но я понял у кого ответом на прямой выпрос является выброс говна на вентилятор с искажением всего чего можно в свойственной ему манере.

Чому утопія:
1) ТЗ: Создать убійцу фейсбука.
2) Бюджет: лімон баксоф об"єднаних штатів.
3) ПМ має створити аджайл команду для пожирання лімона і висеру на виході вбивці ФБ.
4) Профіт.

Какой лимон, ТЫ ШО???

Концлагерь.Газовая камера.Закрываются двери.
Вдруг открывается дверь и заходит гестаповец: — Плиточники есть?
Выходит здоровый хохол: — Ну, есть.
Гестаповец:- почем метр кладешь?
Хохол: — Ну, 10 баксов.
Гестаповец: — А за 5 баксов сможешь?
Хохол: — Зачиняйте двэри!!!

От Agile результат проекта мало зависит. Если вообще зависит. Все зависит от адекватности команды, менеджера и заказчика. А какой при этом был налажен процесс — дело второстепенное, хоть пиши код.

Если вообще зависит.

Зависит.

Все зависит от адекватности команды, менеджера и заказчика.

Если все вокруг адекватные, но не умеют работать друг с другом эффективно, толку не будет. Для этого и нужна какая-то методология разработки, процесс комуникаций и координации внутри команды и команды с клиентом.

Если команда состоит из очень сильных людей то процессы могут быть настроены так, как им удобно. Нужна «какая-то» (адекватная) методология разработки, не обязательно строгий Agile. Согласен с Alex Krakovetskyi, что некоторые команды могут давать хорошие результаты даже с методологией пиши код. Но вот если команда слабая, тогда строгая методология это необходимость.

Можно вопрос ? а зачем Вам нужно?

да войну разжечь наверное хочет, холи

Войну я хотел разжечь, но мой топик потерли -)))

да войну разжечь наверное хочет
Скорее победить в уже начавшейся... 8)

Предельно практический интерес.

Ярослав, очень прикольный топик.
Только, как практик и теоретик в одном лице, хочу спросить «вам зачем?». Из описания следует, что вы скорее удовлетворяете свое любопытство... делать не собираетесь. Так зачем оно вам? :)

Это просто ключевой вопрос, на который нужен ответ!

Теперь пара мыслей по теме:

Если вы делали fixed price проекты не по Agile, то, вероятно, понимаете риски и сложности. Во всех, подчеркиваю, <b> во всех </b> методологиях они одинаковы. Agile — всего лишь способ ВНУТРЕННЕЙ организации работ. Никакие внешние риски проекта он не убирает.

Чем мне нрпавиться тот же Скрам во время fixed price проектов, так тем, что у него есть железная дисциплина и очень мало вариантов обмануть себя и Заказчика о реальном состоянии дел. Если вы к этому не готовы, то не выбирайте Скрам.

В целом, если добавите конкретики и контекста (за пределами «просто любопытства»), то можно дать более четкие кейсы и описания.

Здесь очень важно понимать, что в подобного рода проектах SCRUM может быть использован как методика организации работ на фазе, собственно, разработки. Но следовать таким принципам Agile, как «проясняй требования по ходу дела» и «долгосрочное планирование — пустая трата времени» — равносильно самоубийству.

Причем тут тогда Agile? Это обычный итерационный вотерфолл (вполне работающий в таких случаях).

Да, совместимы. Причем совместимы даже при Fixed Price + Fixed Date.

Кто сталкивался? На что это похоже? Чем кончается?

У нас был Scrum. На что похоже? — На обычный Scrum :)
Заканчивается тем, что клиент в указанные сроки реально получает то что ему надо чтобы стартануть работающий бизнес.
В последствии допиливаются миноры и «хотелки», которые в процессе разработки складывались как feature requests вне scope-а fixed price контракта.
Если изменения таки нужны ПРЯМО СЕЙЧАС и критичны для клиента (изминилось видение или предпологаемая схема работы бизнеса, переигрались приоретиты фич и так далее) — тогда работа работается на основе T&M по change request-ам или выбрасываюся какое-то другие задачи из backlog-а чтобы впихнуть эти изменения.
Команда при такой работе может быть немного динамической, то есть немного расширяться или сжиматься при необходимости и/или желанию клиента.

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

Если клиент принципиально не участвует в процессе разработки и product owner на стороне команды или его роль выполняет scrum master в течении всего процесса, тогда еще проще.

ЗЫ:

И да, риски и асампшены в контракте достаточно объёмно описаны ;)

Причем совместимы даже при Fixed Price + Fixed Date.

Но НЕ совместимы при Fixed Price + Fixed Date + Fixed Scope (если под Agile мы понимаем SCRUM, Kanban и т.п. «ортодоксальные» методологии)

Agile — философия.
А методологию разработки вы вольны выбирать сами, я говорил о Скраме.

Fixed Price + Fixed Date + Fixed Scope
Почему же, совместимы :)
Agile — философия.

А методологию разработки вы вольны выбирать сами, я говорил о Скраме.

Я правильно понимаю, что вы предлагаете рассматривать SCRUM просто как набор практик в отрыве от ценностей и принципов того же Agile Manifesto?

Нет, не совсем так. Я предлагаю не рассматривать все ценности и принципы манифеста как обязательные в каждой методологии разработки Agile-типа, в том числе и в Скраме.

тогда работа работается на основе T&M по change request-ам

Очень любопытно, как у вас fixed price «лёгким движением руки» превращается в T&M :)

Кондовый fixed-price — это, как правило, постоянные перетягивания каната на тему «это Change Request или не Change Request» с кучей бюрократии вокруг отслеживания всех этих Change Request’ов и переутверждений бюджета. Что, как бы, не очень согласуется с принципом «embrace change» Agile-философии.

Очень любопытно, как у вас fixed price «лёгким движением руки» превращается в T&M :)
Не совсем так. Точнее — совсем не так! :) Fixed Price остается Fixed Price-ом. А всё что out of scope — или методом «замены на другое», или доп. T&M, вот абзац же:
В последствии допиливаются миноры и «хотелки», которые в процессе разработки складывались как feature requests вне scope-а fixed price контракта.
Если изменения таки нужны ПРЯМО СЕЙЧАС и критичны для клиента (изминилось видение или предпологаемая схема работы бизнеса, переигрались приоретиты фич и так далее) — тогда работа работается на основе T&M по change request-ам или выбрасываюся какое-то другие задачи из backlog-а чтобы впихнуть эти изменения.
Касательно:
Кондовый fixed-price — это, как правило, постоянные перетягивания каната на тему «это Change Request или не Change Request» с кучей бюрократии вокруг отслеживания всех этих Change Request’ов и переутверждений бюджета. Что, как бы, не очень согласуется с принципом «embrace change» Agile-философии.
Совершенно не обязательно это делать именно так. ;)
И не стоит путать Agile философию и Scrum методологию разработки, вы еще манифест поцитируйте как Божьи заповеди ;)
Команда, которая находится в «вечном шторминге» тоже не по-Agile-овски, но такие есть по разным причинам. Не надо доводить до Agile анархизма. Как и никто не запрещает использовать что-то другое или своё, если это полезно проекту/команде/клиенту/всем.

всё что out of scope — или методом «замены на другое», или доп. T&M

По моему опыту, такое работает, но далеко не со всеми клиентами. В частности, типовая особенность больших корпораций и гос. контор — их закупочные отделы в принципе не знают такой модели, как T&M. А, зачастую, и метод «замены на другое» требует изрядной бюрократии.

Совершенно не обязательно это делать именно так. ;)

Вы так говорите, как будто бы у менеджера проекта со стороны подрядчика всегда есть выбор (если не считать выбором отказ от проекта, но такие решения не на его уровне принимаются). Поверьте, когда выбор действительно есть, никто в здравом уме и трезвой памяти вообще не подпишется на fixed-all проект, максимум — на fixed price/variable scope. Но с определенными типами заказчиков проект можно получить только через публичный тендер, который в 99% случаев предполагает именно fixed-all модель.

Просто есть компании, которые за fixed-all проекты принципиально не берутся — например, на прошлой работе, еще до того, как продались GlobalLogic, на уровне высшего руководства было принято решение брать вообще только T&M проекты. И я своими глазами видел, как грустно и печально приходится менеджерам, пришедшим из таких компаний, когда они попадают на fixed-all проект.

И не стоит путать Agile философию и Scrum методологию разработки,

Я их не путаю. Если хотите, манифест — это «требования», а SCRUM — их «реализация».

С другой стороны, я же и не спорю с тем, что большинство практик из SCRUM будут прекрасно работать и в проекте с более plan-driven подходом. Большинство, но не все — как минимум, НЕ будут работать те практики, которые предполагают исключительно адаптивное планирование

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

По моему опыту, такое работает, но далеко не со всеми клиентами.

Полностью согласен.

Вы так говорите, как будто бы у менеджера проекта со стороны подрядчика всегда есть выбор

Он есть практически всегда, во всяком случае за шаг влево или вправо никого не расстреливают.

когда выбор действительно есть, никто в здравом уме и трезвой памяти вообще не подпишется на fixed-all проект

И тут согласен. Вопрос-то был не о том, на сколько такой бизнес выгоден, а о том, — совместимо-ли с Agile?

Если хотите, манифест — это «требования», а SCRUM — их «реализация».

Манифест — это описание Agile-философии (не требования), Scrum — методология разработки.

я же и не спорю с тем, что большинство практик из SCRUM будут прекрасно работать и в проекте с более plan-driven подходом.

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

Подобные темы на ДОУ уже поднимались.

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

Новые хотелки в процессе работы вытесняют запланированные ранее фичи. Клиента желательно уведомлять об отклонениях от запланированного еффорта, чтобы он понимал реальную картину и для него не было сюрпризов, когда бюджет будет выработан.

Работает только с адекватными клиентами.

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

Это называется fixed price / variable scope и, действительно, совместимо с Agile. В классическом fixed price никакого вытеснения фич, кроме как через формальную процедуру Change Management, быть не может, т.к. в контракте жестко прописан объем функционала.

Если строго придерживаться определений — Agile и Fixed-priсe конечно же не совместимы.. Это очевидно и не стоит упоминать.

Дмитрий, так не вопрос сделать вытеснение фич через Change Management process. Зная заранее, что это нужно будет делать оговариваем с заказчиком, если возможно, облегченный CM процесс и получаем на изменение скоупа дополнительные спринты, одновременно сдвигая сроки приемочного тестирования и прочих дат. И тут вопрос о трудоемкости этого процесса, а не принципиальной возможности. Если время выполнения пакета работ по CR-у больше чем срок согласования CR-а, то можно продолжать изменения скоупа до бесконечности. Получим аджайл и ... профит :)
На мой взгляд возможность совмещения зависит от заказчика.

Если сможете продать риски, то можно попытаться, но даже так это будет игра в рулетку с 4-мя пулями в барабане. Никогда не знаешь занесет ли Остапа или нет.

Подписаться на комментарии