В результате приостановки работы зарубежных компаний и отключения российских компаний от платежных систем Visa и MasterCard многие программисты столкнулись с проблемой доступа к привычным сервисам. Рассказываем о бесплатных альтернативах продуктам, которые уже недоступны для российских пользователей по корпоративным подпискам или могут стать такими в ближайшее время.
За почти четырнадцатилетнюю историю использования Jira и Confluence на Московской бирже в них накоплен огромный объем данных: у нас более 350 проектов в Jira и более 200 пространств в Confluence. Не будет преувеличением сказать, что в этих продуктах сейчас работает вся Биржа, а не только айтишники. Оперблок ведет в Confluence чеклисты регламентных операций, бизнес и аналитики пишут и согласовывают функциональные задания. В Jira недавно перевели проектный портал, которым заведует Проектный офис. Фактически продукты Atlassian у нас используются в режиме, приближенном к 24*7. Поэтому вопросы резервного копирования, восстановления в случае сбоя и времени вынужденного простоя уже давно стояли для нас весьма остро. В прошлом году мы сделали теплый резерв Jira и Confluence буквально на коленке, о чем и расскажем в этой статье. Ничего уникального, но тем выше шанс, что наш подход принесет пользу кому-то еще – увы, Atlassian уже начала отзывать лицензии, и неизвестно, что будет дальше.
За время жизни продукта, безусловно, приходится собирать большое количество данных, анализировать и принимать на их основе решения.
Но как сделать так, чтобы всеми метриками было удобно пользоваться? Чтобы не приходилось собирать всё вручную, а была бы единая точка входа к данным, и сама полученная информация помогала контролировать состояние дел и проводить верную оценку.
Мы нашли для себя удобный способ сбора и отображения данных о проектах и сотрудниках, которые в них задействованы, и хотим поделиться этим способом в статье. Как всегда, мы открыты к диалогу и надеемся, что это решение пригодится в работе или вы адаптируете его по-своему.
Салют, коллеги.
Лично я, очень люблю поговорить про качество, поддерживаемость и выразительность кода (эти умные слова, часто звучат на код ревью)
К сожалению, такие разговоры часто и быстро скатываются в холивар. Но, кажется, я нашел способ "вести разговоры о высоком без боли".
Мысль такая, если приземлить обсуждение на конкретную практическую задачу, то будет сильно проще понять, какой именно смысл вкладывает в слово "выразительность" собеседник.
Всем привет!
Меня зовут Олеся Гаврилова, я руководитель направления по координации проектов в Почтатехн.
Хочу вам рассказать о том, как команда проектного офиса выстраивает систему управления проектами в ПочтаТех, какие задачи стояли перед нами год назад, как мы их решали, к чему пришли и каковы наши дальнейшие планы.
Причины для создания системы управления проектами прозвучат, как в учебниках о проектном управлении: активностей стало больше и их масштаб вырос, из чего стало сложно отделить, какие из активностей требует применения инструментов проектного управления, какие нет и как мы будем достигать поставленные цели.
Что было на момент старта работы проектного офиса:
1. Комитет цифровой трансформации - орган, который утверждал ряд проектов.
2. Ранжирование и отбор проектов, которые рассматривает Комитет.
3. Проекты/продукты, которые утверждал комитет и проекты/продукты, которые реализовались без его участия.
4. Из процессов: подготовка к выходу на Комитет для утверждения проекта, предоставление отчетных материалов по достижению их ключевых результатов.
5. Для управления проектами: 3 информационные системы, MS project, MS excel. Каждый использовал, что ему нравилось больше.
6. Компетенции сотрудников. В компании работают, как люди с большим опытом, так и люди, которые делают первые шаги в области проектного управления.
7. Менеджеры проектов в первую очередь опираются на собственный опыт при реализации проектов, следовательно, успех проекта зависит от имеющегося опыта у менеджера.
В этом году звезды сошлись и я поняла, что гайд по контенту поможет решить кучу вопросов, с которыми я начала всё чаще сталкиваться.
Салют, коллеги.
В рамках пятничной статьи предлагаю посмотреть на интересный способ создания моков в Kotlin, без использования сторонних библиотек.
Я занимаюсь разработкой аддонов для Atlassian-стека в компании Stiltsoft и, из-за технических ограничений, до сих пор (да в 2021 году и, скорее всего, в ближайшие пару лет) вынужден использовать Java 8. Но, чтоб не отставать от прогрессивного человечества, внутри компании мы пробуем Kotlin, пишем на нем тесты и разные экспериментальные продукты.
Однако, вернемся к тестам. Часто у нас есть интерфейс из предметной области, нам не принадлежащий, но который активно используется нашим кодом. Причем у самого интерфейса много разных методов, но в каждом сценарии используем их буквально по паре штук. Например, интерфейс ApplicationUser.
Привет, Хабр!
На связи Гончик, любитель APM (application performance monitoring) инструментов, в частности Glowroot.
Сегодня расскажу о том, как за кратчайшее время найти узкие места в Confluence On-Prem на основе одной промышленной инсталляции. Поскольку стенд использовался для обучения, где источником базы знаний был Confluence. А осень это пора наплыва пользователей-учеников и необходимо было провести аудит и подготовить изменения, поскольку система уже претерпевала ранее проблемы отдачи своевременно контента пользователям в периоды наплыва читателей.
Описание построения процесса календарного и оперативного планирования в связке JIRA<->"локальный MSProject" на примере реализации в одном российском банке.
В предыдущей статье "Несколько примеров успешного изобретения велосипеда" мы поделились рядом решений, полученных путем комбинирования наших плагинов для Atlassian, таких как MyGroovy, JSIncluder и MyCalendar. На этот раз мы рассмотрим еще один плагин из нашей коллекции — Custom Select List.
Почему я решил написать эту статью?
Поработав в нескольких крупных ИТ компаниях на позициях руководителя проектного офиса, я поучаствовал в реализации различных архитектур управления проектами и портфелями. Важную и проблемную часть при этом составляли системы планирования – при кажущейся простоте и широком спектре решений на рынке. Проблема заключается в том, что планирование в компании - это несколько процессов:
• краткосрочное планирование (спринты),
• планирование проектов (контрактов),
• планирование загрузки ресурсов
• и наконец финансовое планирование (квартал, год и т.д.).
Все эти процессы связанны между собой, но в практике не реализуются в одной информационной системе. Поэтому хочу поделиться о своем опыте, удачных архитектурных решениях, которые в итоге позволили сделать более эффективными процессы управления проектами, бюджетирования и финансового планирования, благодаря интеграции различных процессов планирования.
Несколько лет назад небольшой командой сделали тестовый прототип PvP-шутера, который внезапно выстрелил. Тогда ни разработчики, ни процессы не были готовы к такой популярности, мы развивали проект здесь и сейчас — с энтузиазмом хватались за все понравившиеся идеи и старались реализовать их к ближайшему апдейту.
Когда команда увеличилась вдвое, а работы кратно прибавилось, старые процессы перестали работать. Мы могли запросто утонуть в операционке, если бы вовремя не начали меняться.
Материал для тех, кто задумался о долгосрочном планировании или только начал выстраивать процессы у себя. Внутри я подробно рассказал про наш опыт: как мы целиком обновили воркфлоу разработки, внедрили Jira, систему оценки фичей ICE, методологию планирования GIST, а также целую пачку новых инструментов и гуглдоков. Теперь мы на несколько месяцев вперед точно знаем, что будет в проекте.
Чтобы IT продукт вышел качественным, вам, разумеется, нужно контролировать процесс его создания. В этом помогают системы управления IT-задачами, значительно упрощающие жизнь как рядовых разработчиков и тестировщиков, так и «проверяющих».
Важно, чтобы систему контроля можно было настроить по всем важным для вас параметрам, и в этом плане отлично подходит Jira. Не зря же она фактически стала стандартом в сфере IT. В Jira пользователь может настроить всё под себя, а это дает возможность использовать самые разные методики ведения задач. Если при этом пользоваться другими продуктами компании Atlassian, то можно бесшовно расширить управление задачами до реализации CI/CD и ведения документации, это тоже облегчает жизнь.
Но нам ведь важно не только удобство. В определенный момент компании приходится контролировать реальную стоимость решений, и проблема управления ресурсами и бюджетами выходит на первый план.
Малым и средним компаниям вполне хватит стандартных инструментов Jira для управления ресурсами: контроль трудозатрат «из коробки», решения Tempo для гибкого планирования и контроля, а также Big Picture и бюджетирование. Но, когда дело касается Enterprise сегмента, всё резко усложняется. Появляются дополнительные разрезы отчетности, группы проектов, различные бюджеты. Давайте постараемся найти лучшие варианты реализации ресурсного планирования в Jira, исходя из опыта, полученного нами ранее в реальных проектах.
Для начала сформулируем бизнес-проблемы и вытекающие из них требования к решению.
Статья для менеджеров, которым необходимо вести управление проектами в изменчивом мире Agile. Поделюсь опытом использования двух приложений Jira Roadmap и Structure Gantt.
В настоящей статье расскажу историю о том, как можно столкнуться с довольно простой проблемой на больших инсталляциях продуктов компании Atlassian, в частности на Jira.
Методы анализа и поиска узких мест базируясь на простом инструменте Glowroot...
Андрей Маркелов работает в компании Atlassian над продуктом Confluence Cloud. В прошлом работал в Mail.ru, был аутсорсером в NFL.com, работал в advertising-стартапе. Много времени отдал компании Infobip.
Андрей в индустрии с 2007 года. Больше 5 лет занимался аутсорсом для IBM, когда десктопные приложения были еще очень популярны. Там он делал DB2 Recovery Expert for Multiplatforms и другие странные продукты, которые до сих пор существуют, но не имеют широкой популярности. Сейчас переехал жить в Долину.
Мы поговорили с Андреем про то, как сделать себе имя, разрабатывая плагины на голом энтузиазме, почему опытные разрабы мучаются от синдрома самозванца, каково работать над продуктом, которым пользуется половина индустрии, и куда движутся технологии.
Всем привет, я Java-разработчик в ЮMoney.
В этой статье я хочу поговорить о том, какой профит можно получить от оптимизации действующих в компании инструментов, почему это стоит делать и с чего лучше начинать. На примере стека Atlassian и Bitbucket-плагина, который мы используем в ЮMoney, я расскажу и покажу всё в деталях.
Возросшие риски не оправдывают высокую стоимость и слабеющий потенциал роста Big Tech компаний.
Есть пара имен из IT сектора, которые не прибавят вам популярности на вечеринках, но, на наш взгляд, будут расти значительно быстрее рынка.
