Философия DevOps

• Как часто возникают недоразумения между командами или участниками проекта? Были ли эти недоразумения специфичными для определенной группы или для метода общения?

В процессе выполнения определенных межкомандных проектов либо обычной текущей работы интересно исследовать, как часто члены одной команды общаются с членами другой. Хотят ли участники одной команды обращаться к участникам другой команды за советами? Насколько часто люди уточняют свои предположения о желающих общаться? Как часто люди ищут партнеров для работы в парах? Эти вопросы было бы неплохо задать в отдельных командах. Если же вы замечаете, что стили поведения, выявленные в процессе ответов на эти вопросы, наблюдаются на уровне отдельных команд, но не на межкомандном уровне, значит, что-то пошло не так.

Полезно также узнать, в каких проектах задействовано несколько команд, а в каких – всего лишь одна команда. Если в работе принимает участие несколько команд, делают они это одновременно либо одна команда завершает свою часть работы, а затем «перепоручает» оставшееся другой команде? Подобные перепоручения не всегда плохи, скорее это признак недостаточной степени внедрения совместной работы на протяжении всего процесса. В этом случае нужно исследовать рабочий процесс на предмет возможных улучшений. Если проект выполняется одной командной, то отсутствие сотрудничества между командами не страшно. Но если результаты выполнения проекта будут использоваться другими командами либо влиять на них, найдите способы привлечения этих команд.

«Возврат долгов» сообществу

Большая часть преимуществ, связанных с devops-движением, обеспечивается его сообществом. Это сообщество представляет собой группу практиков, которые собираются вместе, чтобы поговорить о работе и способах ее выполнения. В наши дни отсутствует завеса секретности, скрывающая технологии и методики, имевшая место в предыдущие десятилетия. Фактически некоторые из самых известных компаний, работающие в этом пространстве, в течение многих лет говорят не только о своих успехах, но и о неудачах.

Компания Etsy, известная своим техническим блогом Code и многочисленными инструментами, основанными на программах с открытым кодом, в том числе StatsD, называет эту идею «щедростью духа». Эта «щедрость» подразумевает написание постов в публичном блоге, выступления на отраслевых конференциях либо участие в создании программ с открытым кодом. Также сотрудникам предлагается принять участие хотя бы в одном мероприятии в течение года. Это позволяет убедиться в том, что эти люди продолжают приносить прибыль и «возвращать долги» сообществу. Любая организация, которая получает и использует полезные сведения, полученные на основе выступлений на конференциях, постов блогов, собраний или проектов с открытым кодом, должна приложить усилия для «возврата долгов» в натуральной форме.

Участники сообщества не прочь поделиться своей работой и идеями в свободной и открытой форме, что приводит к укреплению сообщества и повышает его ценность. Люди делятся идеями с помощью таких средств общения, как Twitter, LinkedIn, а также выступают на разных встречах и конференциях. Это позволяет сформировать отношения и связи, которые были бы невозможны в иных случаях. Откройте для себя новые решения и познакомьтесь с новыми идеями. Не тратьте зря время на решение проблем, которые уже были решены до вас (во многом благодаря использованию программ с открытым исходным кодом). Это позволит вам более эффективно использовать коллективное время и усилия.

Как уже упоминалось ранее в этой главе, частично успех сообщества определяется тем, что к плохим исполнителям, которые руководствуются соображениями личной заинтересованности за счет всей группы, могут быть применены санкции. Если поведение, недопустимое в условиях совместной работы, осуждается сообществом, а также проявляется «благородство духа» со стороны других организаций, тогда люди будут продолжать делиться знаниями и опытом с сообществом. Если же подобный обмен будет утерян, это нанесет удар по всей отрасли в целом.

Близость между командами разработчиков и эксплуатации в компании Sparkle Corp

«Мне нравится, что существует возможность сократить время разработки с помощью примеров использования, например функции обзора. Это позволяет улучшить впечатление конечного пользователя от нашего сервиса. На основе анализа нашего текущего графика я пришел к выводам о том, что мы можем потратить немного времени на оценку и разработку прототипа, если это целесообразно», – сказал Хедвиг после завершения демонстрации.

«Я обладаю минимальным опытом работы с MongoDB. Мне нужно согласовать все это с остальной частью команды, выяснить, каким опытом они обладают и насколько сложно будет принять новый проект, – предупредил Джордж. – Как инженер эксплуатации из Sparkle Corp, обладающий небольшим опытом работы, я не хочу поручать сомнительную работу эксплуатационной команде».