Привет, меня зовут Паша, уже несколько лет я работаю QA-инженером. И всё чаще и чаще мне больно за индустрию QA, потому что не все понимают, чем QA-инженер отличается от тестировщика. Ведь настоящий QA-инженер может сделать продукт качественным разными путями, а не только проверяя конечную сборку на соответствие неким требованиям.

Этой статьёй я хочу ещё раз напомнить, как инструменты командного взаимодействия решают проблемы качественной разработки, что ответственность за качество лежит на всей команде и что agile-понятия «Прозрачность» и «Предсказуемость» часто теряются на фоне клепания тасок в Jira. Несмотря на свою очевидность, Agile-практики применяются не везде, где могли бы приносить пользу, либо применяются с ошибками и антипаттернами, противоречащими самой культуре Agile. Я расскажу, с какими сложностями столкнулся на разных этапах распространения этой культуры и что делал, чтобы их преодолеть.

Если вы готовы тащить такие практики или пробовали их, но не взлетело, тоже смело заходите под кат. Буду счастлив, если найдёте для себя что-то новое и интересное.

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

1. Circuit Breaker
2. Command and Query Responsibility Segregation (CQRS)
3. Event Sourcing
4. Sidecar
5. Backend-for-Frontend
6. Strangler

Как известно, системные администраторы делятся на 3 категории - кто еще не делает резервные копии, кто уже делает и кто уверен, что из них можно восстановиться. В нашу эпоху DevOps вопрос автоматизации управления резервным копирования стал еще более актуальным, поскольку каждая система предлагает свой уникальный способ создания (и восстановления) дампа и даже в пределах одной системы может быть множество разных способов хранения данных. В этой статье мы обсудим возможные стратегии и доступные технологические решения для создания резервных копий данных для развертываний в Kubernetes и поговорим о возможностях автоматизации и мониторинга процесса резервного копирования.

В State Of DevOps 2018 от DORA мы видим, что Нigh Performing компании используют Trunk Based Development. Разберемся, почему именно ее, какие ее преимущества и недостатки имеет эта модель.

Нередко на старте разработки цифрового продукта присутствует неопределенность - действительно ли проект принесет ту выгоду бизнесу, как запланировано, удастся ли уложиться в сроки и многое другое. Поэтому, прежде чем вкладываться в новую идею, проект или технологию нужно получить подтверждение, что они действительно сработают и будут востребованы у пользователей. Процесс проверки при этом должен быть достаточно быстрым и не затратным.

Меня зовут Анастасия Борознова, я начальник управления инновационных технологий ПГК, выпускница НИЯУ МИФИ и Бизнес-школы Сколково. В статье расскажу о том, как можно снизить неопределенность и риски на старте реализации цифровых продуктов, повысить мотивацию сотрудников к генерации идей по внедрению изменений и существенно увеличить скорость тестирования этих идей при помощи Proof-of-concept подхода - быстрой разработки прототипов.

Представим ситуацию — тестировщик находит баг, начинает обсуждать его с разработчиком — а тот настаивает, что это не баг, потому что в спецификации не было речи об этой функциональности. Знакомо?

Или потому что требования были неоднозначно сформулированы, и он их неправильно понял. А может наоборот, в них было так много информации, что потерялся фокус и некоторая часть информации пропала из виду во время разработки.

И в этой ситуации разработчик не является вредителем, который специально ошибся. На практике, если предоставить ему простые, понятные и, главное, — короткие требования — то количество ошибок, которые будут находить тестировщики, устремится к нулю.

Вы также наверняка знакомы со спорами на тему "баг это или фича". Клиенты обнаружили недоработки, и product owner приходит в команду с замечаниями. А тестировщик с разработчиком защищаются, объясняя это тем, что в изначальной постановке и речи не было о реализации этой фичи. И такие моменты потом заводятся в backlog.

Я считаю, что все такие задачи, заведенные после релиза, и являющиеся следствием плохо проработанной спецификации, — тоже баги. Баги, которые характеризуют качество вашего продукта.

Практически каждый инженер, практикующий DevOps, в какой-то момент сталкивается с задачей настройки правил доступа для своих проектов. В данной статье мы рассмотрим примеры настройки сетевых политик Kubernetes-кластера, в котором используется плагин Calico и осветим некоторые интересные моменты. Предполагаем, что у вас уже имеется кластер k8s, где в качестве сетевого плагина используется Calico.

Эта статья — программа обучения для наших менеджеров на испытательном сроке. У нее есть одна особенность. Все, кто прошел её, стали Junior Project Manager (PM).

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

Впервые прочитав эту цитату Кони Бюрера, который работал в Rational Software, я полагал, что корень всех проблем, возникающих при разработке ПО, кроется именно здесь. С тех пор я повзрослел, оброс шлейфом скепсиса и перестал писать код для продакшена. Я больше не несу ответственности за разработку, тестирование или поставку отдельных классов, компонентов и даже сервисов. Я отвечаю за максимально быструю и качественную поставку бизнес-ценности в рамках одного из ключевых бизнесов ЦФТ - сервиса денежных переводов Золотая корона.

Низкая производительность труда в России

Уточняем описание функций системы с помощью диаграммы Sequence (продолжение "Белки")

В данной статье рассмотрим, как можно детализировать (уточнить) описание автоматизируемой функции с помощью UML Sequence Diagram — диаграммы последовательности.

В данном примере я использую среду Enterprise Architect от австралийской компании Sparx Systems [1].
Полную спецификацию UML см. здесь [2].

Для начала поясню, что мы будем детализировать.
В 1-ой части статьи "От моделирования процессов к проектированию автоматизированной системы" мы моделировали процессы «сказочной» предметной области — строчки про белку из "Сказки о царе Салтане" А.С.Пушкина. И начали мы с диаграммы Activity. Потом во 2-ой части мы разработали функциональную модель с помощью диаграммы Use-case, на Рисунке 1 представлен фрагмент.

Рисунок 1. Связь требования и функции

Теперь мы хотим уточнить информацию о выполнении данной автоматизируемой функции:

• с какими компонентами интерфейса будет взаимодействовать наш пользователь;
• какие управляющие компоненты нам понадобятся;
• что мы будем хранить;
• какими сообщениями будут обмениваться пользователь и компоненты системы для выполнения функции.

Последние несколько лет все чаще доносится о том, что нынешняя модель Интернета морально устарела и требует пересмотра — корпорации жадно собирают данные пользователей, устраивают цензуру и знают о юзер больше, чем их ближайшие родственники. Лидеры мнений и индустрии предлагают свои идеи по формированию Web 3.0 и рассказывают о том, как сделать Сеть лучше и безопаснее. В этой статье рассмотрим историю развития Интернета, выделим отличительные черты каждой эпохи и проанализируем то, что нам пророчат в ближайшем будущем.

Всем привет. Меня зовут Рома, я-разработчик. За короткое время, в одной команде, на одном проекте, я поработал в трёх разных вариациях скрама. Ощущались они по-разному, и каждый новый вариант нравился мне меньше предыдущего. В этой статье я поделюсь своим опытом и выводами.

• Поймете причины поведения своих коллег, руководства и заказчиков в некоторых ситуациях
• Занесете в свой арсенал несколько простых приемов, которые помогут вам легче договариваться по работе
• Сможете абсолютно точно объяснить любому коллеге, что он неконструктивен (и в чем именно), если он действительно неконструктивен

Меня заинтересовал челлендж: в течение 26 недель откладывать N+100 руб, где N - сумма, вложенная на прошлой неделе. Я решил откладывать деньги по средам, составил такую табличку в Google Sheets