Comments 4
В очередной раз вижу применение к требованиям аббревиатуры SMART без адаптации. Как может хорошее требование быть Time-bound?? Это характерно для задач, а не требований.
Я уже где-то в комментариях писал, что T в случае требований - это, скорее, Testable как в INVEST. Мы должны заранее думать о том, как проверять выполнение требования, отсюда растут DoD.
Да, вы правы! Собственно посыл и был в том, что методологию нужно адаптировать под себя. Если взять пример со SMART, то разумно применить Testable, как наиболее подходящее определение. Например, "Система должна генерировать отчет о текучести кадров за последние 12 месяцев в формате PDF".
Но если вернуться к классическому определению SMART, Time-bound может быть частью требований если это требуется бизнес-процессом. Например, "Система должна генерировать ежемесячный отчет о текучести кадров за последние 12 месяцев в формате PDF и отправлять его руководству компании до 5 числа каждого месяца."
И снова не соглашусь :-)
Вы привели скорее User Story, которая распадается на 3 (или 4 - во втором случае) требования.
Tome-bound говорит об ограничении времени действия - задача должна быть выполнена к определенному сроку. В случае требований это выглядит странно: "Требование генерации отчета о текучести кадров действует до 5 числа следующего месяца, после этого его можно не учитывать"...
SMART не методология, а техника постановки целей или задач. Применяйте инструмент по назначению, и не будет возникать вопрос "Почему оно не работает?"
Аналитика требований: SMART, INVEST, MoSCoW — пытаемся систематизировать хаос