Как обрабатывать «внешние» зависимости в Scrum?

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

Вы знаете, что это произойдет «скоро».

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

Если первое, как вы справляетесь с «незаработанными» историческими очками, потерянными из-за зависимости? частичный кредит (eek!) или взять его на подбородок.

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

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

Вы должны сообщить клиенту, что эта зависимость существует и что вам придется ждать, пока API (или что-то еще) не станет доступным, прежде чем вы сможете запланировать работу.

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

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

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

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

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

Звучит грубо, но я хочу донести свою мысль.

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

• Все внешние API, необходимые для истории, должны быть доставлены и протестированы.

Если вам нужен этот API, чтобы повысить ценность вашего продукта, логично сделать это, подождать, пока у нас не появится этот API, чтобы начать нашу работу. В то же время мы можем сделать другие США, которые повышают ценность продукта, мне действительно не нравятся эти США с имитационными реализациями и тому подобным, если для потребителя нет реальной ценности, то нет США, их трата времени и ресурсов. ,

Если вы ждете чего-то, чего вы еще не знаете, вы не можете планировать это, даже если вы на 100% уверены, что оно будет доставлено завтра. Почему? Потому что, если вы этого не знаете, вы даже не сможете оценить его сложность, а если вы не сможете оценить его, вы не сможете спланировать его.

Если вы заранее определили некоторый «интерфейс» / «контракт», которому должна следовать внешняя компания, вы можете спланировать это и создать сервисный макет на вашей стороне. Ваша разработка будет использовать поддельный сервис, поэтому они не будут зависеть от внешней доставки. Тем не менее, разработка с использованием макета должна быть спланирована для спринта, где будет оказана реальная услуга, поскольку функция, разработанная и протестированная в отношении макета, еще не завершена - она ​​должна быть протестирована с реальным сервисом, который будет считаться завершенным в конце спринта.

Связь и соглашения

Две системы объединяются программистами, а не самой методологией. Если компания решила интегрировать внешнюю систему, будет заключен договор между (как минимум) двумя организациями. Контракт должен обеспечить интеграцию . Следовательно, если соглашение между компаниями не требует технического сотрудничества между обоими департаментами, проблема заключается не в методологии разработки. Проблема в методологии бизнеса (в основном контракт) .

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

Как менеджер проекта может управлять зависимостью от внешней команды?

/pm/1400/how-can-a-project-manager-manage-a-dependency-on-an-external-team

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