Статья про trade-off между качеством и скоростью. Часто так бывает, что команды разработки готовы пожертвовать качеством, для того, чтобы увеличить свою скорость разработки. Это может исходить как от стейкхолдеров, так и от самой комманды разработки.

В статье дается также определение высоко-качественного ПО:

• Делает то, что должно делать
• Безопасное
• Поддерживаемое
• Делает то, что нужно пользователю

Проблема в том, что размен качество на скорость создает негативную обратную связь. Снижаем качество => снижается скорость, нам это не нравится, мы еще раз снижаем качество. В статье говориться, что trade-off качество-скорость - ложный. Его не существует. Мы не должны никогда резать качество в угоду скорости.

Если мы хотим разрабатывать быстро, то надо разрабатывать качественно

Что же предлагается делать?

• Строить культуру ответственности команды разрабокти за качество производимого
• Подерживать высокие стандарты качества
• Встраивать качество в процессы и оценку

Немного своих мыслей: хороший вопрос, который остался без ответа “что такое качество?” (ну точнее в статье ответ есть, но он очень абстрактный). Нужно ли нам всегда делать безупречное ПО? Действительно ли нужны безупречные интерфейсы? Действительно ли в каждой фиче следует следить за поддерживаемостью решения?

Для меня очевидно, что нет. ИМХМО, разные контексты требуют разного отношения. Степень “безупречности” будет отличаться для маркетингового лендинга и формы оплаты. Для лендинга, который будет жить всего неделю - не иметь автотестов, архитектуры, какие-то огрехи в UI и UX - это норма. Это то качество, которое нам требуется. Но для формы оплаты так не подойдёт - там цена бага большая, как и цена плохого дизайна системы.