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

80

Во многих книгах и статьях 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. ???
Андре Борхес
источник
31
Вы указываете 3 в разделе «Быть ​​готовым» предполагает, что отказ от использования Scrum изменил бы что-либо, если бы в течение месяца было готово только 80% функций. Это смешно.
Док Браун
7
@ Док, я не могу согласиться, что это смешно. Отказ от некоторых действий Scrum, таких как ретроспектива и демонстрационные встречи, может ускорить разработку. И в случае надежного контракта это может помочь в достижении конечной цели: предоставить фиксированное количество функций в конце срока.
Андре Борхес
26
@AndreBorges Ваше предложение отказаться от ретроспектив и демонстраций такое же, как и при снятии тормозов с автомобиля. Конечно, тормоза только замедляют вас. Но это то, что позволяет вам идти очень быстро.
Euphoric
13
та же проблема остается при любой системе - обратите внимание, что вы можете в значительной степени заменить scrum эквивалентным водопадом, и компания все равно обанкротится
jk.
6
Возможно, если бы эти менеджеры Scrum-Addicts уделяли больше внимания во время этих надоедливых «ретроспективных» встреч, у них была бы возможность нажать на тормоз на 1 или 2 неделе, вместо того, чтобы смотреть, как проект движется к утесу, и нажать педаль газа. ,
Дорус

Ответы:

134

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

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

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

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

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

Док Браун
источник
47
+1 за «Договор« все или ничего »- это не то, от чего выиграет ни поставщик программного обеспечения, ни покупатель» . Это ключевой момент в гибких контрактах.
guillaume31
5
И это, безусловно, тот случай, когда 80% не годятся для некоторых типов проектов (в конечном счете, возможно , хотя и маловероятно, что agile слишком ограничен, чтобы обеспечивать эти проекты). Так, например, бесполезно иметь 80% функций для вашего спутника, когда вы запускаете его, поэтому вы не возитесь с непредвиденными обстоятельствами в этих проектах. Если вы не сможете выполнить поставку, то миссия вашего клиента не будет выполнена (или задержана), вы ничего не можете сделать в контракте, чтобы это изменить.
Стив Джессоп
6
@SteveJessop: Я уверен, что даже когда вы создаете такую ​​сложную вещь, как программное обеспечение для спутника, существуют разные приоритеты для различных функций, и будет много функций, в которых область действия может варьироваться в определенной степени. Конечно, для такой ситуации крайний срок может быть установлен, потому что, если вы не запустите ракету в космос до декабря следующего года, у вас может не быть второго шанса.
Док Браун
6
Но для этого конкретного примера ... конечно, никто не отправил бы новые горизонты, если бы они не смогли закончить камеру hardwaredriver. Но даже для проектов такого масштаба я бы поспорил, что никто не собирается выходить в космос со всеми функциями, о которых они мечтали.
Zaibis
6
возможно, оплата за этап или функциональность также может быть вариантом.
Брэм
68

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

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

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

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

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

Euphoric
источник
9
@RubberDuck До сих пор не существует методологии управления программными проектами, которая позволяла бы определять функции заранее, устанавливать конечные сроки и не была ужасно дорогой. Сфера, время, деньги; Выбери два.
Эйфорическая
8
@RubberDuck: проект уже не гибкий, потому что требования изложены в камне. И оценка только три недели. В водопаде нет ничего волшебного, что делает его всегда поздним, просто он не может справиться со смутными требованиями и переменами. Да, я бы использовал «водопад» в этом случае, или, точнее, «давайте решать, что нужно сделать, и делать это».
RemcoGerlich
3
@RemcoGerlich по иронии судьбы, «давайте решим, что нужно сделать, и сделаем это» само по себе удивительно гибко :-)
gbjbaanb
2
@RemcoGerlich ах, я думаю, вы не поняли мою точку зрения: в этом agile на самом деле речь идет не о методах разработки, а о способности продолжать работу, используя любые средства, которые вам нравятся. Речь идет о прогрессе, а не о процедурах. (например, команда, которая только делает Scrum, не является гибкой, команда, которая только делает стиль водопада, но изменяет его в соответствии с обстоятельствами)
gbjbaanb
2
Я согласен с Доком Брауном здесь. Вы можете абсолютно иметь «ограничение по времени», не говоря точно, «для чего». Например, совершенно разумно сказать: «Наш крайний срок - <некоторая дата>. В этот день мы отправим то, что сделали». Объем того, что будет доставлено, не должен быть установлен в камне в тот момент, когда будет установлен крайний срок. Гибкая разработка - это все, что касается управления областью действия и информирования о прогрессе с шагом в определенное время, которые фактически являются собственными мини-сроками.
Эрик Кинг
15

Кто виноват?

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

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

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

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

Робби Ди
источник
12

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

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

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

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

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

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

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

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

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

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

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

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

  • Общая стоимость составляет максимум 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 был разработан на основе опыта многих неудачных ИТ-проектов. Это не может предотвратить неудачу и не может вылечить некомпетентность команд или руководства. Основная идея:

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

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

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

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

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

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

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

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

Томас Джанк
источник
1
Есть еще один аспект Scrum, который жизненно важен для понимания того, почему этот проект провалился: Scrum охватывает провал . Ожидается, что первая пара спринтов новой команды или проекта провалится. Благодаря тщательному процессу ретроспективы команда улучшит себя и в долгосрочной перспективе станет точной в своих оценках, но только до тех пор, пока они останутся той же командой, работающей над одним проектом. Когда любое из этих изменений изменится, вы должны снова ожидать некоторого сбоя, поскольку базовые переменные смещаются.
Cronax
9

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

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

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

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

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

Икер
источник
3
-1 Смысл гибкости в том, что многие риски просто невозможно предсказать. Например, они добавили 1-недельный буфер на случай, если что-то пойдет не так. Вы всегда можете утроить необходимое время, но тогда вы проиграете против конкуренции, которая этого не делает. Agile должен принять менталитет «Сделано, когда сделано». Что просто несовместимо с контрактами и сроками, как описано.
Эйфорическая
3
@ Эйфорично, я не могу полностью согласиться. Да, смысл Agile в том, что многие риски не могут быть предсказаны, и для этого и нужен буфер, я вам это предоставлю. Однако это не означает, что все риски непредсказуемы, а также не означает, что вы должны зайти в слепой проект, не учитывая риски, которые вы можете предсказать.
Икер
2
@Iker Одно не исключает другого, но смысл того, чтобы быть по-настоящему гибким в процессе разработки, заключается в том, что менталитет «Это сделано, когда это сделано» как для клиента, так и для команды. Конечно, всегда есть некоторые риски, которые вы можете предсказать, но вы никогда не сможете успешно предсказать все возможные риски и то, какое именно влияние они окажут на ваш прогресс. Если только вы не видите будущее каким-то образом. Вот почему Agile работа требует специального контракта, когда вы соглашаетесь, что «мы продолжим работать до тех пор, пока деньги не закончатся, или
какая-
хорошо, я проголосовал за немедленное отклонение вины как концепции. Я согласен, что вина - это непродуктивный компонент, который отвлекает от успеха. Давайте изменим вопрос. Может быть, мы могли бы сделать это "как мы могли бы справиться с этим"? "Как мы можем превратить это в успех для нас?" «Какие изменения с каждой стороны могли бы привести к положительному результату?» Я мог бы согласиться с изменением «вины» на «ответственный», но, поскольку каждый проект с поставщиком и заказчиком является взаимодействием команды, разве не так ли ответственна вся глобальная «команда»? тогда вопрос о том, кто виноват, становится риторическим.
Джошуа К
4

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

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

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

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

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

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

gbjbaanb
источник
6
«Игра готова к Рождеству» может стать постером для Scrum. Отправьте 80%, которые вы закончили, продайте остаток как DLC. Это не гипотетическая ситуация, обсуждаемая здесь, где крайний срок фиксировал время и объем, со 100% штрафом за частичную доставку.
MSalters
2
@MSalters вы полагаете, что игра работает вообще, что 80% могут не пропустить функции, которые могут быть добавлены позже, но нарушить функциональность или сбой ошибок. Это не обязательно должна быть игра, это может быть любое программное обеспечение, которое должно быть доставлено на определенный срок и неизменный срок (так как даже Apple не может отложить Рождество!)
gbjbaanb
6
Это основная предпосылка Scrum! Нарушенная функциональность не считается. Если вы пришли из Водопада, вы обнаружите, что Scrum отдает приоритет исправлению ошибок, а не добавлению новых функций. «80% выполнено» означает, что отсутствуют уровни, отсутствуют боссы и т. Д.
MSalters
1
@gbjbaanb По этим причинам, что-то может быть сделано на 99,9%, но все равно не работает, потому что происходит сбой сразу после запуска.
user253751
@immibis, но это правда. Такие вещи, как игры, не имеют тенденцию оставлять функции до конца, большинство частей игры должны быть реализованы для того, чтобы все работало - в то время как вы можете извлечь некоторые функции (и я знаю игры, которые сделали это), они не добавляют функции постепенно. Так что пропавший босс был бы сломанной игрой. Я выбрал игры только в качестве примера, поскольку они, как правило, (особенно до доставки в Интернет), являются примерами жестких сроков.
gbjbaanb
4

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

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

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

Резиновая утка
источник
3
Да, иногда клиент становится счастливее, если команда предоставляет хотя бы некоторые рабочие функции, но это не всегда так. Я говорю о случаях, когда (1) продукт бесполезен для конечных пользователей, если не реализовано 100% функций (например, требуется дорогостоящая сертификация, которую необходимо выполнять только после завершения всего) или (2) клиент это компания старой школы с подходом «все или ничего»: если продукт не готов на 100%, мы считаем его неудачным, нарушаем договор и увольняем всех ответственных.
Андре Борхес
2
Клиент всегда будет рад видеть прогресс в работе программного обеспечения. Дорогая сертификация может подождать, пока продукт не будет удовлетворен. Выпуск этого клиенту не означает, что они должны выпустить это общественности. В случае 2, на самом деле нет другого выбора, кроме как заставить ваших юристов / менеджеров по продажам писать лучшие контракты Честно говоря, ваши проблемы были бы такими же, если не хуже, с водопадом там.
RubberDuck
2
@AndreBorges Конечно, клиент будет счастлив увидеть 80% функций, чем 0% функций? По крайней мере, таким образом, клиент знает, что продукт в основном готов.
user253751
@immibis, если вы так говорите, это значит, что вы достаточно счастливы, чтобы избежать «особых» клиентов в вашей работе. Существуют огромные неуклюжие правительственные корпорации, которые применяют не столь разумные условия контракта, но если вы инвестируете все свои ресурсы в их задачу и добиваетесь успеха, они платят серьезные деньги, которые могут поднять вашу маленькую компанию до небес. Однако, если вы потерпите неудачу, вы можете найти себе новую работу. Это риск того, что некоторые люди готовы пойти на это.
Андре Борхес
2
Именно так! Из-за внутренней бюрократии и нехватки опытного управленческого персонала крупной компании иногда бывает проще считать неудачный крайний срок «неудачным экспериментом» и вообще отказаться от проекта, чем прилагать дополнительные усилия в попытке установить связь и пересмотреть сферу действия. Грустно, но факт :(
Андре Борхес
1

Во многих книгах и статьях 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 функций в зависимости от времени, возможностей и навыков, но может соответствовать.

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

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

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

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

candied_orange
источник
Я хотел бы просто предположить, что вы имели в виду спринт, а не отставание - я имел в виду именно то, что написал в вопросе: отставание в спринте
Андре Борхес
люди, занимающиеся творческой работой, такой как программирование, реагируют лучше всего, если им предоставляются три вещи: автономность, мастерство и цель - это может быть огромной темой для спекуляций само по себе, но факт заключается в том, что, к сожалению, большая часть программной работы становится менее креативной и более рутина (скучные задачи, фиксированные наборы технологий и наборы функций, строгие контракты). Следовательно, во многих случаях кнут и пряник работают просто отлично.
Андре Борхес
@AndreBorges Вы правы, я думал о продукте. Недавно я работал с инструментом, который называет спринт-бэклог спринтом, а продукт - бэклогом. Вы поймали меня на поражении, чтобы мой словарь не стал частным.
candied_orange
Программирование @AndreBorges никогда не будет начинкой конверта. Это проблема свечей. Причина в том, что любую повторяющуюся проблему можно решить с помощью того же кода, который решил первую проблему. Несмотря на это, менеджмент может прийти в менталитет, где они думают, что творчество - это проблема, которую нужно устранить. Я работал на и бежал из нескольких из этих магазинов. Они не держат хороших людей. Они не производят хорошего программного обеспечения. Разработчики - мастера. Попытка превратить их в работников сборочного конвейера только вредит вашему делу. Моя работа не в том, чтобы переворачивать яйца. Это гарантирует, что яйца перевернуты.
candied_orange
0

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

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

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

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

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

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

JeffO
источник
0

Цель

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

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

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

вопрос

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

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

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

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

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

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

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