Можно ли когда-либо заключить фиксированную сферу + фиксированный срок + контракт с фиксированной ценой для работы с «agile»?

32

Некоторые проекты, которые мы используем для внутреннего использования, - это Scrum, хотя они все еще «исправляют все» для клиента. Мы испытываем смешанный успех с нашей стороны (клиенту нравится видимость графика снижения производительности). Могут ли типы проектов, с которыми мы работаем, успешно выполняться с использованием гибких методов?

Крис Бакетт
источник
17
Можно ли заставить работать фиксированный объем + фиксированный срок + контракт с фиксированной ценой?
Carson63000
4
Разве это не способ перефразировать: «Быстро, хорошо или дешево. Выберите два»?
Матье М.
3
Разве не зафиксирован антоним agile?
Мэтт Эллен

Ответы:

10

Ну, я работал в основном в «гибких» средах (хотя мы не используем жаргон), и я делал вещи с фиксированной стоимостью. Как правило, это означает, что затраты плюс, так как ни одна компания не может позволить себе делать все бесплатно, а требования меняются и развиваются по мере того, как клиент более четко определяет, чего он хочет.

Первоначальные требования для части с фиксированными затратами должны выполняться гораздо более тщательно, чем в обычной итеративной среде, что делает процесс несколько менее итеративным. «Плюсная» часть контракта может быть более итеративной, если мы выполнили часть с фиксированными затратами более или менее удовлетворительно для клиента.

Роберт Харви
источник
71

Я хотел бы задать встречный вопрос:

Может фиксированный объем + фиксированный срок + фиксированный контракт цены когда - либо будет сделано для работы, период ?

Поговорка «хорошо / быстро / дешево - выбирай два» - не просто глупая инженерная шутка. Каждый руководитель проекта, достойный его внимания, знает о треугольнике управления проектами :

Треугольник управления проектами

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

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

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

  • Появятся непредвиденные расходы, что приведет к перерасходу бюджета. Срок подписки истек. Производитель прекратил свою поддержку для продукта, который вы используете, и вы должны найти новый. Почасовой подрядчик повысил свою ставку под угрозой отъезда. Вся ваша команда только что объявила забастовку, требуя повышения на 10% и дополнительной недели отпуска.

  • Графики скольжения. Возникают непредвиденные проблемы; тот компонент построения диаграмм, который вы использовали 5 лет подряд, не совместим с Windows 95, которую ваш клиент все еще использует. Непонятная ошибка в 64-битной Windows приводит к серьезным сбоям пользовательского интерфейса, и вы тратите почти неделю на ее обнаружение и разработку обходного пути (на самом деле это случилось со мной). Ваш старший разработчик попал под автобус, и вы должны нанять и обучить нового. Ваша предполагаемая дата доставки всегда неверна. Всегда.

    Смотрите закон Хофштадтера :

    Закон Хофштадтера: это всегда занимает больше времени, чем вы ожидаете, даже если вы принимаете во внимание закон Хофштадтера.

Гибкие методы - это все, что нужно для решения проблемы стоимости, графика и объема работ. В большинстве случаев речь идет именно о манипулировании областью действия, а иногда и расписанием , поэтому вы начинаете с туманных пользовательских историй и планируете пересмотры, а не полные версии. Различные методологии используют разную терминологию, но это все одна и та же основная предпосылка: частые выпуски и перебалансировка графика и объема с каждым выпуском.

Это не имеет смысла для проекта, который является (или претендует на то, чтобы) либо фиксированной областью действия, либо фиксированным графиком.

Если бы один атрибут проекта (стоимость / объем / график) был исправлен, я бы сказал, что он может не подходить для гибких методологий.

Если два атрибута проекта являются фиксированными, то ваш проект определенно не подходит для гибких методологий.

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

Если этот контракт все еще на столе, я призываю вас отказаться от него. И если вы уже приняли это, пусть Бог помилует вашу душу.

Aaronaught
источник
4
+1 для закона Хофштадтерса. Я собираюсь процитировать это на следующей сессии оценки.
Крис Бакетт
2
Обратите внимание, что если «исправлено» на самом деле не означает « исправлено» (как это подразумевается в комментарии к ответу Тодда), то это несколько меняет ландшафт, и успех проекта будет частично зависеть от того, как все согласятся с фактическим определением слова. «фиксированный» (или «должен» или «требуется», или что-то конкретное в контракте). Если область действия действительно «фиксирована, если у нас есть время» , то она начинает больше походить на гибкий проект. :)
Aaronaught
2
Я подозреваю, что именно так руководство работало с клиентом.
Крис Бакетт
3
Проекты с фиксированным графиком / масштабом / ценой могут работать (я их сделал), они просто требуют действительно твердых требований, действительно хорошей оценки, и, как вы говорите, эти вещи очень сложны в реальности. +1 за четкое объяснение того, как Agile в основном противоречит всему механизму с фиксированной ценой, хотя один из них - это (умные) компромиссы, а другой исключает возможность обменивать что-либо.
Джон Хопкинс
3
Только количество возражений по этому ответу показывает, сколько людей трудятся в беспорядке Agile + с фиксированной ценой.
носитель кольца
18

Я люблю эту цитату:

«Scrum отлично подходит как для переменной-области с фиксированной датой, так и для« фиксированной-области »(которая постоянно растет). Если вы работаете с фиксированной датой фиксированной даты, я рекомендую водопад или RUP, который купит вас через несколько месяцев, чтобы искать новую работу ». ~ Майкл Джеймс

Брюс
источник
6

Конечно, до тех пор, пока ваш качественный бар остается на удивительно низком уровне. Я верю в старый железный треугольник «время доставки / качество / цена», где вы можете выбрать два, но затем другой всплывает. Похоже, вы установили время и цену доставки (а также функции), поэтому единственное, что может дать, - это качество.

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

В противном случае я считаю, что фиксация фиксированного времени, набора функций и цены безрассудна и приведет к героическим усилиям, которые приведут к снижению качества и уменьшению объема поддерживаемого кода. Agile не волшебная волшебная пыль.

Тодд Уильямсон
источник
2
Это в значительной степени то, как мы справились с этим с нашим клиентом, - пусть сфера действия ускользнет и добавит его в следующей версии. Их основными мотиваторами являются срок и цена. Мы не хотим, чтобы качество снижалось - как отмечается в этом и других комментариях, мы полностью осознаем треугольник - у деловой стороны есть интересная работа, чтобы клиент тоже знал об этом.
Крис Бакетт
0

Фиксированная цена / фиксированный срок / фиксированная область действия могут быть сделаны как минимум настолько же быстрыми, насколько это может быть в водопаде.

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

В Agile вы можете выполнить спринт-ноль, чтобы сгенерировать отставание пользовательских историй и сделать некоторые оценки. Тогда согласитесь встретить истории ценности по фиксированной цене, к фиксированному сроку. Область действия определяется с точки зрения полезных историй, которые вы намереваетесь выполнить, и никаких обещаний относительно пользовательских историй не дается.

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

Эрик Уилсон
источник
Старый, но ... в Agile это можно сделать бесконечно лучше, чем в Waterfall, и шансы не изменятся. Ноль всегда будет нулем. Если одна задача в одной истории встречается с одним событием, которое меняет стоимость или усилие, вы потерпели неудачу.
EKW
0

Я согласен с Брюсом в определенной степени. Хотя я не слишком знаком с водопадом или RUP, и поэтому не могу комментировать это.

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

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

Мне нравится идея непрерывного планирования, так как разработчики слишком часто говорят владельцу продукта уходить, когда они работают над историями в середине спринта. Это прекрасно, если ваша команда работает над историями, которые все еще актуальны, а владелец вашего продукта - просто неприятность. Но в некоторых случаях истории становятся излишними во время спринта, и владельцу продукта необходимо это определить, а команде - переориентироваться на изменившиеся цели / истории - не в этом ли гибкость?

Danette
источник
2
если вы занимаетесь постоянным планированием, то Scrum действительно не для вас. Канбан может быть более подходящим, чтобы попробовать. Но то, что вы говорите о Agile, - это то, о чем вы говорите.
gbjbaanb