6912
правок
Изменения
м
→Оценка при многих специализациях
Специализация в IT все возрастает, и все они нужны в разработке. Раньше достаточно было разработчика широкого профиля вместе с аналитиком, потом появвилась появилась специализация на front-end и back-end. А сейчас есть специализации на каждую мобильную платформу, и в целом количество специализаций превышает ограничение численности эффективной '''команды 7±2'''. В '''[https://www.facebook.com/groups/agilerussia/permalink/1681968131877413/ в В посте] ''' была описана именно такая ситуация, и сейчас я пишу по мотивам обсуждения. Там был дан пример команды.
# Аналитик
# BackEnd разработчик
Мы имеем уже семь узких специализаций. И многие практики перестают работать: непонятно, как делать оценку, потому что каждый компетентен в своей области. Непонятно, как обеспечить взаимозаменяемость специалистов, чтобы снять критичность при болезни одного, как избежать пробок в потоке работы из-за перегрузки одного специалиста и что делать с неполной загрузкой.
'''Универсальных рецептов ''' тут, естественно, нет, однако, это '''не означает, что все надо придумывать самому'''. Есть достаточно '''много практик''', из которых можно выбирать подходящие для ваших условий, и которые я выношу в пост. И хотя все написано на IT-примерах, это достаточно легко обобщается и на бизнес-команды, в которых вопрос специализаций стоит еще острее.
= Много специализаций в команде =
Если опыт достаточно большой, то можно '''калибровать размеры историй''' через примеры и примерную трудоемкость, например: "к средним историям у нас относится два типа задач: (1) сделать форму для ввода, обычно у нас занимают столько-то времени у таких-то специализаций; и (2) сделать отчет обычно у нас занимают столько-то времени у таких-то специализаций". Такая калибровка особенно полезна, когда в команде меняется состав и новым участникам надо освоить шкалы оценки. Список каждая команда может формировать и накапливать сама, но при этом списки разных всех команд должны быть в общем доступе для обмена опытом и взаимного сравнения.
А еще в описании задачи обязательно '''фиксировать аналогию историюистории''', и когда ее будут реализовывать - то смотреть за ее соблюдением. Если вскрываются какие-то особенности задачи, которые делают решение по аналогии непригодным, то необходимо в момент возникновения проинформировать и PO и других заинтересованных лиц. Daily Scrum Meenting подойдет, но при условии что к его моменту не уйдешь далеко по альтернативной ветви, и психологически будешь готов отказаться. Переписка в таск-трекере тоже, но только в таком варианте, когда получатели сообщений будут понимать: идет не рабочее уточнение задачи, а нештатная ситуация, требующая внимания.
Итого, для оценки есть два способа: каждый оценивает свое, и тут можно выдавать трудоемкость, или коллективная оценка по размеру историй.