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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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