Agile *

В начале почти любого проекта приходится решать, как именно им управлять. Выбор сегодня огромен: от классического PMBOK до Kanban и гибких подходов. Но на практике этот выбор слишком часто определяется не логикой самого проекта, а личными предпочтениями, корпоративной инерцией или очередной управленческой модой.

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

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

Техническое решение: Установка камер на уровне лица с углом обзора 120°, обеспечивающих:

Видимость лиц при входе/выходе

Точность до 99.5%+

Сохранение соответствия DPDPA (90 дней хранения для отладки, затем удаление изображений)

Экономическое обоснование (для 56 автобусов):

Стоимость установки: 23.7 млн₽

Дополнительная защита: 12–20 млн₽/год

ROI: 51–84% годовых

Срок окупаемости: 14–23 месяца

Но главное: защита от системных рисков (штрафы, репутация, мошенничество)

Статус: Веду переговоры по интеграции с компанией, которая предоставляет доступ к системам электробусов. Это позволит нам расширить покрытие и снизить затраты на установку.

Понедельник. Спланировали неделю, к среде 90% задач не тронуты, завершаете в огне. Знакомо?

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

Доброго дня

В 2011 году у нас была идея сделать на web онлайн mind-web доску и недавно идея воплотилась в реальность.

Название приложения — «Наброски», или WebSketch, ссылка.

Здравствуйте всем, я – менеджер продукта в компании «СИБИНТЕК». Если вы решите изучать Agile‑подходы самостоятельно или запишитесь на тренинг, то рано или поздно столкнетесь с фреймворком Кеневин (Cynefin). Он, как и фреймворк Scrum, прост в понимании и достаточно сложен для совершенного овладения. Но, возможно, это как закон тяготения Ньютона: вы его не применяете в повседневной жизни, а просто действуете соразмерно этому закону. Кстати, «cynefin» – валлийское слово, которое переводится как «среда обитания».

Уэльское происхождение названия фреймворка не удивительно. Его разработчик – шотландец. Кеневин создали для руководителей и специалистов: он помогает выбрать подходы к принятию решений для задач различного уровня сложности. Давайте заглянем в мир Кеневин, которому уже более 25 лет.

Автор фреймворка предполагает в своей модели, что реальный мир вокруг нас – это множество взаимосвязанных систем, в которых действуют различные агенты‑модуляторы: люди, компании, регламенты, процессы, события и др., которые постоянно взаимодействуют между собой. Количество и характер их взаимодействий определяет сложность каждой из систем. Все эти системы автор делит на четыре типа (домена): упорядоченные простые, упорядоченные сложные, комплексные и хаотические. В каждом из этих доменов предлагается своя модель принятия решений. Нужно сразу сказать, что Кеневин – это не столько категоризационная, сколько смыслообразующая модель. Это аналитический фреймворк.

Если вы хоть раз гуглили «как настроить Obsidian для задач» - вы знаете, чем это заканчивается. Три часа в YouTube, пять вкладок с гайдами, десяток установленных плагинов и... система не работает. Потому что это чужая система.

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

Если тема управления знаниями и задачами в Obsidian вам близка - заглядывайте в мой тг-канал, там я разбираю подобные вещи регулярно.

TL;DR перевода статьи Boris Tane: SDLC is dead.

SDLC больше нет. AI-агенты не ускорили привычный жизненный цикл разработки, они его схлопнули.

- Agile-ритуалы мертвы. Планирование спринтов, оценки в story points, релизные поезда и многодневные ожидания аппрувов в PR — всё это пережитки прошлого.

- Все этапы слились воедино. Сбор требований, system design, написание кода и тестов происходят одновременно — в реальном времени и в диалоге с агентом.

- Code Review — это новый луддизм. Машина генерирует 500 PR в день, человек физически не может их проверить. Код должен лететь прямо в main под прикрытием автотестов, feature flags и хорошо настроенного observability.

Новый жизненный цикл — это узкая петля: Intent (Намерение) → Build (Создание) → Observe (Наблюдение).

Привет, Хабр! Меня зовут Елизавета, я скрам-мастер стрима ДБО (веб-версия дистанционного банковского обслуживания) для банков в команде РСХБ.Цифра. Выстраиваю процессы на основе человекоцентричного подхода, помогаю команде раскрывать потенциал. В этом материале хочу поделиться с вами историей о том, как мы превратили обычную задачу по формированию команд в приятный процесс. Да, это возможно! Расскажу не только о методиках, но и человеческих взаимоотношениях, где психология — лучший друг программистов и тимлидов, которые объединяются ради создания продукта в финтехе.

Мы едим хлеб, а не смотрим на замешивание теста

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

Мы должны руководствоваться достижением цели, а не удобством процессов.

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

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

Как руководитель отдела ИИ с опытом внедрения решений в холдингах на 15 000+ сотрудников, я вижу, что только системный инженерный подход спасает проекты от превращения в «дорогой гараж».

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

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

Большинство команд, которые внедрили канбан, на самом деле просто создали доску с колонками. Перетащили стикеры слева направо — и решили, что на этом все. Но канбан — это не формат доски, а метод управления потоком работы.

Мы тут решили дотошно разобраться и рассказать, из чего он состоит на практике: инструменты, принципы, WIP-лимиты и метрики. 

В посте рассмотрим модель эффективной команды под названием "Учпочмак".

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

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

Java называют языком программирования. С формальной точки зрения это может быть и так. На практике картина более широкая: я считаю, что Java нужно рассматривать как целую программную систему для гибкой (Agile) разработки. В ней можно выделить четыре ключевых подсистемы, которые вместе образуют Java платформу:

1. Система ведения онтологии и моделирования бизнеса
2. Система верификации типов с правилами подстановки
3. Система среды исполнения динамического кода
4. Система модульной эволюции кодовой базы

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

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

После обширного анализа будет представлено видение направления развития Явы как платформы, получившей новую среду скриптовых языков GraalVM. Основным тезисом служит заявление, что Агиль методология требует строгой трактовки, дисциплины и продуманных инструментов, чтобы свобода разработчика не превратилась в её свободный полёт в пучину хаоса.

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

Проблема: когда коммуникации поглощают рабочее время

Исследование: сколько времени уходит на коммуникации?

Практика: три разных мира коммуникаций

Размер имеет значение

План действий: как вернуть время для работы

Как измерить успех?

Обратная сторона медали: когда нельзя сокращать коммуникации

Краткий вывод

Сегодня Agile — почти стандарт в IT(и не только). Его используют стартапы, корпорации и даже государственные организации. Но мало кто задумывается, что Agile — это не методология.

Agile — это философия управления разработкой, основанная на адаптации к изменениям, быстрых итерациях и тесном взаимодействии с пользователями.

Ни‑че‑го не понятно. Да, есть такое, но давайте разбираться, что такое Agile, откуда он взялся, что было до него и почему сейчас большинство рынка его придерживаются.

До Agile: эпоха водопадов

До начала 2000-х основной моделью разработки была каскадная модель (Waterfall/Водопад).

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

На связи Анастасия Шильникова, менеджер по тестированию компании «Гарда».

Мы регулярно сталкиваемся с ситуациями, когда в Jira к задаче вроде есть какое-то описание, стоит статус «готово», но, чтобы понять, в чем была проблема, что было исправлено, как было проверено, приходится «нырять» в мессенджер или звонить коллегам. Все это съедает время, размывает ответственность между командами и мешает выпускать продукт быстро, качественно, в срок.

Чтобы решить проблему, мы решили внедрить в жизненный цикл разработки концепцию DoR (Definition of Ready) и DoD (Definition of Done). В этой статье я расскажу: чем DoR и DoD отличаются от критериев приемки и почему их важно не путать, как не превратить полезный инструмент в бюрократическую обязаловку, какие узкие места могут возникнуть при внедрении концепции.

Знакомая картина? Вечер воскресенья. Вы, вооружившись мотивацией после очередной статьи о продуктивности, открываете свой календарь и любовно раскрашиваете временные слоты с 8:00 до 22:00. Тетрис сошелся, мозг получает порцию дофамина от иллюзии контроля.

Но наступает утро понедельника. В 10:15 прилетает алерт: на проде отвалился важный сервис (или звонит запаниковавший клиент). Вы идете тушить пожар. Когда дым рассеивается, ваш идеальный график разрушен до основания, а вместо удовлетворения вас накрывает липкое чувство вины: «Я снова выбился из плана».

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

Недавно один мой приятель после релокации переехал из дома в квартиру. Места стало меньше — и в приглашении на день рождения дочери появилась фраза:
“No more physical toys.”

Не потому что он стал «строгим родителем».
А потому что складывать уже некуда, игрушек слишком много и каждая новая мгновенно обесценивает предыдущие.

В бизнесе мы ведём себя точно так же. Мы обожаем новые «игрушки»: