Немного о качестве

Сегодня я бы хотел немного поговорить о качестве программного обеспечения.













Еще одна картинка:

Этот треугольник называют "железным", подразумевая, что нельзя изменить одну сторону, не меняя другие. Часто, нижнюю грань у этого треугольника подписывают как "функции", подразумевая, что чем больше функций, тем больше времени и денег необходимо. Но мне больше нравится вариант качество.
Давайте посмотрим простой пример: К вам пришел заказчик и вывалил на вас свои ожидания. Вы, например, в соответствии со Scrum, написали Backlog, примерно его оценили, назвали ориентировочное время и цену. Заказчика все устроило, вы подписали договор и, даже, выполнили пару спринтов. Вы молодец, по результатам этих спринтов выяснилось, что вы оценили достаточно хорошо и в заданный срок, с заданными финансами все функции реализуете. Все хорошо? Можно успокаиваться и начинать думать куда потратить премию? В большинстве случаев нет.
Как я уже сказал функции != качество. Вы сделаете в оговоренный срок весь функционал, но выясниться, что из-за огромного количества ошибок пользоваться им нельзя. Останется заказчик доволен? Или другой пример, у вас все работает (помним про лампочку), но когда разворачивается все это у заказчика и заходит первая тысяча пользователей все начинает тормозить. Ну как там заказчик? Еще не брызжет слюной?
Именно из-за таких ситуаций нельзя гнаться за количеством реализованных функций, PBI, User Story, называйте как хотите. Еще на этапе написания спецификаций (ТЗ, PBI) необходимо определиться с критериями качества. Если говорить про Scrum, то они должны быть описаны прямо в Backlog-е.
Для каждого PBI можно указать требования по приемке, например: приемлемое время отработки под нагрузкой, максимальное время занесения информации по сложному объекту (мы ведь нашим пользователям должны экономить время, а не хухры мухры). Также желательно задать Test Case, по которому программисты определят, хоть минимальную функциональность они обеспечили или нет (да и тестировщику будет от куда плясать).
Потом, когда дело дойдет до написания кода, необходимо подключать модульные тесты. Как только заработает интерфейс, сразу, не дожидаясь конца спринта, интеграции или чего там у вас обычно ждут, подключать тестировщиков, чтобы они прогоняли сценарии, которые программистам в голову не придут, а у заказчика из-за них упадет приложение.
Да, кстати, инструкции пользователя, это тоже "качество". Какая бы не была ваша программа замечательная, когда количество функций станет достаточно большим, пользователи скажут вам огромное спасибо, если у вас будет хорошая встроенная или хотя бы внешняя инструкция по использованию.
Ладно, на сегодня все. Кстати, весь этот поток сознания по мотивам все того же QADay.