Мне нравится изучать различные аспекты open-source проектов, особенно когда они набирают популярность в сфере DevOps. Проекты, которые относят к «технологиям DevOps», могут представлять собой масштабируемые системы для совместной работы, которые решают широкий спектр проблем – от методов передачи сообщений до мониторинга. Всегда есть что-то новое, что можно исследовать, устанавливать, раскручивать и исследовать.
Тем не менее, DevOps не может существовать без принципов. Некоторые из этих концепций – очевидные истины, для принятия которых требовалось некоторое время. В свою очередь, есть и другие идеи, которые помогают нам многое признавать и выходить за рамки наших когнитивных искажений.
Хотя, строго говоря, он не относится к DevOps, один из принципов, который изменил все для меня — это Канбан. Простая идея о том, что работа должна быть прозрачной и оптимизированной, была радикальной для такого хронически многозадачного человека, как я. Я поддерживаю наглядность рабочих процессов и по сей день. Возможность не теряться в задачах стала для меня огромным облегчением. Кроме того, я больше не радуюсь промежуточным успехам: теперь я радуюсь решенным задачам.
Чтобы узнать, что повлияло на моих коллег, я попросил членов DevOps-команды OpenSource.com поделиться своими мыслями по этому вопросу:
Какая из концепций DevOps (практика, принцип или модель) изменила вашу карьеру?
Алекс Бунарджич
Ошибайтесь быстрее, ошибайтесь как можно раньше, ошибайтесь так часто, как можете. До того, как я вник в эту удивительную концепцию, я тщетно бился и работал в стандартной водопадной модели. Моя карьера состояла из ряда неудачных проектов, и все они начинались с тезиса «Отказы недопустимы!». Это чрезвычайно утомительная модель, которая снижает эффективность работы и приводит к тому, что от одного разочарования к другому приходится переходить к другому.
Воплощение в жизнь шквала быстрых и неистовых отказов – лучшее, что случилось в моей карьере. Фрустрация сменилась ощущением полета. Это привело к массовому принятию/внедрению практик TDD [test-driven development – разработка на основе тестирования] и к осознанию того, что TDD — это не «test», а «DRIVING»!
Кэтрин Луи
Культурный хакинг. Я понятия не имела, что существует название метода, который я (как партизан) использовала, чтобы изменить корпоративную культуру, но потом я увидела видео Себа Паке «Ignite Montreal» и порадовалась, что этим занимаюсь не только я.
Клемент Верна
Постоянное улучшение. До тех пор, пока меня не познакомили с идеями непрерывного совершенствования, я не искал путей развития ни в своей работе, ни в карьере. Постоянное совершенствование заставило меня осознать, что именно зависит от меня. Я понял, что смогу бросить вызов самому себе, узнав что-то новое и выбравшись из своей зоны комфорта. Это привело к тому, что я начал вносить свой вклад в проект с открытым исходным кодом (Fedora), а затем начал работать в Red Hat. Это определенно изменило мою карьеру.
Джейсон Хиббетс
Все началось с «The Lean Startup» на моем первом саммите «Code for America Summit». Я отчетливо помню поворотный момент в моей карьере в 2012 году. Эрик Рис, автор «The Lean Startup» и член совета директоров “Code for America", был на сцене вместе с Тимом О’Райли. Они говорили о взломе кода, а также о культуре и неудачах при проверке знаний. Моим самым большим достижением было знакомство с «The Lean Startup». Я скачал книгу и прочитал большую ее часть во время полета домой. Она изменила мой подход к работе и к руководству командой.
Самым большим изменением, которое я внес, стало внедрение циклов обратной связи. Это критически повлияло на стиль работы и мою команду. Я сместил привычки моей команды в сторону принятия решений, основанных на данных. Мы стали обмениваться информацией и идеями в рамках циклов обратной связи. Также мы проводим еженедельные встречи для проверки здоровья и постоянно изучаем наши рабочие процессы и гипотезы. Кроме того, мы экспериментируем с новыми идеями и оцениваем эти эксперименты. Мы проводим встречи для в начале работы над задачей в процессе работы над ней и после ее завершения – это позволяет нам понять, что делать дальше, а что — нет, чтобы мы могли двигаться дальше.
Вилли-Питер Шауб
Во время двухмесячного академического отпуска в 2018 году меня осенило, что страх неудачи отбирает у меня энергию и страсть к разработке ПО, а я любил эту карьеру. Я понял, что ошибки – это не трагедия, а инструмент для инноваций, сотрудничества и непрерывного обучения, который подпитывает DevOps. И это осознание стало ключевым моментом в моей карьере. Прозрачность сотрудничества, прогрессивное воздействие, развитие, основанное на гипотезах и тестах, а также методы CD – все эти практики, создают возможности как можно скорее добиться отказа, провести проверки и адаптировать решения, над которыми мы работаем (и свою карьеру).
Ваша очередь
DevOps может многому вас научить, даже если вы ни разу не откроете терминал или какую-либо программу. Поэтому я задаю вам тот же вопрос:
Какая концепция из DevOps оказала наибольшее влияние на вашу карьеру?
Пожалуйста, поделитесь своими мыслями в комментариях.
Узнайте подробности, как получить востребованную профессию с нуля или Level Up по навыкам и зарплате, пройдя платные онлайн-курсы SkillFactory:
- Курс по DevOps (12 месяцев)
- Профессия Веб-разработчик (8 месяцев)
- Профессия UX-дизайнер с нуля (9 месяцев)
- Профессия Web-дизайнер (7 месяцев)
- Курс по Machine Learning (12 недель)
- Обучение профессии Data Science с нуля (12 месяцев)
- Профессия аналитика с любым стартовым уровнем (9 месяцев)
- Курс «Python для веб-разработки» (9 месяцев)
Полезное
ссылка на оригинал статьи https://habr.com/ru/company/skillfactory/blog/511040/
Добавить комментарий