Рекомендованая длина спринта в скраме — от недели до 4 недель.
Для разработчиков более удобны длинные спринты, поскольку меньше выбивают из потока, но они менее гибкие: создают риск появления мини-водопада внутри спринта, непрозрачность разработки для PO и бизнеса, реже проводятся ивенты, заточенные на адаптацию и оптимизацию команды. Короткие спринты идеальны для бизнеса, но не слишком удобны для Dev Team. Обычно при выборе длины спринта ищется компромисс исходя из реалий проекта.
Привет! Мы занимались разработкой только под мобильные устройства. Данные расширения использовалиcь под платформами Android и iOS и зарекомендовали себя отлично.
Не уверены, что при сборке под Linux это расширение не будет работать, нужно проверять.
Из минусов мы находили только то, что входящим в проект разработчикам немного сложнее разбираться в асинхронном приложении, построенном на базе UniRx. Но это уже больше относится к архитектурным вопросам, а не к данной библиотеке.
В статье не идет речь об изменении планировочного покера. Здесь сравниваются два разных способа оценивания.
Первый — собственно планировочный покер.
Второй — распределение историй по оценкам с помощью Silent sorting. Выглядит так:
0. Предварительно команде предоставляется возможность изучить стори, которые будут вынесены на оценивание;
1. На планировании на доску в ряд выстраиваются оценки по любой шкале — Фибоначчи, расширенный Фибоначчи или T-Shirt sizes;
2. Затем на стикеры или magnetic notes выписываются истории;
3. С помощью Silent sorting команда распределяет истории по оценкам;
4. Проводится дополнительное обсуждение по тем историям, которые были перемещены несколько раз.
Так вот, при использовании второго подхода можно достичь указанного в статье ускорения обработки историй на 10-15%.
Выбор того или иного решения напрямую зависит от конкретной задачи — в статье мы рассмотрели только распространенные подходы. Если возникает проблема с синхронизацией флага 'proceed', то стоит воспользоваться эксклюзивной блокировкой или «сигналингом», который обычно предпочтительней блокировок, потому что так рабочему потоку не нужно лишний раз просыпаться и проверять флаги или какие-либо источники данных.
Для разработчиков более удобны длинные спринты, поскольку меньше выбивают из потока, но они менее гибкие: создают риск появления мини-водопада внутри спринта, непрозрачность разработки для PO и бизнеса, реже проводятся ивенты, заточенные на адаптацию и оптимизацию команды. Короткие спринты идеальны для бизнеса, но не слишком удобны для Dev Team. Обычно при выборе длины спринта ищется компромисс исходя из реалий проекта.
Если говорить на языке js (es5 спецификации), то классов вообще как таковых нет, речь идет об объектах и прототипах.
Речь идет о помещении прототипа в отдельный файл.
Не уверены, что при сборке под Linux это расширение не будет работать, нужно проверять.
Из минусов мы находили только то, что входящим в проект разработчикам немного сложнее разбираться в асинхронном приложении, построенном на базе UniRx. Но это уже больше относится к архитектурным вопросам, а не к данной библиотеке.
Первый — собственно планировочный покер.
Второй — распределение историй по оценкам с помощью Silent sorting. Выглядит так:
0. Предварительно команде предоставляется возможность изучить стори, которые будут вынесены на оценивание;
1. На планировании на доску в ряд выстраиваются оценки по любой шкале — Фибоначчи, расширенный Фибоначчи или T-Shirt sizes;
2. Затем на стикеры или magnetic notes выписываются истории;
3. С помощью Silent sorting команда распределяет истории по оценкам;
4. Проводится дополнительное обсуждение по тем историям, которые были перемещены несколько раз.
Так вот, при использовании второго подхода можно достичь указанного в статье ускорения обработки историй на 10-15%.