Про вредительство
Nov. 29th, 2013 09:57 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
vit_rЛокомотив консультирования в Германии, фирма Sophist изобрела новую фигню. Сейчас мужик убеждает всех, как круто иметь негативные требования.
В принципе всё правильно, но консультантам надо абстрагироваться от слова «constrains». В результате получается фигня страшнее, чем с проталкиваемыой ими формой записи с must/shall/can. В данный момент он рассказывает, что в некоторых требованиях по тестированию не надо писать способ проверки, потому что requirement с отрицанием внутри - это такая хитрая штука, которая как-бы requirement, но не совсем requirement. Короче, софисты расчищают место под рынок семинаров.
С другой стороны толпы муравьёв сидят и переписывают в спецификации «must» в «can» и обратно, вместо того, чтобы поменять один атрибут в таблице. Если посмотреть по всей индустрии, объёмы получаются весьма существенные.
В принципе, это работа для секретарш, а не для специалистов, но кто же им доверит. Если идея пойдёт в массы, объёмы работ сильно увеличатся. (И ещё больше секретарш поставят себе на визитку Requirements Engineer)
С другой стороны я всеми четырьмя руками за. Не то, чтобы это было интересно, но оплата всё равно по часам. Один раз попытался предложить всё сделать скриптом, но идея поддержку не получила. Но две недели править руками десятки тысяч требований - это не самая идиотская работа из того, что порождают идеи профессоров и консультантов.
В принципе всё правильно, но консультантам надо абстрагироваться от слова «constrains». В результате получается фигня страшнее, чем с проталкиваемыой ими формой записи с must/shall/can. В данный момент он рассказывает, что в некоторых требованиях по тестированию не надо писать способ проверки, потому что requirement с отрицанием внутри - это такая хитрая штука, которая как-бы requirement, но не совсем requirement. Короче, софисты расчищают место под рынок семинаров.
С другой стороны толпы муравьёв сидят и переписывают в спецификации «must» в «can» и обратно, вместо того, чтобы поменять один атрибут в таблице. Если посмотреть по всей индустрии, объёмы получаются весьма существенные.
В принципе, это работа для секретарш, а не для специалистов, но кто же им доверит. Если идея пойдёт в массы, объёмы работ сильно увеличатся. (И ещё больше секретарш поставят себе на визитку Requirements Engineer)
С другой стороны я всеми четырьмя руками за. Не то, чтобы это было интересно, но оплата всё равно по часам. Один раз попытался предложить всё сделать скриптом, но идея поддержку не получила. Но две недели править руками десятки тысяч требований - это не самая идиотская работа из того, что порождают идеи профессоров и консультантов.
