User
Вот уже чуть больше года я активно использую Notion для планирования задач и проектов, поэтому я решил подвести некоторые итоги и систематизировать все приёмы, которые я использую. Описание системы будет состоять из двух частей. В первой части, я хотел бы уделить отдельное внимание Инбоксу — одной из самых важных составляющих удобной системы планирования. Вторая часть будет посвящена непосредственно Управлению проектами.
В итоге мы получим домашний сервер с фейковым доменом, на поддомене которого мы развернём GitLab и настроим работу gitlab-runner'а для деплоя наших веб-проектов.
Я не буду долго разглагольствовать по поводу каждого шага, лишь в крайних случаях буду описывать моменты, с которыми вы можете столкнуться в процессе и пути их решения.
В предыдущей статье “Jira без боли” (ч1, ч2) был небольшой эпизод про интеграции с другими сервисами через инструмент автоматизации n8n (читается как нейтн).
В этом материале расскажу, зачем он нам понадобился, какие задачи мы начали с его помощью решать, какую роль он сейчас играет у нас в Каруне. И чем он может быть полезен вам.
Сегодня Вы узнаете, как онлайн, с смс и регистрацией задеплоить своё приложение в kubernetes. Поехали!
В этой серии вы узнаете как собрать докер-образ приложения на Vue.js и как опубликовать его в GitHub Packages. Вот так. Вот в общем-то и... не всё... Одним GitHub Action, как это было для Spring Boot приложения, о котором я рассказывал тут, в этот раз обойтись не получится. Нужно ещё проделать некоторые манипуляции, о которых я и расскажу в данной статье.
Конечно, рядовым пользователям от использования Jira бывает больно, и это даже порождает целые сайты вроде — https://ifuckinghatejira.com/. Я же попытаюсь рассказать, как жить с Jira без боли хотя бы для бизнеса.
На протяжении последних трёх лет в компании Karuna я помогал масштабировать и адаптировать Jira под растущие потребности.
В паре статей хочу поделиться нашими лучшими практиками — готовыми решениями и всем тем, что позволит бизнесу закрывать свои боли с помощью этого инструмента.
Я надеюсь, в этих материалах вы найдёте не только прописные истины, но и массу ранее неизвестных вам фич, инструментов и подходов, а также сможете обращаться к статьям в будущем, чтобы подсмотреть, как решить ваши сложности. Я сам именно так и планирую использовать эти материалы.
В предыдущей статье я рассказал, как мы наводили порядок в Jira, готовились к масштабированию и переезду всех бизнес команд в этот инструмент, и как после переезда обеспечивали коллег необходимыми инструментами, которых в Jira нет из коробки: шаблонами, чек-листами, инструментами аналитики, WIP лимитами, и прочим.
После этого перед нами появились новые вызовы — многие проблемы бизнеса всё ещё не решались, или решались с помощью откровенных костылей. Поэтому нам предстояло превратить Jira в настоящий звездолёт.
Capability Maturity Model Integration (CMMI) – Комплексная модель производительности и зрелости – набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определенных областей деятельности.
Представьте себе, что в мире есть волшебное средство, которое в 7 раз повышает эффективность обучения — быстрее выучить английский, быстрее освоить программирование, быстрее понять что угодно в мире.
Удивительно, но такое средство было найдено в 1990 году американским социологом Майклом Хоу. Он провел серию тестов среди студентов и определил, что пользователи «волшебного средства» в 7 раз лучше запоминали материал, легко вспоминали факты и легко применяли знания на практике.
Тот, кто использовал «волшебное средство» был наголову выше обычных студентов. «Обычные» хуже помнили материал и хуже его понимали, более того, даже одаренные отличники были слабее тех, кто использовал это «волшебное средство».
Это удивительное средство...
Всем привет! Я Айыына Егорова, Agile Coach в inDrive. Хочу поделиться небольшим опытом работы с командами без спринтов с применением Kanban-метода. Cтатья будет полезна руководителям команд, скрам-мастерам и любым агентам изменений.
Вы узнаете, как быстро запустить работу в команде без спринтов: с чего начать, какими инструментами мы пользуемся в компании и какие ошибки нельзя допускать. Отдельно разберем пример проведения воркшопа STATIK в команде Localization.
Это сложная тема, которая периодически всплывает в среде IT-специалистов, об этом сказано уже немало, а вот для «неайтишников» многое может оказаться новостью. Как для тех, кто хочет «войти в IT», так и для тех, кто по роду своей деятельности вынужден работать вместе с IT-службами. Некоторые вещи будут очевидны для IT-специалистов, но не очевидными для других. Иногда из-за их непонимания люди допускают болезненные ошибки. Не только и не столько со своей карьерой, сколько в своём бизнесе делают ставку не на тех людей. Поэтому, давайте разберём этот вопрос без эмоций и на понятном для неспециалистов языке.
Можно сказать, что на данный момент самый распространенный подход в гибкой адаптивной разработке продуктов - Scrum. Одна из ролей в Scrum - собственно Scrum-мастер. Роль, в зоне ответственности которой лежит обучение команды, правильная настройка процессов в команде, выявление и устранение препятствий в работе.
Если руководство и команда не обладают опытом в работе по Scrum, можно ли понять вообще, чем на практике должен заниматься Scrum-мастер, эффективно ли он выполняет свою работу?
В IT очень легко «застрять» — остаться в примерно одной должности с теми же компетенциями, без роста зарплаты и каких-то интересных новых вызовов. Чтобы этого не случилось, нужно продвигаться по карьерной лестнице — не обязательно к руководящей должности, но к новым задачам и высотам.
Мы поговорили о карьерном росте с Алексеем Барановым, который со стартовой позиции в компании дорос до генерального директора с фиксированной зарплатой 10,000 $. Он поделился своим опытом и рассказал, как именно стоит действовать, чтобы улучшить свою карьерную позицию. Алексей работает в сфере продаж, однако его советы универсальны и полностью подходят в том числе для IT. Передаем ему слово.
Казалось бы, с документацией всё просто — пишешь, публикуешь, поддерживаешь актуальность. Например, вот у нас в Ozon есть пользовательские инструкции на docs.ozon.ru: выглядит просто как текст на сайтике, что ж необычного-то в его размещении и в целом в работе техписателей?
Если начать раскапывать, всплывёт ещё несколько вопросов:
• где хранить тексты и почему Confluence не подходит?
• как красиво оформить документацию с помощью статических генераторов сайтов
• зачем техписателям знать git и CI/CD?
• в какой момент пора искать разработчиков в команду и превращать документацию в платформу?
На связи Катя — руководитель отдела технических писателей в Ozon, и сегодня расскажу о платформе Docs Ozon изнутри.
Самый популярный вопрос у моих учеников — «как построить дерево метрик и с чего начать?», а следом за ним — можно ли сформировать бэклог продукта без дерева метрик.
Дерево метрик — это декомпозированная цель компании.
Как же часто мне приходилось слышать от рекрутеров одну и ту же фразу:
Мы работаем по Agile. Спринты по 1-2 недели
Под "Agile" они, конечно же, имеют в виду Scrum. Но я с уверенностью могу сказать, что ни в одной компании, что я работал, Agile'ом даже и не пахло. И тут я даже не говорю о том, что Agile каким он был задуман в принципе не дошел до массовой разработки (о чем рассказывал один из создателей Agile Дейв Томас на конференции GOTO 2015). Я говорю об Agile в общепринятом значении этого слова.
В дальнейшем, на техническом интервью, если спрашивать по пунктам, практически любой реальный работник компании подтвердит вам, что никакого Agile в компании нет, а используются лишь элементы Agile.
По некоторым причинам команде разработчиков либо не получается наладить работу по Agile, либо руководство знает, как лучше, и навязывает собственное видение методологии разработки. Эту проблему адресовал в своей статье Рон Джефрис (вот перевод на русский), дав красноречивое название подобным практикам — "Dark Scrum". Существует и более мягкая формулировка для тех, кто считает подобное положение вещей скорее фичей, а не багом — "Pseudo Agile" или "Post Agile".
В этой статье я постараюсь расставить точки над Ё и разобраться, что такое Agile на самом деле, и какие проблемы существуют у современных гибких методологий.
Привет! Хочу поделиться историей миграции сервисов логирования и трейсинга с компонентов Elastic Stack на Grafana Stack и тем, что из этого вышло. До миграции у нас в М2 использовались достаточно классические схемы:
Обучение программированию может быть сложной задачей, особенно когда не ясно, с чего начать. Лучший способ улучшить свои навыки программирования - использовать их для создания проектов.
Вот лучшие проекты для разработчика, которые укрепят вашу уверенность и помогут стать лучшим фронтедером, независимо от того, новичок вы или недавно вернулись к программированию. Я также отметил технологии, которые можно использовать в каждом проекте, но не стесняйтесь использовать любой из ваших любимых языков программирования или фреймворков.
Мой мадригал тем инструментам разработки, которые изменили мою жизнь
Программирование стало гораздо более многогранным ремеслом с тех пор, как в середине 1990-х я впервые попробовал AmigaBASIC. В те времена еще можно было купить один большой том о компьютере, на котором вы программируете – и там бы нашлось 99% всей нужной информации. Эта книга, где на множестве страниц уголки загнуты в качестве закладок, обклеенная стикерами, лежала бы у вас под рукой, пока вы вбивали бы команды в монохромный текстовый редактор.
Современная книга по клиентскому веб-фреймворку может быть толще, чем во времена программирования под C64 бывали мануалы, достаточные для создания полноценных игр. С другой стороны, сегодня информация по любым платформам, для которых требуется писать код, находится буквально в одном клике.
Сегодня никто бы больше и не подумал покупать документацию по разработке – и Microsoft, и Apple свободно выкладывают свою документацию в Интернете для всех желающих. А что говорить о проектах с открытым исходным кодом!
Во времена npm, PyPI и GitHub сложно объяснить, насколько неоднозначным решением (которое требовалось всесторонне обдумывать) раньше считалось потребовать хоть какие-нибудь возможности, которые выходили бы за рамки функционала операционной системы. Часто вместе с продуктом приходилось сдавать и все его зависимости.