Как встроить качество в процессы производства ПО? (Часть 2)

Согласен! Интересно, что начало изменений и внедрение нового подхода указывается не как набор действий по натягиванию фрэймворков, а именно как работа с командой и их мышлением (восприятием) и созданию в голове ценности производства качественного результата.

Спасибо за статью, пошел думать.

Спасибо за вопрос!

Основная цель выстраивания процессов - это минимизация количества багов, которые утекут в прод. Подход описанный в статье, дает возможность во время этапа реализации получать обратную связь (читайте, а не наделали ли мы багов?). И на месте все правится. Это и есть Тесты-Вперед. Вы не пишите код до того пока не написали тест для него. Это подходы TDD, BDD и/или ATDD. Так у вас есть гарантия, что новый функционал не поломал то, что было написано раннее (т.е. баги не появились). Тесты править в основном нельзя (только если идет рефакторинг и реструктуризация кода), т.к. тесты отражают требования к функционалу. К примеру, Unit тесты - это из TDD. Они должны падать только по одной причине, ВDD тесты могут падать по нескольким, т.к. они сложнее. И если тест упал после реализации, то вот он баг - надо править. И в этом и есть прелесть. Вы не передаете дальше по этапам функционал с багами.

Но этого недостаточно, нужны также практики экстремального программирования - групповое владение кодом, групповые код ревью, анализаторы кода (Sonar, Purecov, Purify и т.д.). Это чтобы убрать человеческий фактор при разработке.

Надеюсь ответил на ваш вопрос.