Отличная статья, спасибо)
В вопросе 23 про 'use strict' поправьте ошибку, пожалуйста:
Object.defineProperties(obj, 'x', {
value: 1
})
delete obj.x // Uncaught TypeError: Property description must be an object: x</code>
В этом примере ошибка вызвана не наличием 'use strict', а неправильной записью, о чем и говорится в сообщении: Property description must be an object: x. А вот с записью:
использовали ли вы цели спринта и формулировали ли критерии готовночти этих целей? если да, то поделись пожалуйста примерами цель-DoD-таска именно в связке интересно
К целям спринта я лично отношусь скептически вопреки Scrum методолгии, потому как обычно спринт слишком малый промежуток, а команда может параллельно работать над несколькими целями. А вот в SAFe были цели на PI (Program Increment) - более длительный промежуток (4-5 спринтов). Они хорошо работали. Бизнес их приоритизировал во время планирования PI, а мы соответственно планировали задачи исходя из приоритета целей. Так у целей нет четкого срока закрытия - это может произойти как после первого спринта, так и по середине третьего, а команда может параллельно работать над разными целями внутри спринта. Для таких целей DoD довольно прозрачен - фича сделана и ей можно пользоваться. В обычном скраме цели больше отвлекают, по моему опыту.
у нас в команде в 2-х недельный спринт на скрам активности 8-9 часов на скрам активности и каждый день 2-3 часа на митинги у части команды, а сколько у вас примерно часов уходит на общекомандные созвоны?
На двухнедельный спринт общекомандных митингов (1ч планнинг, 1ч ретро, 1ч рефаймент, 15м*5дн=1ч15м) = 4ч15м. Если рефаймент не понадобился, то еще минус час. Митинги части команды сложно подсчитать, потому что тут очень много неизвестных переменных. То фронт общается с бэком по апи, то QA нашли багу и надо ее обсудить, то PO хочет прояснить как технически лучше решить проблему. Но все созвоны, которые частью команды, обычно полностью вас касаются и являются такой же важной работой, как писать код. Я в статье предлагаю минимизировать митинги, в которых люди успевают заскучать)
хватало разрабов (отдельно FE и BE), QA, был отдельный дизайнер и девопс на команду
PO/BA великолепно описывал задачи в описанной статье нотации и подготавливал их заранее
митингов было настолько мало, насколько возможно
люди понимали зачем собираются
ретроспективы каждый раз улучшали процесс
соблюдался четкий тайминг
не работало в командах, где:
слишком много человек, где митинги затягивались, а половина присутствующих скучала
слишком мало человек, где недостаточно экспертизы и, прикрываясь T-Shaped, из разрабов делали фулстеков, которые и дизайн себе должны придумать, и протестировать, и задачи описать
люди не понимали зачем собираются, считали процессы элементом конроля, не видели пользы
на ретроспективах не пытались найти решения, назначать ответственных
митинги могли длиться долго и нудно
Собственно, это и помешало. Как с этим бороться при хороших данных в виде полноценной команды оптимального размера, в статье описано. В работе с людьми не думаю, что могут быть универсальные инструкции. Потому и во вступлении говорю, что у меня есть часть ответа.
В вопросе 23 про 'use strict' поправьте ошибку, пожалуйста:
В этом примере ошибка вызвана не наличием 'use strict', а неправильной записью, о чем и говорится в сообщении: Property description must be an object: x. А вот с записью:
ошибка будет связана непосредственно с 'use strict'
Не болейте)
Отличные вопросы, спасибо!
К целям спринта я лично отношусь скептически вопреки Scrum методолгии, потому как обычно спринт слишком малый промежуток, а команда может параллельно работать над несколькими целями. А вот в SAFe были цели на PI (Program Increment) - более длительный промежуток (4-5 спринтов). Они хорошо работали. Бизнес их приоритизировал во время планирования PI, а мы соответственно планировали задачи исходя из приоритета целей. Так у целей нет четкого срока закрытия - это может произойти как после первого спринта, так и по середине третьего, а команда может параллельно работать над разными целями внутри спринта. Для таких целей DoD довольно прозрачен - фича сделана и ей можно пользоваться. В обычном скраме цели больше отвлекают, по моему опыту.
На двухнедельный спринт общекомандных митингов (1ч планнинг, 1ч ретро, 1ч рефаймент, 15м*5дн=1ч15м) = 4ч15м. Если рефаймент не понадобился, то еще минус час. Митинги части команды сложно подсчитать, потому что тут очень много неизвестных переменных. То фронт общается с бэком по апи, то QA нашли багу и надо ее обсудить, то PO хочет прояснить как технически лучше решить проблему. Но все созвоны, которые частью команды, обычно полностью вас касаются и являются такой же важной работой, как писать код. Я в статье предлагаю минимизировать митинги, в которых люди успевают заскучать)
Резюмируя: работало в команде, где:
хватало разрабов (отдельно FE и BE), QA, был отдельный дизайнер и девопс на команду
PO/BA великолепно описывал задачи в описанной статье нотации и подготавливал их заранее
митингов было настолько мало, насколько возможно
люди понимали зачем собираются
ретроспективы каждый раз улучшали процесс
соблюдался четкий тайминг
не работало в командах, где:
слишком много человек, где митинги затягивались, а половина присутствующих скучала
слишком мало человек, где недостаточно экспертизы и, прикрываясь T-Shaped, из разрабов делали фулстеков, которые и дизайн себе должны придумать, и протестировать, и задачи описать
люди не понимали зачем собираются, считали процессы элементом конроля, не видели пользы
на ретроспективах не пытались найти решения, назначать ответственных
митинги могли длиться долго и нудно
Собственно, это и помешало. Как с этим бороться при хороших данных в виде полноценной команды оптимального размера, в статье описано. В работе с людьми не думаю, что могут быть универсальные инструкции. Потому и во вступлении говорю, что у меня есть часть ответа.