Про технические нефункциональные требования

На одном проекте сменился техрук. В прошлой его компании всё было на автотестах, тестировщиков не было. Ну вот он и решил быть в тренде и косты порезать- взял и сократил ручных тестировщиков. На архитектуру и код он перед этим не смотрел.

Как оказалось, в той системе были большие проблемы с Testability и Configurability. Проще говоря - писать автотесты дольше, чем кодировать, а локально развернуть и протестировать невозможно - только на окружениях. Тестировщики-ручники тестировали по наитию, без внятных тест-планов или всяких трасибилити матриц. Вопрос: что будет с проектом?

На другой проекте пришел эйджайл-коуч-трансформер. Знания его в технике сводились к словам "Девопс", "Юнит-тесты" и "Континиус интегрейшн/деплоймент", но с руководством он общаться умел. Ему дали натягивать скрам и двухнедельные релизы на группу внутренней автоматизации (это те ребята, которые пишут сугубо бек-офис). К самим разработчикам претензий не было, но у ребят был нулевой показатель Deployability. Простым языком - "для раскатки нужны особые Литании Раскатки и пара техножрецов для вознесения молитв Духу Сервера". В обшем, через n месяцев мучений, скрам не взлетел. Нервов разрабам потрепали изрядно, денег потратили порядочно. Самое интересное, что эти двухнедельные релизы бизнесу были не нужны и ему дали эту группу как пилот.

А как нужно-то делать?
Если вы стартуете или начинаете трансформировать проект или команду, нужно подключать грамотных технарей и выписывать все NFR, включая технические. Грубо говоря, делаем аудит и уже потом решаем, нужно ли что-то делать. Объясню на примере:

Дано:
- Бизнес с очень глубокими знаниями в доменной области
- Домен с очень специфическими бизнес-процессами
- Группа матёрых разработчиков-сениоров и сениорит
- В целом, ошибки допускаются - есть возможность откатить косяки в проде

Ход размышлений:
- Аналитик не особо поможет, потому что домен начисто отбитый. Это наоборот замедлит разработку и внесёт помехи. Т.к. разрабы опытные, то даём общаться им напрямую с бизнесом.
- Бизнес не будет писать портянки требований, а постоянно давать обратную связь. Значит, нам нужно делать малые каденции и часть деплоить (даже раз в день). Значит, выкручиваем на максимум Deployability.
- Нам нужен постоянный регресс из-за частых поставок и сложных требований. Значит, затачиваем Testability на интеграционные автотесты. Нужен ли тестировщик? Если есть очень грамотный, то можно для UAT. Если обычный - то будет мешать.
- Чтобы все было +/- стабильно, мы разрабатываем тактику Integrability (чтобы не толкаться локтями и обеспечить обратную совместимость).
- У нас нет серьезных требований по Reliability, значит все, что написано выше, может работать.

Выводы:
То, как у вас работало на прошлом проекте, может не взлететь в этом. Даже в той же компании, даже у того же бизнеса. Используйте цифры и здравый смысл при трансформациях и других вмешательствах в команду.