На тренинге один из участников Роман подал интересную мысль. Она очень простая и короткая, прямо на один блогпост :)
Разбирали взаимосвязь и root cause (корневые причины) по проблемам и получилось следующее. Разработка ПО полна положительных обратных связей.
Например:
Давление по срокам -> снижение качества работы -> появление багов -> увеличение стоимости поддержки -> уменьшение производительности по новой функциональности -> рост давления по срокам
Тут я привел для простоты одну из веточек root cause. Есть как минимум еще одна через снижение мотивации команды.
Обратная связь положительная. Руководство пытается ускорить разработку, нажимая на команду. Ускориться можно только если снизить качество, что вы итоге приводит к снижению производительности и еще большему давлению на команду.
Это означает, что если ничего с этим не делать, то неизбежен кризис. Например, в первом случае (давление по срокам) иногда стоимость поддержки настолько возрастает, что компания просто бросает старый код и где-то рядом с нуля пишет новый.
Иногда, по мере ухудшения ситуациии, возникают новые связи, которые как-то компенсируют положительную обратную связь. Например, что-то пытаются с этим сделать, фиксируя требования для снижения давления.
Agile - это (в частности) способ превратить положительную обратную связь в отрицательную. Для приведенного примера будет так:
Давление по срокам -> сокращение сроков поставки (длины релиза, итерации) -> частое тестирование -> раннее обнаружение дефектов -> снижение затрат на тестирование -> уменьшение стоимости поддержки -> повышение производительности -> уменьшение давления по срокам.
Еще пример, может быть не такой тривиальный. Мы как то разбирали с ребятами причины, по которой автоматизация тестирования не дает результатов.
Автотесты не работают <- автотесты трудно поддерживать <- архитектура старого кода затрудняет создание тестов
Получается, пока тестировщики автоматизируют тестирование старого кода, команда разработчиков успевает выдать вдвое больше кода, который также трудно автотестировать!
Договорились, что в рамках итерации команда автоматизирует тестирование для нового функционала в первую очередь, а для старого по остаточному принципу. Сначала научились писать легко тестируемый код, и лишь потом взялись за задачу автоматизации тестирования для старого кода.
А что понимается под качеством в данной публикации?
ОтветитьУдалитьКлассная статья, сейчас тоже занимаемся подобным анализом, правда пока стараемся использовать более простые инструменты, типа "пять почему", но некоторые команды уже пробовали свои варианты Fault Tree делать.
ОтветитьУдалитьПо поводу давления по срокам, по-моему, тут коренная причина - неправильно установленные отношения с заказчиком (за частую из-за неумения поставлять продукт инкрементально в соответствии с ценностью для заказчика).
По автотестам согласен, у нас тоже есть такие проблемы с одной CMS'кой, но коренная причина тут, наверное не в легаси коде, а в плохом взаимодействии разработчиков и тестировщиков, а уже как следствии этого слабая архитектура через рефакторинг. Сейчас по одному проекту делаем диаграмму Парето по соответствию дефектов и компонентов, чтобы определить компоненты самые дорогие с точки зрения исправления багов, а затем тестировщики будут делать дополнительные автотесты, а разработчики аудит и рефакторинг.
> А что понимается под качеством в данной публикации?
ОтветитьУдалитьКачество кода
Давление по срокам -> снижение качества работы -> появление багов -> увеличение стоимости поддержки -> уменьшение производительности по новой функциональности -> рост давления по срокам
ОтветитьУдалитьЭто нужно распечатать и начальнику в лицо бросить)