Комментарии 2
В целом логика ясна, но составляли ли вы какие-то метрики, по которым можно судить, что введение этих концепций действительно ускорили разработку и ТТМ? Назначались ли ответственные от участвующих отделов, кто проверяет соблюдение критериев входа и выхода?
Добрый день!
Ответственность за соблюдение лежит на всей команде, их внедрение обсуждалось и согласовывалось. При этом финально соблюдение всех рекомендаций, особенно DoD, контролируется отделом тестирования, так как невыполнение каких-либо из них влияет на качество выпускаемого продукта. Например, при планировании спринта команда проверяет, что критерии входа соблюдены у задач, которые берутся в работу; промежуточная проверка проводится при взятии задачи в тестировании; ну и финальная тестером при ее закрытии. Кроме того, работает правило, если заметил, что кто-то что-то не выполнил — напомни, попроси сделать. Однако по максимуму сделано так, чтобы эти правила соблюдались автоматически, путем настроек пайплайнов или запретов переходов без заполнения нужных полей для исключения человеческого фактора.
В нашем случае эти практики внедрялись, в первую очередь, из-за их влияния на качество. Эту динамику отслеживали по количеству найденных дефектов, количеству возвратов тикетов в доработку, количеству регрессионных дефектов. В итоге это повлияло и на TTM (использовали Cycle time).
Зачем командам разработки и QA концепция DoR и DoD, и как не превратить ее в бюрократию