Сейчас я буду как та бабка из Игры Престолов - ходить за вами и бубнить 'Позор! Позор!'
'Базовые принципы описания задач' Самое важное не написали: каждая задача описывается из расчета быть сделанной одним человеком за один рабочий день, отсюда следуют все ограничения по объему и смыслу.
Текст задачи пишется так чтобы был понятен абсолютно обнуленному человеку - в пн после выходных народ имена свои забывает, не то что скоуп работы. В идеале без привязки к контексту вообще, как будто для нового человека на проекте пишете.
Заголовок задачи содержит четкое указание к действию: исправить-добавить-реализовать и тд. В идеале человек получив вашу задачу вообще дальше думать не должен - сразу брать и делать. Получается такое - не всегда )
Теперь про ваш пример: 'Предположим, суть задачи сводится к тому, чтобы отобразить скидку на товаре в корзине в e-commerce приложении.'
Самая большая проблема: никак не описаны крайние состояния, т.е максимальная скидка, минимальная скидка или ее отсутствие. А это важно тк эти же состояния должны быть дальше протестированы QA.
Разработчик который будет это реализовывать гарантированно этот момент пропустит, тестировщик - тем более.
Да, очень верные дополнения, спасибо! В статье фокусировалась больше на продуктовых задачах: - исхожу из того, что продуктовая задача по дефолту про "сделать", а не "исправить"/"протестировать" - декомпозиция на более мелкие таски (1 задача = 1 день) остается на разработке
Мы в Joom очень стараемся, чтобы люди на всех этапах были вовлечены в происходящее и продакт не декомпозировал все до мельчайших деталей (он и не сможет сделать это так, как будет удобно разработке)
Ну и примеры были утрированы и сокращены :) Для крайних состояний можно даже отдельный блок в шаблоне сделать, чтобы их не упускать (я, признаюсь, тут упустила и не обратила на это должного внимания в статье)
о, не заметил коммент и расписал примерно то же самое в своем :)
про один рабочий день - увы, не всегда получается настолько мелко декомпозировать задачи. При этом иногда количество подобных задач будет настолько велико, что команда быстро взбунтуется и попросит хотя бы что-то объединить. Растет количество задач = растет и количество связей между задачами. Когда на проекте очень большой бэклог и команда, это все будет челмедведосвина и павлиноуткоежа напоминать.
Я для себя взял правило про "не более 3 дней", но оно тоже субъективно очень
Сейчас я буду как та бабка из Игры Престолов - ходить за вами и бубнить 'Позор! Позор!'
'Базовые принципы описания задач'
Самое важное не написали: каждая задача описывается из расчета быть сделанной одним человеком за один рабочий день, отсюда следуют все ограничения по объему и смыслу.
Текст задачи пишется так чтобы был понятен абсолютно обнуленному человеку - в пн после выходных народ имена свои забывает, не то что скоуп работы. В идеале без привязки к контексту вообще, как будто для нового человека на проекте пишете.
Заголовок задачи содержит четкое указание к действию: исправить-добавить-реализовать и тд.
В идеале человек получив вашу задачу вообще дальше думать не должен - сразу брать и делать. Получается такое - не всегда )
Теперь про ваш пример:
'Предположим, суть задачи сводится к тому, чтобы отобразить скидку на товаре в корзине в e-commerce приложении.'
Самая большая проблема: никак не описаны крайние состояния, т.е максимальная скидка, минимальная скидка или ее отсутствие. А это важно тк эти же состояния должны быть дальше протестированы QA.
Разработчик который будет это реализовывать гарантированно этот момент пропустит, тестировщик - тем более.
Да, очень верные дополнения, спасибо! В статье фокусировалась больше на продуктовых задачах:
- исхожу из того, что продуктовая задача по дефолту про "сделать", а не "исправить"/"протестировать"
- декомпозиция на более мелкие таски (1 задача = 1 день) остается на разработке
Мы в Joom очень стараемся, чтобы люди на всех этапах были вовлечены в происходящее и продакт не декомпозировал все до мельчайших деталей (он и не сможет сделать это так, как будет удобно разработке)
Ну и примеры были утрированы и сокращены :) Для крайних состояний можно даже отдельный блок в шаблоне сделать, чтобы их не упускать (я, признаюсь, тут упустила и не обратила на это должного внимания в статье)
Откуда взято про величину задачи? Очень интересует этот вопрос, но подобных рекомендаций (как вы привели) не встречала.
о, не заметил коммент и расписал примерно то же самое в своем :)
про один рабочий день - увы, не всегда получается настолько мелко декомпозировать задачи. При этом иногда количество подобных задач будет настолько велико, что команда быстро взбунтуется и попросит хотя бы что-то объединить. Растет количество задач = растет и количество связей между задачами. Когда на проекте очень большой бэклог и команда, это все будет челмедведосвина и павлиноуткоежа напоминать.
Я для себя взял правило про "не более 3 дней", но оно тоже субъективно очень