На моем текущем месте работы руководство очень трепетно относится к внесению трудозатрат. Необходимость ведения трудозатрат при продуктовой разработке - вопрос дискуссионный, но кто бы что не говорил, статистические данные могут быть полезны при планировании.
Как правило, если мыслить категориями гибких методологий задачи имеют иерархическую структуру, самые крупные - эпики, своеобразные вехи продукта, которые задают направление развития. Далее идут истории / фичи - законченные фрагменты функционала представляющие ценность. Внизу иерархии располагаются уже задачи предназначенные для конкретных исполнителей (аналитиков, дизайнеров, разработчиков). С моей точки зрения наибольшую ценность представляют исторические данные от том, на сколько точно команда попадает в оценку той или иной фичи. Однако точно оценить фичу целиком очень сложно, поэтому мы оцениваем только задачи нижнего уровня.
Большинство современных систем ведения задач позволяют не только фиксировать оценки и трудозатраты по конкретным задачам, но и агрегировать оценки подзадач в задачах верхнего уровня.
И вот в какой-то момент мы обратили внимание, что несмотря на то, что мы вроде бы достаточно точно оцениваем задачи нижнего уровня агрегированные трудозатраты по фиче все равно сильно уезжают за первоначальную оценку. Причина оказалась в том, некоторые участники команды вносили трудозатраты не в задачи нижнего уровня, а непосредственно в эпики и истории, размывая тем самым показатели.
Для ведения задач в компании используется продукт JetBrains YouTrack, поэтому для решения проблемы трудозатрат списываемых в верхнеуровневые задачи было решено воспользоваться механизмом пользовательских рабочих процессов (в YouTrack можно писать свои собственные рабочие процессы на JavaScript).
Ниже приведен фрагмент кода который не дает списывать трудозатраты (в терминах YouTrack - рабочие единицы) если тип задачи не подходит для этого.
const entities = require('@jetbrains/youtrack-scripting-api/entities');
var workflow = require('@jetbrains/youtrack-scripting-api/workflow');
exports.rule = entities.Issue.onChange({
title: '[ВСТАВИТЬ СМЕШНОЕ НАЗВАНИЕ]',
action: (ctx) => {
const issue = ctx.issue;
workflow.check(
!(issue.Type.name == ctx.YOUR_ISSUE_TYPE.name && ctx.issue.workItems.added.isNotEmpty()),
`Нельзя вносить трудозатраты в верхнеуровневые задачи ?`
);
},
requirements: {
Type: {
type: entities.EnumField.fieldType,
YOUR_ISSUE_TYPE: {
name: "[ТИП В КОТОРЫЙ НЕЛЬЗЯ РЕПОРТИТЬ ВРЕМЯ]"
}
}
}
});Немного пояснений.
Вот хорошее руководство от JetBrains про то, как добавлять новые рабочие процессы.
Наше правило работает при изменении задачи (добавление единиц работы), поэтому мы используем правило вида entities.Issue.onChange.
Далее мы используем готовый механизм из API YT workflow.check, с помощью которого проверяем тип текущей задачи и вносятся ли в нее в данный момент трудозатраты. Если проверка вернет false, YouTrack не даст выполнить действие и выведет сообщение.
workflow.check(
!(issue.Type.name == ctx.YOUR_ISSUE_TYPE.name && ctx.issue.workItems.added.isNotEmpty()),
`Нельзя вносить трудозатраты в верхнеуровневые задачи ?`
);В секции requirements описываются поля проекта, которые нам нужны, чтобы наше правило работало. Данный механизм облегчает жизнь сразу по нескольким направлениям.
Во-первых, когда наш процесс содержит требования при добавлении его в проект YT сам проверит, будет ли наш процесс работать в этом проекте. В данном конкретном случае он проверит, что в проекте есть настраиваемое поле Type, которое является перечислением и содержит значение YOUR_ISSUE_TYPE с именем "[ТИП В КОТОРЫЙ НЕЛЬЗЯ РЕПОРТИТЬ ВРЕМЯ]".
Во-вторых, все что мы объявили в требованиях можно использовать в коде, чтобы каждый раз не прописывать строковые значения типов, состояний и тому подобное.
Вот таким не хитрым образом можно попытаться добиться чистых трудозатрат по фичам, историям и эпикам.
А что вы думаете по поводу фиксирования трудозатрат?
Пожалуйста напишите в комментариях.
