Работа с неудачными спринтами и сроками

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

Это выглядит великолепно с точки зрения разработчика, однако, допустим, у нас есть компания-разработчик программного обеспечения " Scrum-Addicts LLC ", разрабатывающая что-то для серьезных клиентов (" Money-Bags Corporation "):

1. Менеджеры Scrum-Addicts предлагают создать программное обеспечение для Money-Bags
2. Они согласовывают список функций, а Money-Bags просит указать дату доставки.
3. Менеджеры Scrum-Addicts консультируются со своей командой Scrum, и команда говорит, что для выполнения всех функций потребуется 3 недельных спринта
4. Менеджер Scrum-Addicts добавляет 1 неделю, чтобы быть в безопасности, обещает отправить программное обеспечение через 1 месяц и подписывает контракт с Money-Bags
5. После 4 спринтов (срок поставки) команда Scrum может предоставить только 80% функций (из-за неопытности в новой системе, необходимости исправления критических ошибок в предыдущих функциях в производственной среде и т. Д.)
6. Как предполагает Scrum, на данный момент продукт потенциально может быть отправлен, но Money-Bags требуется 100% функций, как указано в контракте. Поэтому они нарушают договор и ничего не платят.
7. Scrum-Addicts находится на грани банкротства, потому что они не получили денег от Money-Bags, а инвесторы были разочарованы результатами и не хотят больше помогать компании.

Очевидно, что ни одна софтверная компания не хочет быть в шкуре Scrum-Addicts. Что я не понимаю в Agile и Scrum, так это то, как они предлагают командам решать вопросы планирования и сроков, чтобы избежать ситуации, описанной выше. Итак, подведу итог, у меня есть 2 вопроса:

Кто виноват?

1. Менеджеры, потому что это их работа, чтобы сделать правильное планирование
2. Команда, потому что они сделали больше, чем могли
3. Кто-то еще

Что нужно сделать?

1. Менеджеры должны сдвинуть крайний срок в 2 раза (или в 3 раза) позже, чем исходная оценка команды.
2. Следует побуждать членов команды выполнять всю работу, которую они выполняли, несмотря ни на что (назначая штрафы за неудачные спринты).
3. Команда должна отказаться от Scrum, потому что это не соответствует политике крайнего срока компании
4. Мы все должны отказаться от разработки программного обеспечения и присоединиться к монастырю
5. ???

Я вижу несколько фундаментальных проблем управления в вашем примере:

• если менеджер Scrum-Addicts подписывает контракт с "жестким сроком", но добавляет запас прочности в 33% в ситуации, когда "задействована новая система", это довольно безрассудно.

• доступность предоставления как минимум x% функций через один месяц могла бы использоваться для согласования контракта, когда клиенты платят деньги хотя бы частично, когда он получает только 80% функций в установленный срок. Договор «все или ничего» - это то, от чего не выиграет ни поставщик программного обеспечения, ни покупатель - это означает не только 0 денег для поставщика, но и 0 функций для клиента. А методология разработки «все или ничего», такая как «Водопад», позволит вам писать такие контракты, а гибкий подход открывает дополнительные возможности.

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

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

Одно из утверждений « Манифеста гибкой разработки программного обеспечения »:

Сотрудничество с клиентом в рамках переговоров по контракту

Тот факт, что Scrum-Addicts LLC договорились о заключении договора, а не о сотрудничестве с клиентом, заставляет меня усомниться в их гибкости.

Ясно одно: ловкость должна приниматься КАЖДЫМ. Ловкость не только для разработчиков. Менеджеры и клиенты также должны принять ценности Agile Manifesto. Если клиенты не принимают гибкость и все еще требуют жестких контрактов и минимального сотрудничества, то либо не используйте гибкость, либо найдите лучших клиентов.

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

Кто виноват?

Менеджеры, юридический отдел, бухгалтеры - выбирайте сами ...

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

Клиенты хотят иметь свой пирог и есть его - они с радостью принимают водопад, мини-водопад, ловкий, ла-ла-ланд, если они получают продукт X за $ Y к дате Z.

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

ИТ-проекты имеют дело с неизвестными ; некоторые из этих неизвестных даже неизвестны . Что это обозначает?

Возьмите, например, игрушечный мост для вашей модели железной дороги. Есть все известные вам параметры:

• Вы знаете, насколько велика долина

• Вы знаете материал гор, их высоту, устойчивость и т. Д.

• Вы знаете, сколько материала вам нужно

• Вы знаете из более ранних «проектов», сколько времени у вас ушло на создание подобных вещей

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

Сделайте пример еще дальше:

• Скажем, вы не строите мост для своей собственной модели железной дороги, вместо этого вы строите его для совершенно незнакомого человека: ваша задача - построить железнодорожный мост между двумя горами

• Скажем, у вас нет информации о модели ландшафта

• Информация о ландшафте состоит из двух гор, которые кажутся не слишком большими

• Последовательность горы между камнем и желе

• Общая стоимость составляет максимум 10 $

• На рабочем месте совершенно темно и нет шансов на свет: у вас есть только коробка из 8 спичек

• Срок исполнения 3 часа

Это было бы аналогией с ИТ-проектом. У вас есть опыт строительства мостов, и по известной местности легко ходить. Что делает это трудным, так это тьма . Есть много вещей, которые вы вряд ли можете предсказать: размеры гор известны только после того, как вы проведете некоторое время в темноте. Такова последовательность гор. Исходя из этого, вы можете оценить, сколько времени это займет у вас и сколько это будет стоить. Здесь неизвестными являются вещи, которые вы не знаете в начале проекта, такие как конкретная местность и т. Д. Но есть вещи, которые вы не можете предвидеть, даже с самым большим опытом и самыми консервативными оценками. Эти вещи - неизвестные неизвестные, которые несут в себе немного хаоса.

Каждая ИТ-компания должна знать это. Им приходится иметь дело с проектным риском.

1) Есть несколько способов минимизировать (финансовый) риск: сделка может включать в себя то, что клиент платит за каждый рабочий прирост. Таким образом, после получения приращения 1 необходимо оплатить частичную ставку. Пока Scrum-Addicts LLC поставляет, существует минимальный финансовый риск. Чем более детализированы цели спринта , тем ниже общий риск каждого спринта. Это означает, что если корпорация Money-Bags получила 80% контракта, они должны как минимум заплатить 80% стоимости контракта. Если они отказались платить после неудачного спринта, риск не так высок, как отказ платить 100%.

2) Scrum-Addicts LLC имеет проблемы со своими разработчиками

Менеджеры Scrum-Addicts консультируются со своей командой Scrum, и команда говорит, что для выполнения всех функций потребуется 3 недельных спринта. Менеджер Scrum-Addicts добавляет 1 неделю, чтобы быть в безопасности, обещает отправить программное обеспечение через 1 месяц и подписывает контракт с мешками денег

Это говорит о том, что а) разработчики не разбираются в схватках или б) они неправильно разбираются в схватках. Чем дольше команды работают со скрамом, тем лучше их оценки. Если команды делают оценки, а менеджер добавляет «буфер» как «безопасность», менеджер, кажется, знает лучше, чем команда, что является плохим признаком . Если у вас есть опытная команда, вам не нужен «менеджерский буфер», команда включила его в оценку. Идея в том, что чем больше спринтов работало вместе, тем больше команда знает свои сильные и слабые стороны и имеет некоторые метрики для реалистичных оценок. Конечно, есть, как уже упоминалось, неизвестные неизвестныекоторые, как правило, затрудняют оценку; или хотя бы неточным. Но в конечном итоге оценки должны становиться все лучше и лучше.

Кто виноват?

1) Управление

Как сказано выше: в управлении рисками явно наблюдается сбой. Если компания находится на грани банкротства, компания этого заслуживает. Если вы работаете в такой компании: уходите!

2) Команда

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

Что нужно сделать?

Сейчас: возьмите денежные мешки в суд

На будущее: не заключать такие контракты

Скрам не виноват в провале управления. Scrum был разработан на основе опыта многих неудачных ИТ-проектов. Это не может предотвратить неудачу и не может вылечить некомпетентность команд или руководства. Основная идея:

• структурировать способы общения (кто с кем разговаривает, когда о чем)

• поощрять неудачу отчетности разработчика рано

• разделять задачи на задачи и подзадачи

• структурировать время и возможности (кто работает, когда над чем)

• распределить задачи по временным интервалам

• сделать непредсказуемое немного более предсказуемым (планирование покера)

или в целом: минимизировать риск.

Скрам - это инструмент, как молоток. Является ли это хорошим инструментом, зависит от ваших знаний, как его использовать. Но иногда отвертка подходит лучше. Тебе решать.

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

Лучший способ посмотреть на это: «Что вызвало задержку?». Был ли это недостаток опыта в технологии? Критические ошибки, которые не были обнаружены при тестировании / QA? Отсутствие тестирования / QA? Слишком оптимистично оценивать? Не принимая во внимание не очень оптимистичные оценки команды? Кто-нибудь попал под автобус? Какой бы ни была причина, следующий вопрос - «Как мы можем быть уверены, что это больше не повторится?». В некоторых (надеюсь, редких) случаях ответом может быть «избавиться от таких-то», но если вы начнете с «Мне нужно наказать того, кто несет ответственность», вы вряд ли увидите большинство случаев. где это не правильное решение.

В рамках проекта вы уже утонули. Срок пришел и ушел, вы предупредили клиента, как только стало очевидно, что он собирается проскочить (потому что вы это сделали, верно? Если нет, это часть проблемы), и теперь это нужно обрабатывать, как бы оно ни было прописано. в договоре (это на самом деле прописано в договоре, верно?). Вообще говоря, это должно включать переговоры с клиентом о том, как вы собираетесь доставить недостающее. Многим людям нравится думать о контракте как о чем-то, что нельзя изменить, но сталкивается либо с: а) отказом от контракта и отсутствием того, что вы купили, б) предъявлением иска компании за нарушение контракта и потерей большого количества денег в суде, и в) переговоры о том, как получить свой продукт с наименьшим количеством возможных проблем, большинство компаний выбирают в.

Заглядывая вперед, прежде чем указывать цену / крайний срок для клиента, вы должны проанализировать риски, связанные с проскальзыванием крайнего срока или перерасходом средств (каковы возможные причины такой вещи? Какие причины вы можете как-то смягчить, а какие - нет, и просто планировать), и использовать эту информацию, чтобы помочь решить, что вы собираетесь обещать. Если это тот случай, когда он составляет 100% или ничего, вы, очевидно, будете указывать более высокие цены и более длительные сроки, потому что риск выше.

Вы заметите, что я не говорил об Agile во всем этом ответе. Это потому, что (я собираюсь на секунду забыть об участии клиента в Scrum, хотя это очень и очень важно), на данный момент это не имеет большого значения. Вы столкнетесь с этой проблемой в Agile, Waterfall или любом другом процессе разработки, который вы используете. Да, Agile должен помочь вам лучше управлять рисками, позволяя увидеть, действительно ли они стали актуальными проблемами ранее, и вовлечь клиента в сам процесс, чтобы он всегда был в курсе, но это не панацея.

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

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

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

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

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

Скрам - это система, которая постоянно развивается, постоянно что-то определяя и совершенствуя. Это просто не подходит для такого развития. Другие могут управлять этим типом и при этом придерживаться концепции итеративной разработки, Kanban - один такой, Crystal - другой. Но важно понять, что если вы неукоснительно следите за Скрамом, вы не будете проворны. Любая настоящая Agile-система должна быть способна трансформироваться, чтобы справиться с этими конкретными проблемами, поэтому она называлась в первую очередь гибкой, она касается выполнения того, что необходимо сделать, и если фиксированный срок является частью этого, то вам следует учитывать это в своей работе.

Парадигма развития не совпадает с парадигмой контракта. В идеале способ написания контрактов изменился бы, но на самом деле это вряд ли произойдет. Однако, даже если бы вы отказались от схватки, у вас все равно были бы сюрпризы и пропущенные сроки (только вы, вероятно, были бы намного позже, потому что вы сделали весь этот дизайн заранее, и все было неправильно !!).

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

Хорошо ли, что вы не смогли выполнить все, что обещали, в тот день, когда обещали? Нет, но ваш клиент будет намного счастливее, если вы сможете доставить что-то, что работает вовремя, а потом доставить остальное быстро, чем, если вы просто опаздываете и у вас ничего нет.

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

То, как вы «наказываете» такое поведение, ограничивает объем работы, которую те, кто не закончил, могут выполнить в следующем спринте. Шансы поработать над классными вещами исчезают. Награда за хорошую работу - больше работы.

Это выглядит великолепно с точки зрения разработчика, однако, допустим, у нас есть компания-разработчик программного обеспечения "Scrum-Addicts LLC", разрабатывающая что-то для серьезных клиентов ("Money-Bags Corporation"):

Менеджеры Scrum-Addicts предлагают создать программное обеспечение для Money-Bags. Они согласовывают список функций, и Money-Bags просит предоставить дату отгрузки. Менеджеры Scrum-Addicts консультируются со своей командой Scrum, и команда говорит, что это займет 3 недели. -длинные спринты для выполнения всех функций Менеджер Scrum-Addicts добавляет 1 неделю для обеспечения безопасности, обещает отправить программное обеспечение в течение 1 месяца и подписывает контракт с Money-Bags После 4 спринтов (крайний срок доставки) команда Scrum может предоставить только 80% функций (из-за неопытности с новой системой, необходимости исправления критических ошибок в предыдущих функциях в производственной среде и т. д.). Как предполагает Scrum, на данный момент продукт потенциально может быть отправлен, но Money-Bags требуется 100% функций, как указано в договоре. Поэтому они нарушают договор и ничего не платят.

Scrum-Addicts находится на грани банкротства, потому что они не получили денег от Money-Bags, а инвесторы были разочарованы результатами и не хотят больше помогать компании.

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

Очевидно, что ни одна софтверная компания не хочет быть в шкуре Scrum-Addicts. Что я не понимаю в Agile и Scrum, так это то, как они предлагают командам решать вопросы планирования и сроков, чтобы избежать ситуации, описанной выше.

Подумайте, ПОЧЕМУ МБ хочет забрать свой мяч и пойти домой. МБ не требовал, чтобы работа была сделана в течение месяца с самого начала. SA обещал 100% критических функций в течение одного месяца и не поставил. SA устанавливает срок не МБ. SA даже произвольно добавил неделю к крайнему сроку. Так почему же это срок?

Иногда, конкурируя за работу, компании-разработчики программного обеспечения поддаются искушению выпендриться и пообещать луну. Профессионалы тщательно устанавливают, нужна ли вообще луна. Что является наиболее важной потребностью в MoneyBags? 100% функций или функционирующий продукт через месяц? Они даже знают, что действительно важно? Есть ли какое-то предстоящее событие, устанавливающее жесткие сроки?

Если бы я был Scrum-наркоманами, ведущими переговоры по этому контракту, я бы хотел узнать намного больше о потребностях бизнеса Money-Bags и структурировать контракт так, чтобы предоставить столько гибкости, с которой Money-Bags комфортно себя чувствует. Я бы научил их, как работает гибкий процесс, чтобы они знали, чего ожидать от нас.

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

Итак, подведу итог, у меня есть 2 вопроса:

Кто виноват? Менеджеры, потому что их работа заключается в правильном планировании
команды, потому что они взяли на себя обязательство выполнять больше работы, чем могли.
Кто-то другой

Любой мог остановить эту пародию до того, как у нас будет месяц.

Я мог бы даже обвинить Money-Bags Corp в том, что он нанял команду, которая, очевидно, обманным путем представляла процесс водопада быстрым. Сам контракт дает понять, что это не проворно. Планирование сделать за месяц не делает его гибким.

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

Что нужно сделать?

Как насчет гибкой? Доставить что-нибудь каждый спринт? Получить отзыв до истечения срока? Недельные спринты? Как насчет пересмотра драконовского контракта в тот самый момент, когда вы подозреваете, что крайний срок находится в опасности, а не в сокрытии и молитве? По крайней мере, вы можете перестать тратить время на обреченный проект и найти более разумного клиента.

Менеджеры должны сдвинуть крайний срок в 2 раза (или в 3 раза) позже, чем исходная оценка команды.

Множители сроков примерно так же полезны, как и установка часов на 15 минут раньше, поэтому вы никогда не опоздаете. Вы можете обмануть себя так долго, прежде чем поймете, что вы делаете.

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

Следует побуждать членов команды выполнять всю работу, которую они выполняли, несмотря ни на что (назначая штрафы за неудачные спринты).

Члены команды должны быть поощрены. Не удалось, совершено или иным образом. Вместо того чтобы строить какие-либо искусственные последствия, такие как наказания или даже бонусы (кнут и пряник), исследования показали, что люди, занимающиеся творческой работой, такой как программирование, лучше всего реагируют, если им предоставляются три вещи: Автономия, Мастерство и Цель.

Даниэль Пинк говорит об этом TED . Речь идет о не гибкой мотивации, но я легко увидел, как сопоставить эти точки с гибкой:

Автономия - я хочу руководить собственной жизнью - позвольте мне выбрать работу из отставания.
Мастерство - я хочу стать лучше в чем-то важном - Отзывы клиентов.
Цель - я хочу быть частью чего-то большего, чем я - Совместная команда.

Команда должна отказаться от Скрама, потому что это не соответствует политике крайнего срока компании. Скрам может уложиться в срок более точно, чем водопад. Учитывая крайний срок схватки можно встретить его. Он может соответствовать только 1 из 47 функций в зависимости от времени, возможностей и навыков, но может соответствовать.

Гибкий проект может быть разработан настолько экстремально, что каждый вечер, когда команда возвращается домой, она готова к отправке. Это кажется глупым, если вы не думаете о доставке, как о том, что клиент просит проверить и предоставить обратную связь. Чем раньше это произойдет, тем раньше вы сможете внести коррективы. Это поражает все возможные сроки. Просто не каждая функция. Но это направляет вас к функциям, которые имеют значение.

Мы все должны отказаться от разработки программного обеспечения и присоединиться к монастырю

Точно так же, как если бы меня заперли в комнате подальше от реальной жизни, это заставило бы меня писать МЕНЬШИЙ код.

Я отредактировал этот ответ до размера. Если вам интересно читать историю редактирования.

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

Вы не можете указать дату доставки слишком далеко в будущем. Вы даете оценку.

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

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

Кто знает, на некоторых проектах вы можете отправить раньше.

Вы не можете быть проворным, если клиент не хочет.

Цель

Я считаю, что следующие две «метрики» должны быть основой для любого делового решения:

• выгодна ли работа (для клиента)
• мы работаем максимально эффективно

Это довольно универсально. Конечно, все усложняется очень быстро, например, прибыльная работа связана с тем, что продукт делает правильные вещи, пользователь может использовать продукт, продукт продается правильно и т. Д. - для многих из этих " Scrum-наркоманов" ООО "не несет ответственности.

вопрос

Контракт не ориентирован на цели, изложенные выше. Есть пункт «все или ничего» - сделай все, и тебе заплатят, или ничего не сделай и не заплати. Однако это не имеет прямого отношения к создаваемой ценности. Другой недостаток, который следует: теперь нам нужно потратить время и деньги, чтобы убедиться, что контракт соблюдается. С какой стати мы хотим потратить эти деньги? Как помогает убедиться, что контракт выполнен, когда требования за это время изменились, и мы обнаружили, что заказанное программное обеспечение не создает никакой ценности? Там просто больше денег идет на ветер! Теперь, конечно, есть причина для такого поведения:

• В культурном плане мы привыкли покупать такие вещи. Мы ожидаем покупки программного обеспечения так же, как и для автомобиля: выберите конфигурацию, получите цену и срок, и очень расстроитесь, если эти два не будут выполнены.
• мы хотим переложить риск и ответственность
• мы хотим стабильности, это помогает планировать и заставляет нас чувствовать себя лучше (а также нашего клиента, что является важным аспектом!)

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

Вот как это должно работать

• иметь контракт на услуги и работу, а не на продукт
  • должно быть прекращено в относительно короткие сроки
• работать в тесном сотрудничестве, чтобы обеспечить оптимальную эффективность
• привлекать все необходимые стороны, как от « Scrum-Addits LLC », так и от « Money-Bags Corporation » - «единый контакт», туннелирующий всю информацию, не будет работать здесь

ну я в основном только что сказал "быть проворным". Теперь вот почему:

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