Комментарий
work-to-rule
← Регламентация: начинаем за здравие, кончаем итальянской забастовкой
Обсуждение
Читать и комментировать в ЖЖ ↗
Комментарий
Идеальная форма регламентации получается это "формальный язык описания задания" )) Все что можно описать на языке и совместимое с предыдущими описаниями на этом же языке мы автоматически пропускаем в работу поскольку это "всего навсего валидное описание процесса". За осмысленность вносимого изменения отвечает тот кто внес и тот кто одобрил.
Комментарий
tnx, fixed
Комментарий
Так а разве нельзя этот же самый график "переложить" на работу с требованиями (условно, из RUP)? Стоимость переделок из-за незафиксированных требований, стоимость выявления требований (фиксация, согласование, моделирование, проектирование), итоговое время разработки. И чем более пологая кривая стоимости переделок из-за ошибок, тем детальнее нужно фиксировать требования, а чем она круче, тем менее детаельнее: запуск ракеты vs перекраска кнопочки на сайте
Комментарий
А требований вообще нет ))) Есть гипотезы, и работают с требованиями не аналитики. У меня несколько подразделов в курсе по этому вопросу, подробненько.
Комментарий
Да, типа того. Только "формальность" под вопросом, но ещё под вопросом "кто внёс и кто одобрил". Кто внёс, тот и одобрил. Никаких аналитиков, только инженеры: инженеры принимают решения, а не "делают предложения для имеющих право их одобрить". Никакого каскадирования.
Комментарий
Да-да, я читал их, и слушал выступления. Будущее наступило, но не везде и не сразу. Пока мне лично в моём маленьком уголку удобнее считать, что требования есть. По крайней мере, для управления ожиданиями стейкхолдеров о составе будущего релиза. Там много а-ля MoSCow-приоритезации и много гипотез, но все же, возаращаясь к моему первому комменту, ощущение, как будто бы тоже существует некий оптимум по уровню детализации зафиксированного
Комментарий
Это два разных измерения: оптимум по детализации и "требовательность". Ибо в доксе тоже может быть детализация разная, не только в деонтике.