Ну если менеджеры комитятся на все-все-все фичи то вам нужен не скрам. Тогда четкие спецификации и никаких изменений после комитмента. Иначе любой процесс будет приводить к срыву.
Планируются обязательные и найситухев фичи. Обязательные фичи стараемся сделать в спринт. Найстухев можно перенести дальше. Соответственно, так и планируем загрузку.
Про дедлайны я уже несколько раз привел ссылку здесь что нет скрамгайде теперь комитмента сделать все фичи а только форекаст.
Держать спринт закрытым - продуктовые горящие баги будут футболиться в бэклог (знаю примеры таких команд). Дать возможность докидывать срочные таски - получается хаос а не спринт.
В скрамгайде написано, что можно добавлять таски в спринт при условии, что они не ставят под угрозу цель спринта.
Возможно разные задачи. Есть фоновое думание, есть сфокусированное думание. Обычно задаи не требуют сфокусированного думания и только его в течении недели, нет? Либо это рождение каких-то артефактов типа дизайнов либо это исследования.
Исследования и дизайны вполне могут быть частью беклога.
Если "люди важнее процессов", могу ли я считинговать и запланировать на спринт очень маленькую задачу, которую точно сделаю за пару часов и при этом у меня не будет давления
Я не скрам мастер, но по гайду
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.
Если про вот это то я не вижу там наследования реализации соответственно такая же ситуация как и с нестатиками. ( Все равно что имплемент метода либо явно определяем какой интерфейс реализуем либо неявно, но нет такого что две реализации пришли из разных веток даймонда)
Отлично, значит что-то принимающее тип и выдающее на его основе другой тип является дженериком. Напрмимер вы, когда берете тип животного и из него делаете тип клетки для этого типа животного. Но это не важно.
Клетка принимающая только собак, но при этом любую.собаку и гарантирующая, что выдает имеено собак не является ни под типом ни супертипом к клетке принимающей любое животное. На этом мы согласились?
Очевидно тогда клетка для собак это не клетка для любого типа животных.
В нее нельзя положить слона,
А гарантия "положить" на все супертипы.
Это как - в клетку для животных можно положить что угодно?
Клетка_для_любого<T> инвариантна относительно T.
Как и требует LSP - мы не можем подменить клетку в которое гарантированно помещается любое животное на клетку которая гарантирует что там только собаки и принимает только собак как и наоборот.
Дженерики - это, фактически, функции в пространстве типов. В зависимости от свойств функций, порождаемые ими типы могут сабтайпиться в любом направлении по отношению к аргументам, но для корректной работы должны удовлетворять LSP.
Тип - это множество возможных значений. Клетка для животных принимает все значения, что и клетка для кошек.
Тип клетки это множество возможных значений клеток. Клетка для собак это клетка для животных в том смысле, что собаки это животные, но клетка для собак это не клетка в которую можно положить любое животное. Например, слон в нее не уместится.
Клетка для животных в первом смысле не гарантирует того, что туда можно положить любое животное. Только то, что если оттуда удастся что-то достать, то это будет животное.
Клетка для любых животных и клетка для каких-то животных.
Ну если менеджеры комитятся на все-все-все фичи то вам нужен не скрам. Тогда четкие спецификации и никаких изменений после комитмента. Иначе любой процесс будет приводить к срыву.
Планируются обязательные и найситухев фичи. Обязательные фичи стараемся сделать в спринт. Найстухев можно перенести дальше. Соответственно, так и планируем загрузку.
Про дедлайны я уже несколько раз привел ссылку здесь что нет скрамгайде теперь комитмента сделать все фичи а только форекаст.
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.
А почему надо писать для новой экосистемы весь компилятор а не только бекэнд?
В каждой квартире поставить колонку с Алисой. За свои деньги. Отключать нельзя.
Если про вот это то я не вижу там наследования реализации соответственно такая же ситуация как и с нестатиками. ( Все равно что имплемент метода либо явно определяем какой интерфейс реализуем либо неявно, но нет такого что две реализации пришли из разных веток даймонда)
А как статики то наследуются?
Чем они принципиально отличаются от статиков в классах?
Отлично, значит что-то принимающее тип и выдающее на его основе другой тип является дженериком. Напрмимер вы, когда берете тип животного и из него делаете тип клетки для этого типа животного. Но это не важно.
Variance refers to how subtyping between more complex types relates to subtyping between their components.
Клетка принимающая только собак, но при этом любую.собаку и гарантирующая, что выдает имеено собак не является ни под типом ни супертипом к клетке принимающей любое животное. На этом мы согласились?
Собака подтип, а не супертип
А свойства должны быть таковы, чтобы соблюдать контракт клетки.
Клетка, которая принимает и выдает только собак не является клеткой которая принимает любое животное. Поэтому подстановка для них не работает.
Дженерик это функция которая делает из одного типа другой тип. То, что эта функция работает в голове а не выражена в ЯП на ход рассуждений не влияет.
Очевидно тогда клетка для собак это не клетка для любого типа животных.
В нее нельзя положить слона,
Это как - в клетку для животных можно положить что угодно?
Клетка_для_любого<T> инвариантна относительно T.
Как и требует LSP - мы не можем подменить клетку в которое гарантированно помещается любое животное на клетку которая гарантирует что там только собаки и принимает только собак как и наоборот.
Дженерики - это, фактически, функции в пространстве типов. В зависимости от свойств функций, порождаемые ими типы могут сабтайпиться в любом направлении по отношению к аргументам, но для корректной работы должны удовлетворять LSP.
Тип клетки это множество возможных значений клеток. Клетка для собак это клетка для животных в том смысле, что собаки это животные, но клетка для собак это не клетка в которую можно положить любое животное. Например, слон в нее не уместится.
Клетка для животных в первом смысле не гарантирует того, что туда можно положить любое животное. Только то, что если оттуда удастся что-то достать, то это будет животное.
Клетка для любых животных и клетка для каких-то животных.