Иногда мне кажется, что шутки о том, что руководство внедряет Agile, чтобы успеть больше при меньших затратах, не так уж и далеки от истины. Я редко видел, чтобы команды разработчиков понимали Agile как что-то большее, чем просто набор церемоний, чаще всего ассоциируемых со Scrum. 

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

Sometimes it seems that jokes about management implementing Agile to do more with less aren't far from the truth. I've rarely seen development teams understand Agile as anything more than a set of ceremonies, most often associated with Scrum.

In my experience, attempts to optimize team performance often boil down to changing the internal processes within the team itself. Meanwhile, critical decisions are made outside the team, remaining in a waterfall model. This creates a disconnect: on one hand, company management strives for the flexibility of Agile, while on the other, they continue to follow rigid patterns, limiting the team and preventing it from fully realizing its potential.

Разобраться в тонкостях тестирования пользовательского интерфейса веб-приложений Flutter может быть непростой задачей. Если вы когда-либо ломали голову, размышляя о том, как применить свой опыт работы с Selenium к интерфейсу, нарисованному с помощью Flutter, эта статья для вас.

Мы рассмотрим метод, который поможет преодолеть разрыв между уникальным процессом рендеринга Flutter и мощными возможностями тестирования Selenium.

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

Многие думают, что запустить тесты Web UI с помощью известных инструментов не получится, но это не так. Давайте разбираться.

Navigating the intricacies of UI testing in the world of Flutter web applications can be a daunting task. If you've ever found yourself scratching your head, wondering how to apply your Selenium expertise to a Flutter-rendered interface, this article is for you. We're going to explore a method that bridges the gap between Flutter's unique rendering process and the robust testing capabilities of Selenium. Whether you're a seasoned tester or just starting out, the insights shared here will equip you with the knowledge to streamline your testing process and enhance the quality of your Flutter web apps. So, grab a cup of coffee, settle in, and let's unravel the mysteries of UI testing for Flutter web applications together.

В индустрии разработки программного обеспечения очень много времени и ресурсов тратится на совещания. У многих менеджеров календарь большую часть времени забит встречами.

По данным исследования компании Atlassian, средний работник тратит до 31 часа в месяц на непродуктивные совещания. Это примерно 8 часов в неделю, что равносильно полной рабочей неделе одного сотрудника из команды из пяти человек каждый месяц. Если мы переведем это в рабочие дни, то получается, что в среднем четыре человека работают, а один постоянно находится на совещаниях. Это не учитывает дополнительное время, потраченное на неформальные обсуждения и ad-hoc встречи, которые еще больше сокращают время, доступное для непосредственной работы над созданием продукта. Таким образом, разработчики фактически проводят менее половины своего рабочего дня на прямую разработку, что является тревожным сигналом для любой организаци.

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

Мое нежелание тратить время впустую или неэффективно, вылилось в то, что в департаменте разработки программного обеспечения мы тщательно следим за временем, которое наши разработчики тратят на совещания. В среднем, на разработчика приходится всего 2 часа 15 минут обязательных совещаний в неделю, включая четыре стендапа по 15 минут, встречу 1 на 1 с руководителем на 30 минут каждые две недели и 60 минут на различные совещания, такие как планирование и демонстрации. Остальное время, примерно 5 часов 45 минут, уходит на прочие активности в MS Teams, включая чаты и единичные созвоны. Хотя мы считаем, что и это время следует оптимизировать, основное внимание мы уделяем именно ключевым совещаниям, чтобы убедиться, что каждая минута проведенного времени имеет ценность.

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

In the software development industry, a lot of time and resources are spent on meetings. Many managers have calendars filled with meetings most of the time.

According to a study by Atlassian, the average worker spends up to 31 hours a month on unproductive meetings. That's about 8 hours a week, which is equivalent to a full work week for one employee out of a team of five people every month. If we convert this into working days, it means that on average four people are working, and one is constantly in meetings. This does not take into account additional time spent on informal discussions and ad-hoc meetings, which further reduce the time available for direct work on product creation. Thus, developers actually spend less than half of their working day on direct development, which is a worrying sign for any organization striving for innovation and efficiency.

Personally, I don't like meetings. I always try to minimize communication if an issue can be resolved without a face-to-face meeting. I apply this rule both at work and in life. For example, I prefer to refuel my car using an app, and I try to order food and other services without needing confirmation from an operator, and I did this even when such an approach was not so common. If I need to find a place, I will open a map in the app, instead of asking passers-by for directions.

My reluctance to waste time or be inefficient has resulted in our software development department carefully monitoring the time our developers spend on meetings. On average, a developer has only 2 hours and 15 minutes of mandatory meetings per week, including four 15-minute stand-ups, a 30-minute one-on-one meeting with a manager every two weeks, and 60 minutes for various meetings such as planning and demonstrations. The rest of the time, about 5 hours and 45 minutes, is spent on other activities in MS Teams, including chats and individual calls. Although we believe that this time should also be optimized, we focus mainly on key meetings to ensure that every minute spent is valuable.

In this article, I will consider the approaches I use and the ideas that motivate me to minimize the costs associated with meetings.

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

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

Я ожидаю, что некоторые из вас скажут: "Всё это очевидно, просто возьми и сделай". Но давайте не будем забывать, что целые книги написаны о том, как правильно описывать требования и структурировать работу, существуют стандарты, но проблема всё ещё актуальна. Понимание того, что перед нами не простая задача, приходит с опытом в разработке, и именно поэтому я отношу её к категории средней сложности. Я старался изложить её как можно проще, но уверен, что ваши конструктивные комментарии помогут сделать изложение идеальным. Спасибо вам заранее за это.

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

Я записал свои мысли и делюсь ими с вами. Это довольно распространенная проблема. Задачи висят без движения, их всё время откладывают. В статье поговорим о последствиях такого беспорядка, и как правильно с этим справляться.

Я изложу мой подход поддержания гигиены бэклога. Поверьте мне, ваша команда будет вам за это благодарна.

This week, I was reflecting on a recent one-on-one chat with a manager in my division about keeping our backlogs clean and dealing with those tasks that just keep getting pushed back.

I jot down my thoughts and decided to share them with you. It's a common issue, right? Tasks hanging around, always getting postponed. Let's talk about the mess this creates in our backlogs and how to handle it the right way.

Check out my latest article where I dive into the art of backlog hygiene. Trust me, your team will thank you for it!