Вы же сказали "либо у людей так или иначе будут ожидания касательно объёма+сроков и они будут расстраиваться" соответственно именно вы и не допускаете
Зачем?
Обычно это зависимости (другой команде нужно к какому-то сроку), новые требования законодательства или публичные обещания руководства. Бывает есть крупный заказчик, который не будет внедрять продукт, если там нет какой-то фичи и с ним договорились.
Да. Еще пробовали в конце спринта пытаться затолкать фичи со срезанием углов по качеству, но оказалось, что потом себе дороже. У нас баги в проде довольно дорого стоят и расмотрев на ретроспективе пришли к выводу что лучше бы фичу отложили но выпустили качественно
Наверняка есть такие люди, которые бесятся от любого несоответствия прикидки и реальности. Интересно, что вы даже не допускаете существования людей, которые относятся к прикидкам не так как вы.
Как это происходит у нас. Команда комитится на несколько фич в спринт. Может даже на ноль. Обычно это жесткие зависимости. Остальное время делают найс ту хев фичи. Они облегчают жизнь пользователям, но в принципе не срочные. Если за спринт сделаны не все найс ту хев фичи, то это ок.
После нескольких спринтов новичок понимает, что можно не успевать найстухев и все ок и не особо парится.
Ну бывают иногда гиперответственные которые парятся на любое несоответствие реальности картине мира.
Ну если менеджеры комитятся на все-все-все фичи то вам нужен не скрам. Тогда четкие спецификации и никаких изменений после комитмента. Иначе любой процесс будет приводить к срыву.
Планируются обязательные и найситухев фичи. Обязательные фичи стараемся сделать в спринт. Найстухев можно перенести дальше. Соответственно, так и планируем загрузку.
Про дедлайны я уже несколько раз привел ссылку здесь что нет скрамгайде теперь комитмента сделать все фичи а только форекаст.
Держать спринт закрытым - продуктовые горящие баги будут футболиться в бэклог (знаю примеры таких команд). Дать возможность докидывать срочные таски - получается хаос а не спринт.
В скрамгайде написано, что можно добавлять таски в спринт при условии, что они не ставят под угрозу цель спринта.
Возможно разные задачи. Есть фоновое думание, есть сфокусированное думание. Обычно задаи не требуют сфокусированного думания и только его в течении недели, нет? Либо это рождение каких-то артефактов типа дизайнов либо это исследования.
Исследования и дизайны вполне могут быть частью беклога.
Если "люди важнее процессов", могу ли я считинговать и запланировать на спринт очень маленькую задачу, которую точно сделаю за пару часов и при этом у меня не будет давления
Я не скрам мастер, но по гайду
Topic Two: What can be Done this Sprint?
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.
Соответстенно вы лично не можете, но у вас есть совещательный голос как разработчика.
One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint.
Если про вот это то я не вижу там наследования реализации соответственно такая же ситуация как и с нестатиками. ( Все равно что имплемент метода либо явно определяем какой интерфейс реализуем либо неявно, но нет такого что две реализации пришли из разных веток даймонда)
Почему не использовать Span вместо самодельного StringPart?
А как вы планируете спринты? Есть ли какое-то планирование поверх спринтов? Как отслеживаете зависимости?
Вы же сказали "либо у людей так или иначе будут ожидания касательно объёма+сроков и они будут расстраиваться" соответственно именно вы и не допускаете
Обычно это зависимости (другой команде нужно к какому-то сроку), новые требования законодательства или публичные обещания руководства. Бывает есть крупный заказчик, который не будет внедрять продукт, если там нет какой-то фичи и с ним договорились.
Да. Еще пробовали в конце спринта пытаться затолкать фичи со срезанием углов по качеству, но оказалось, что потом себе дороже. У нас баги в проде довольно дорого стоят и расмотрев на ретроспективе пришли к выводу что лучше бы фичу отложили но выпустили качественно
Наверняка есть такие люди, которые бесятся от любого несоответствия прикидки и реальности. Интересно, что вы даже не допускаете существования людей, которые относятся к прикидкам не так как вы.
Как это происходит у нас. Команда комитится на несколько фич в спринт. Может даже на ноль. Обычно это жесткие зависимости. Остальное время делают найс ту хев фичи. Они облегчают жизнь пользователям, но в принципе не срочные. Если за спринт сделаны не все найс ту хев фичи, то это ок.
После нескольких спринтов новичок понимает, что можно не успевать найстухев и все ок и не особо парится.
Ну бывают иногда гиперответственные которые парятся на любое несоответствие реальности картине мира.
Ну если менеджеры комитятся на все-все-все фичи то вам нужен не скрам. Тогда четкие спецификации и никаких изменений после комитмента. Иначе любой процесс будет приводить к срыву.
Планируются обязательные и найситухев фичи. Обязательные фичи стараемся сделать в спринт. Найстухев можно перенести дальше. Соответственно, так и планируем загрузку.
Про дедлайны я уже несколько раз привел ссылку здесь что нет скрамгайде теперь комитмента сделать все фичи а только форекаст.
https://www.scrum.org/resources/commitment-vs-forecast
В том что я наблюдаю, требования об других команд возникают в середине спринта но при этом обычно выполняются в следующем.
Бывают срочные баги, но очень редко срочные новые требования.
Возможно, вам подходит что-то типа канбана
Это модно, но только в Канбане )
Проблема была бы, если бы требования надо было сделать в этом же спринте. А так оно откладывается на следующий.
И вы останавливаетесь на несколько дней и думаете не производя при этом никаких артефактов?
Как так? Почему должны быть авралы, если команда сама определяет цель спринта и планирует, что будет поставлено?
В скрамгайде написано, что можно добавлять таски в спринт при условии, что они не ставят под угрозу цель спринта.
Возможно разные задачи. Есть фоновое думание, есть сфокусированное думание. Обычно задаи не требуют сфокусированного думания и только его в течении недели, нет?
Либо это рождение каких-то артефактов типа дизайнов либо это исследования.
Исследования и дизайны вполне могут быть частью беклога.
Я не скрам мастер, но по гайду
Topic Two: What can be Done this Sprint?
Through discussion with the Product Owner, the Developers select items from the Product Backlog to include in the current Sprint. The Scrum Team may refine these items during this process, which increases understanding and confidence.
Соответстенно вы лично не можете, но у вас есть совещательный голос как разработчика.
См также:
https://www.scrum.org/resources/commitment-vs-forecast
One of the most controversial updates to the 2011 Scrum Guide has been the removal of the term “commit” in favor of “forecast” in regards to the work selected for a Sprint.
А почему надо писать для новой экосистемы весь компилятор а не только бекэнд?
В каждой квартире поставить колонку с Алисой. За свои деньги. Отключать нельзя.
Если про вот это то я не вижу там наследования реализации соответственно такая же ситуация как и с нестатиками. ( Все равно что имплемент метода либо явно определяем какой интерфейс реализуем либо неявно, но нет такого что две реализации пришли из разных веток даймонда)
А как статики то наследуются?