Со стороны Владельца продукта, радеющего за свой продукт, профит в том, что у него есть возможность грамотно расставлять приоритеты Историй под ожидания и желания end-user'ов, условий рынка, каких-то шагов конкурентов под каждый спринт, а не сидеть на жопе и ждать, когда проект, который пилиться 9 месяцев по ТЗ появится наконец-таки на свет, но, например, уже никому не нужный, потому что многие условия/требования изменились и проект в том виде, как он проектировался изначально уже на рынке ничего не стоит.
На полгода-год планов никаких быть не может, разве что крупными мазками могут быть обозначены хотелки. Единственная более-менее осязаемая часть беклога — нарезанные User story на пару-тройку спринтов. Всё это выливается из-за одного из пунктов Agile манифеста: готовность к изменениям важнее следования первоначальному плану.
В том числе сам подход о найме команд в идеале должен строиться иначе. Стейкхолдер платит не за проект в целом, а платит команде её стоимость в спринт. Тут же и раскрывается смысл итераций — инкремент продукта, который по завершению спринта и релиза в продакшн повысит прибыль, например. И по факту, стейкхолдеры в праве в любой момент прекратить финансирование команды.
При «Водопаде», если на середине разработки стейкхолдеры прекратят финансирование, то у них на руках остаётся не работающее нечто и бесполезное ТЗ, которое даже не привносит понимания: зря или нет они потратили кучу денег на разработку. При скраме же у них есть продукт с конкретным набором фич, который уже давно работает или не работает (как одна из причин, почему они прекратили инвестирование). Они так же могут банально прекратить инвестирование, если посчитают, что стоимость спринта, например, не соизмерима с инкрементом продукта.
Было и наоборот, когда фича, запланированная на неделю, пилилась за полдня…
Если вы завершаете спринт быстрее и у вас остаётся адекватное количество времени до демо, то вы вполне можете смело подойти в Владельцу продукта и взять из беклога ещё одну-другую User Story на текущий спринт. Это проще, конечно, если беклог «начёсан» на пару спринтов вперёд.
Выбор продукта, с которым необходимо интегрироваться для решения конкретной User story, лежит на плечах команды. Соответственно, если аналогов продукту нет, которые более адекватны и с временем ответа, и стабильностью работы, то есть пара выходов, но все они сводятся к совету gandjustas.
Во-первых на планировании спринта (а лучше на груминге, задолго до планирования) рассказать Владельцу продукта, что у такой-то User story есть внешняя зависимость (аналогов которой нет, поэтому приходится нам с ней работать), которая может подпортить итог спринта. Он в свою очередь может изменит приоритет, может ему это будет ОК.
Во-вторых всё в ваших руках, и если вы закоммитились на какую-то User Story, то должны стараться сделать всё, чтобы не облажаться командой на демо: это может и чаще долбить суппорт «внешней зависимости» (всей командой по 100500 раз на день, чтобы чаще отвечали), быть может предложить им помощь, если они не способны решать проблемы быстро (в ваших же интересах, чтобы они шевелились быстрее, так как в первую очередь вы потеряете деньги от их неторопливости), возможно реализвовать самим то, что предлагает другая контора.
Это, конечно, рассуждения о сферическом коне, ибо по описанию не совсем понятен масштаб бедствия.
User Story не совсем о требованиях, а скорее о проблемах пользователей.
Story Points не имеют ничего общего с приотретизацией, потому как приоритезирует Product Owner, а Story Points — удел команды. Помимо всего прочего Story Points не стоит приравнивать к человеко-часам.
Scrum — о командной ответственности, так что задачи на Sprint Planning берёт на себя команда, а не отдельные личности.
У Скрам-мастера нет блин никакого права вето в принципе.
Много воды в лекции и неточностей в деталях, которые превратят скрам в организации в скрамнецо.
А тут как быть? По идее мина должна находится в зелёном секторе, но внезапно игра прекратилась, когда выбрал поле обведённое кругом. При этом неясно откуда у двойки справа внизу появится вторая мина рядом.
Можно первые несколько секунд при появлении сообщения показывать кнопку подтверждения операции неактивной, или просто сделать настраиваемый параметр, дабы не трепать себе нервы на локальной машине.
На полгода-год планов никаких быть не может, разве что крупными мазками могут быть обозначены хотелки. Единственная более-менее осязаемая часть беклога — нарезанные User story на пару-тройку спринтов. Всё это выливается из-за одного из пунктов Agile манифеста: готовность к изменениям важнее следования первоначальному плану.
В том числе сам подход о найме команд в идеале должен строиться иначе. Стейкхолдер платит не за проект в целом, а платит команде её стоимость в спринт. Тут же и раскрывается смысл итераций — инкремент продукта, который по завершению спринта и релиза в продакшн повысит прибыль, например. И по факту, стейкхолдеры в праве в любой момент прекратить финансирование команды.
При «Водопаде», если на середине разработки стейкхолдеры прекратят финансирование, то у них на руках остаётся не работающее нечто и бесполезное ТЗ, которое даже не привносит понимания: зря или нет они потратили кучу денег на разработку. При скраме же у них есть продукт с конкретным набором фич, который уже давно работает или не работает (как одна из причин, почему они прекратили инвестирование). Они так же могут банально прекратить инвестирование, если посчитают, что стоимость спринта, например, не соизмерима с инкрементом продукта.
Если вы завершаете спринт быстрее и у вас остаётся адекватное количество времени до демо, то вы вполне можете смело подойти в Владельцу продукта и взять из беклога ещё одну-другую User Story на текущий спринт. Это проще, конечно, если беклог «начёсан» на пару спринтов вперёд.
Во-первых на планировании спринта (а лучше на груминге, задолго до планирования) рассказать Владельцу продукта, что у такой-то User story есть внешняя зависимость (аналогов которой нет, поэтому приходится нам с ней работать), которая может подпортить итог спринта. Он в свою очередь может изменит приоритет, может ему это будет ОК.
Во-вторых всё в ваших руках, и если вы закоммитились на какую-то User Story, то должны стараться сделать всё, чтобы не облажаться командой на демо: это может и чаще долбить суппорт «внешней зависимости» (всей командой по 100500 раз на день, чтобы чаще отвечали), быть может предложить им помощь, если они не способны решать проблемы быстро (в ваших же интересах, чтобы они шевелились быстрее, так как в первую очередь вы потеряете деньги от их неторопливости), возможно реализвовать самим то, что предлагает другая контора.
Это, конечно, рассуждения о сферическом коне, ибо по описанию не совсем понятен масштаб бедствия.
Story Points не имеют ничего общего с приотретизацией, потому как приоритезирует Product Owner, а Story Points — удел команды. Помимо всего прочего Story Points не стоит приравнивать к человеко-часам.
Scrum — о командной ответственности, так что задачи на Sprint Planning берёт на себя команда, а не отдельные личности.
У Скрам-мастера нет блин никакого права вето в принципе.
Много воды в лекции и неточностей в деталях, которые превратят скрам в организации в скрамнецо.