tgoop.com/devops_architecture/54
Last Update:
Об менеджерское и инженерное рассмотрение процесса разработки [1/2]
Если продолжать обсуждать переход от документо-ориентированных (document-centric) процессов управления к программно-задаваемым (software-defined) (предыдущие посты: раз, два, три), легко упустить одно обстоятельство, которое одновременно наиболее ярко покажет совершившуюся революцию (и возможно окажется, что это революция консервативная).
А именно, ключевой фигурой, которая задает и контролирует некий процесс работы (например, процесс превращения фичи из замысла в код работающий на продакшне — через разработку, тестирование и другие стадии процесса разработки) перестал быть менеджер, как это было в документо-ориентированных процессах. Для программно-задаваемых процессов этой ключевой фигурой снова стал инженер, как это было до выделения менеджмента как отдельной дисциплины.
Менеджера в общем мало интересует содержание отдельных работ, его интересует выполнение взятых на себя обязательств исполнителями: чтобы разработчики в срок разработали код фичи и передали его тестировщикам, чтобы тестировщики протестировали фичу и передали его для деплоя на продакшн и т.п. Одна из основных задач менеджера - контроль таких обязательств. Если тот, кому передали результаты некоторой работы подписал акт приемки, менеджеру в целом не важно, работает ли фича на самом деле, закрывает ли она потребности клиента, т.к. обязательства прописанные в контракте выполняются. Ошибка на продакшне это всего лишь повод либо добавить в контракт "гарантийный срок на поставляемый результат" (как обязательство устранять дефекты в течение этого срока), либо открыть отдельный контракт на поддержку. И это все совершенно нормально и правильно, т.к. контракт за выполнением которого он следит - это интерфейс через который взаимодействуют организации. Если контракт плохо организован, начнет сбоить само взаимодействие.
Инженера же, напротив, интересует в первую очередь как именно происходит работа. Не соблюденный технологический процесс не приведет к тому результату, который мы ожидаем, в непротестированном коде почти наверняка будут ошибки. При этом, любая инженерная деятельность по своей сути весьма неравномерна — разработчик не может сказать "я написал код к фиче, как ее дальше будут тестировать и деплоить, и будет ли фича в принципе работать мне не важно". Почти всегда потребуется то или иное его участие и в других фазах. Ошибка найденная при тестировании или на продакшне возвращается к нему, и ее потребуется исправить. Для получения успешной системы в продакшне важно не только выполнение отдельных работ, но и весь технологический процесс, который поставляет результат в продакшн. В нем в отдельных фазах в принципе может не быть людей, а в других фазах могут участвовать одновременно несколько командных ролей, при этом у этих участников нет явно формализованной ответственности за участие в этой фазе. Если тестировщик нашел багу в написанном коде, разработчик садится с ним рядом и они вместе разбираются в чем там проблема, а не перекидывают тикеты друг другу ("-Я протестировал и нашел ошибку. -А я исправил. -А я снова потестировал и снова нашел"). При этом сбой на ранней стадии сквозного технологического процесса с большой вероятностью приведет к проблемам на его поздних стадиях, и поэтому этот процесс нужно проектировать также как и любой объект инженерной деятельности, и настолько же тщательно контролировать его реализацию: лучше всего описать его кодом чтобы получить гарантию что он всегда будет происходить именно так как проектировался.
BY Об DevOps и архитектуру
Share with your friend now:
tgoop.com/devops_architecture/54