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

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

В такой ситуации, если у нас есть запас декомпозированных требований, это даёт следующие преимущества:

• Во-первых, мы не ограничиваем себя в выборе задач для спринта (можем работать только с теми задачами, которые уже декомпозированы).

• Во-вторых, во время планирования не нужно тратить время на разбивку, и команда может сосредоточиться на формировании спринта с учётом всех приоритетов, обсудить зависимости и детали реализации требований.

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

Два основных подхода к декомпозиции.

Существует два базовых подхода к декомпозиции крупных задач на пользовательские истории — «горизонтальное» и «вертикальное» разбиение:

• При применении так называемой «горизонтальной» декомпозиции, задачи делятся на основе типа выполняемых работ (функций) и используемых компонентов. В данном подходе большая задача разбивается на части, где разработчик получает одну долю обязанностей, тестировщик — другую, а технический писатель — третью, и так далее. Важно отметить, что каждая из этих частей не приводит к завершенному результату самостоятельно; для успешного выпуска готового функционала требуется совместная реализация всех взаимосвязанных задач всеми участниками процесса. Пример горизонтальной декомозиции из саб-тасков в Jira:

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

Разбиение задач с использованием «вертикального» метода больше соответствует Agile принципам и его применение гораздо более эффективным, основные причины в следующем:

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

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

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

Техники декомпозиции требований

Способ 1: Этапное разбиение бизнес-процессов

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

• Вход в личный кабинет

• Просмотр товаров в «корзине»

• Формирование счета

• Отправка счета на почту

• Оплата различными способами: банковская карта, перевод и т.д. Каждый из этих этапов можно оформить как отдельную пользовательскую историю. Таким образом, мы разбиваем обширный бизнес-процесс на составные части, что позволяет определить приоритеты и лучше понять процесс в целом, включая возможные зависимости между этапами.

Способ 2: Разделение на позитивные и негативные сценарии

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

• Позитивный сценарий: пользователь авторизуется и успешно совершает покупку.

• Негативный сценарий 1: попытка покупки без авторизации.

• Негативный сценарий 2: недостаточно средств на счете для завершения транзакции.

• Негативный сценарий 3: блокировка учетной записи после нескольких неверных попыток ввода пароля.

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

Способ 3: Разбиение по правилам и условиям

В отличие от предыдущего метода, здесь акцент делается не на этапах, а на логических ветках процесса, основанных на различных правилах. Например, для функции покупки можно выделить правила, такие как:

• Минимальная сумма покупки.

• Дополнительные варианты оплаты при превышении определенной суммы.

• Автоматическая отмена заказа через 2 дня без оплаты.

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

Способ 4: Разделение по типам операций

Многим функциональным требованиям соответствуют стандартные операции, такие как создание, чтение, обновление и удаление (CRUD). Например, для управления карточкой товара в интернет-магазине можно выделить:

• Create: добавление нового продукта.

• Read: просмотр описания продукта.

• Update: редактирование информации о продукте.

• Delete: удаление товара из магазина.

Такое разбиение позволяет четко определить необходимые операции и их приоритеты.

Способ 5: Декомпозиция по платформам и ОС

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

• Персональные компьютеры

• Планшеты

• Смартфоны

• Разные операционные системы: Windows, iOS, Android.

Такой подход помогает определить приоритетные направления разработки.

Способ 6: Разделение по типам данных и параметрам

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

• Поиск по наименованию товара.

• Поиск по номеру товара.

• Поиск с использованием регулярных выражений.

Эта декомпозиция позволяет четко определить допустимые параметры и легко управлять требованиями.

Способ 7: Разделение по ролям и правам доступа

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

• Владелец: создание и удаление товаров.

• Администратор: редактирование описаний и работа с клиентами.

• Клиент: просмотр и покупка товаров.

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

Способ 8: Декомпозиция по тестовым сценариям

Этот метод разбивает функциональность на основе тест-кейсов, которые необходимо проверить для проверки успешности работы функций. Например, для функции добавления товара в «корзину» могут быть выделены следующие тестовые сценарии:

• Товар доступен для покупки.

• Товар зарезервирован другим пользователем.

• Товара нет в наличии.

Такой подход позволяет объединить различные техники декомпозиции и формирует ясные задачи для разработки и тестирования.

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

Преимущества Декомпозиции задач:

• Улучшает понимание: Разделение крупных задач (или историй пользователей) на более мелкие позволяет команде лучше понять, что именно требуется сделать. Мелкие задачи легче осмысливать и обсуждать.

• Лучшая оценка: Команда может более точно оценить время и усилия, необходимые для выполнения мелких задач, что улучшает планирование и управление ресурсами (Гарантирует отличный Митинг Планирования используется числами Фибоначчи или последовательность T-Shirt Sizes ).

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

• Увеличение прозрачности: Когда задачи разбиты на более мелкие части, становится легче отслеживать прогресс и выявлять проблемы на ранних этапах. Это позволяет команде быстро реагировать на изменения.

• Повышение гибкости: В Scrum часто происходят изменения в требованиях, и декомпозиция задач позволяет команде более гибко реагировать на эти изменения, адаптируя свои планы и приоритеты.

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

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

• Постепенная интеграция: Разделение задач на более мелкие части позволяет команде поэтапно интегрировать и тестировать функциональность, что уменьшает риски и улучшает стабильность.

Я надеюсь, что данная информация вам пригодилась! Если у вас есть вопросы или пожелания, оставляйте комментарии. Буду рад помочь вам с личными советами по IT, бизнес-анализу, Scrum или управлению проектами!

Приветствую вас, коллеги и соратники в мире управления проектами! При разработки программного обеспечения существует множество подходов, методологий к управлению IT проектами. Среди них топ места занимают Scrum и Kanban. Сегодня освежим наши знания об этих двух методах, и принципах их применении.

Скрам: Кратко о главном

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

Основные элементы Скрам:

Роли:

• Product Owner: отвечает за создание и приоритизацию бэклога продукта.

• Scrum master: помогает всей команде следовать процессам скрам и устраняет препятствия, которые могут мешать работе.

• Developers: группа специалистов, которые выполняют работу по созданию продукта.

Артефакты:

• Бэклог продукта: список всех задач и требований, которые должны быть выполнены.

• Бэклог спринта: задачи, выбранные для выполнения в текущем спринте.

• Инкремент: завершенная работа за спринт, которая добавляет ценность продукту.

События:

• Спринт: имеет фиксированный период (обычно 2-4 недели), в течение которого команда работает над задачами.

• Планирование спринта: встреча для определения задач, которые будут взяты в работу и выполнены входе спринта командой.

• Ежедневный стендап(daily-ки): короткие ежедневные встречи для обсуждения прогресса и препятствий.

• Обзор спринта: встреча для демонстрации завершенной работы(демо) заинтересованным сторонам.

• Ретроспектива: встреча для анализа прошедшего спринта и выявления возможностей для их улучшения.

Канбан: Кратко о главном

Канбан — это метод управления процессами, который акцентирует внимание на визуализации работы, ограничении незавершенных задач и постоянном улучшении. Это одна из методологий по управления проектами из семейства Agile.

Основные элементы Канбана:

Визуализация вашей работы:

• Использование доски Kanban, на которой отображаются задачи в виде карточек, перемещающихся по колонкам доски, имеющие различные стадии/статусы (к примеру, "Todo", "In progress", "In QA", "In review", "Done").

Ограничение незавершенной работы(WIP):

• Установка лимитов на количество задач(WIP лимитов), которые могут находиться в каждой колонке одновременно, чтобы предотвратить перегрузку команды и улучшить поток работы.

Постоянное улучшение:

• Регулярный мониторинг и оптимизация процессов, использование метрик для оценки производительности, результатов и выявления узких мест, горлышек.

Давайте сравним Scrum и Kanban по различным атрибутам, чтобы знать основные отличия, между этими методами управления (помним, скрам — это фреймворк, а канбан — метод организации и управления задачами). Таблица ниже показывает разницу между Scrum и Kanban.

Разница между Скрамом и Канбаном: Памятка для менеджеров проектов

1. Work cycle

Scrum: Итерации. Scrum включает спринты, в течение которых команда следует циклу plan-do-check-act (PDCA).

Kanban: Continuous flow. В Канбан, как только одна задача завершается, команда сразу берется за следующую.

2. WIP - Work In Progress

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

Kanban: WIP лимиты в Канбан означает количество задач, которые могут одновременно находиться в одной колонке в течение заданного промежутка времени на конкретном этапе работы.

3. Inspect-Adapt (Empiricism)

Scrum: Каждый спринт — это возможность для инспекции и адаптации.

Kanban: Нет конкретного механизма для инспекции и адаптации. Работа движется в одном направлении.

4. Transparency (Empiricism)

Scrum: Артефакты в Scrum включают product backlog, sprint backlog и increment. Соответственно обеспечить прозрачность требований, реализации и результатов.

Kanban: Никаких специфических артефактов для прозрачности. Канбан-доска обеспечивает некоторую прозрачность. Многие команды используют бэклог продукта (из Scrum) в сочетании с досками канбана.

5. Planning

Scrum: Конкретный митинг для планирования спринта и дня — sprint planning и daily scrum.

Kanban: Нет четких указаний по планированию работы. Команды самостоятельно выбирают свой ритм и подход к планированию.

6. Responsibility/Structure

Scrum: Ответственность в Scrum - владелец продукта фокусируется на бизнесе, разработчики на реализации и Scrum мастер на устранении препятствий и имплементации Скрам. Вся работа выполняется кросс-функциональной командой.

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

7. Stakeholder/Customer

Scrum: Скрам предполагает активное участие заинтересованных сторон и клиента — по крайней мере, один раз за спринт во время мероприятия sprint review(демо).

Kanban: Канбан не дает возможности привлечь заинтересованные стороны или клиентов. Некоторые команды применяют подход “обзора проделанной работы” раз в месяц.

8. Daily meetings

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

Kanban: Daily в канбане — стендап не является частью практик Канбана, но все равно можно проводить эту встречу. Стендап можно считать одним из способов реализации принципа improve continuously. Вопросы на них лучше задавать с фокусом на задачи.

9. Поток работы

Scrum: Скрам использует фиксированные временные рамки, называемые спринтами, которые обычно длятся от одной до четырех недель. Это позволяет командам "пушить" заранее запланированные задачи в рамках каждого спринта.

Kanban: Канбан основан на принципе "пул", что означает, что работа вытаскивается из очереди по мере необходимости. Это позволяет командам адаптироваться к изменяющимся требованиям и приоритетам, так как новая задача берется только тогда, когда есть свободный ресурс.

10. Метрики

Scrum: Основные метрики, которые применяются в скраме: Velocity (Скорость), Burndown Chart (График сгорания), Sprint Goal Achievement (Достижение цели спринта), Release Burndown.

Kanban: Основные метрики, которые применяются в канбане: Lead Time (Время производства), Cycle Time (Цикловое время), Throughput (Производительность), Work In Progress (WIP).

11. Оценка и приоритизация

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

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

12. Изменения в ходе работы

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

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

Kanban: В методологии Kanban всё гораздо проще — изменения могут быть внесены в любое время. Если бизнес решает, что необходимо срочно приступить к выполнению задачи, это не требует долгих процессов перепланировки (работу можно начать буквально через несколько минут). Однако здесь также существуют свои сложности, например, возможные блокировки задач, которые уже находятся в работе, и снижение производительности разработчика из-за необходимости переключаться на новую задачу. О том, как с этим справляться, я постараюсь рассказать отдельно.

13. Начала работ над тасками

Scrum: Скрам строится на основе спринтов, ограниченных во времени. Работа начинается только после того, как задачи будут расставлены по приоритету и оценены, проработаны ac, после чего они попадают в список спринта (Sprint Backlog). Обычно это происходит с регулярностью, соответствующей итерациям, что подразумевает ожидание включения конкретной задачи в ближайший спринт (хотя это не всегда происходит быстро).

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

14. Проведение демо

Scrum: Demo проводится в конце спринта и является частью Sprint Review. На этом митинге команда демонстрирует завершенные элементы работы (например, функционал, который был разработан за спринт) заинтересованным сторонам, включая владельца продукта. А также в получении ОС по проделанной работе.

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

Поэтому демо-сессии можно проводить, как на регулярной основе (например, раз в определенный период) или после завершения значительных задач.

Напоследок пару слов о СкрамБане

Скрам-бан — это гибридная методология, объединяющая элементы, как Scrum так и Kanban, которая предназначена для управления проектами и улучшения процессов разработки.

Основные характеристики Скрам-бан:

• Гибкость: Скрам-бан сохраняет гибкость, позволяя командам вносить изменения в процессе работы, что особенно важно в динамичных условиях.

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

• Поток работ: Скрам-бан фокусируется на оптимизации потока работ, уменьшая время выполнения задач и повышая эффективность команды.

• Непрерывное улучшение: Команды регулярно анализируют свои процессы и ищут способы их улучшения, что способствует росту и развитию.

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

Напишите в комментариях, что вы чаще используете в своих проектах — Scrum или Kanban? Не забудьте также поставить лайк посту — это вдохновляет меня на написание новых материалов! Спасибо за вашу поддержку!

Летом 25 года я решил координально сменить сферу. Думал на стройку, но образование не позволило быть там сразу управляющим.
Решено было получить доп. образование и уйти в Айти, в котором я шарю на уровне пользователя. Тем более ни глубоких знаний программирования, и в целом физмата там не требуется. Выбрал, понравилось, отучился.
Начал искать стартовые позиции, на набор боевого опыта. Нашел, отстажировался, но вакансия не подразумевала переход в штат.
Ищу дальше уже 2 недели.
Приходит 23.02, в выходной день, в 7 утра в телегу "нашла вас на сайте Охотник за головами, вот ссылка на нашу вакансию, очень хочу созвона".
Открыл, почитал, денежки указаны неплохие, есть над чем задуматься.
Но название должности "Бизнес ассистент/опер менеджер/проджект менеджер" создает желание спросить, что все таки ищет работодатель.
Функционал - от общения со стейкхолдерами, до "ты тень рук-ля, должен угадывать его желания". Думаю, ну ладно, может интересное предложение.
Назначили время, приготовился, за 5 минут, закрыл все дела, а ссылки нет и нет, сижу жду.
За 1 минуту до времени созвона кидает сайт и : "прошу ознакомиться до встречи".
Кликнул по ссылке - не открывается без впн, дальше не стал заходить. Сомнительно, все таки. Присылает ссылку, захожу.
Девушка, лет 20, неплохой внешности и приятной манерой подачи речи, начинает проверку связи, представляется, и просит включить запись.

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

Далее начинается заученный рассказ о компании, которая к слову занимается не софт разработкой, как указано в описании, а это крипто обменник. Предвкушая, что оформление на ИП или самозанятость, оплата в крипте или в листочках с дерева, нет ни ДМС, ни техники, я понял что трачу время (опыт уже был в собесах ранее).

Я - "Татьяна, скажите, а вы прежде чем со мной встречаться, читали мое резюме? Я Менеджер проекта, ищу работу Проджект менеджером. У вас в описании прямые обязанности проджект менеджера, но плюс еще системного аналитика, прОдукт менеджера, личного помощника и т.д."

Д - "Давайте я включу запись, вы расскажете про опыт и мы поймем, что вы нам подходите или нет"

Я - "Вроде же обсудили про запись, давайте сначала обсудим мои вопросы..."

Я не успел закончить фразу, и тут иконка загрузки, и : "Организатор завершил конференцию"...

Захожу в ТГ, ни ответа ни привета, просто молчание.

Такое у меня в первый раз.

— Хватит, — сказал он, — низкопоклонства перед Западом. Мы русские люди. Какой еще, к лешему, «Скрам»? Какое «Велью»? С понедельника живем по правде.

Так в нашем опенспейсе наступило средневековье.

В понедельник мы собрались на PI-планирование. Теперь это называлось «Великий Сход». Атмосфера была тревожная. Программисты, люди по природе своей циничные и ленивые, жались к стенам.

В центр зала вышел наш Release Train Engineer, Аркадий. Раньше он носил худи с логотипом React, теперь на нем была льняная рубаха, правда, поверх джинсов. Глаза его горели нездоровым огнем.

— Братья! — возопил Аркадий. — Гой еси, мастеровые! Собрались мы ныне, дабы снарядить Обоз Поставки в путь долгий, на квартал грядущий!

Рядом со мной стоял Леха, наш тимлид. Леха — человек мрачный, его жизненная философия сводится к трем аксиомам: сервер упадет, заказчик идиот, а пиво должно быть холодным.

— Староста, — поправил я его шепотом. — Ты теперь не тимлид, а Староста Артели «Бэкенд».

— Я идиот, — буркнул Леха. — А Аркаша — Голова Обоза. Звучит как диагноз.

Началось все с «Оглашения Замысла». Вышли Попечители (бывшие стейкхолдеры) и полчаса рассказывали, как важно нам захватить рынок доставки собачьего корма. Потом слово взял Град-Зодчий (в девичестве — Enterprise Architect). Он развернул схему микросервисов, похожую на карту взятия Казани, и велел строить хоромы каменные, чтоб на века.

Нас разгнали по углам — на «Артельные Посиделки».

— Так, — сказал Леха, глядя в джиру. — У нас тут Затея висит. «Интеграция с платежным шлюзом». Как оценивать будем?

— В стори-поинтах нельзя, — напомнил я. — Соловейчик велел в Вершках. Или в Пядях.

— Хорошо, — Леха почесал затылок. — Тут работы много. API кривое, документации нет. Потянет на семь пядей во лбу.

— Много, — возразил тестировщик Гриша. — Не сдюжим. У нас Тяга слабая, половина артели в отпусках.

— Ладно, пиши пять вершков. И пусть Господь управит.

Самое страшное началось у Доски Пути. Это была огромная пробка на стене, вся опутанная красными нитками. Аркадий бегал вдоль нее, спотыкаясь о провода, и кричал:

— Чьи Путы?! Кто кого держит? Почему Артель «Фронтенд» не может начать верстать кнопку?

— Дык, — отозвался с галерки фронтендер, — мы ждем, пока бэкендеры базу окучат.

— Путы! — трагически воскликнул Голова Обоза. — Тугие, окаянные путы! Староста Леха, пошто задерживаешь братьев своих?

Леха молчал. Ему хотелось курить и, возможно, убить Аркадия.

К вечеру перешли к «Укрощению Лиха». Это был ритуал ROAM, только с национальным колоритом.

— Лихо первое! — зачитывал Аркадий. — «Сервер падает при нагрузке в тысячу юзеров». Кто возьмет на душу?

— Я возьму, — вздохнул Град-Зодчий. — Буду Опекуном сего Лиха.

— Добро! Лихо второе! «Дизайнер уходит в декрет».

— Тут мы бессильны, — сказали из зала.

— Значит, — Аркадий развел руками, — на все воля Божья. Принимаем как есть. Accepted. То есть, тьфу, «Смирение».

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

Я посмотрел на Леху. Леха смотрел в пол. Он знал, что API не заработает, что сроки сгорят, а Соловейчик через месяц передумает и увлечется буддизмом. Леха хотел показать один палец. Возможно, средний.

Но он был Старостой. У него была ипотека и двое детей.

— Голосуем! — взревел Голова Обоза.

В воздух взмыли десятки рук. Все показывали открытую ладонь. Пять перстов. Полная вера. Зуб даем, всё исполним.

— Любо! — прослезился Аркадий. — Сдюжим, православные! Трогай Обоз!

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

— Пять вершков, — задумчиво сказал Леха, глядя на огонек сигареты. — А ведь не сдюжим.

— Не сдюжим, — согласился я. — Зато как звучит! Не факап, а «Лихо». Не баг, а «Испытание». Чувствуешь величие?

— Чувствую, — сказал он. — Пойдем, Радетель. Нам еще код писать. Или, как теперь говорят, бересту марать.

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

Толковый словарь урядства и благочиния в разработке программных изделий

Раздел I. О Людях и Чинах

• Agile Team — Артель.

  Боевая единица производства. Группа людей, объединенных общей бедой и сроками. Живут в одной избе (или чате), делят радости и баги.

• Scrum Master — Староста.

  Человек, который не пашет, не сеет, а только спрашивает: «Что ты делал вчера, мил человек, и что будешь делать сегодня?». Следит, чтобы в Артели не пили медовуху до релиза.

• Product Owner — Радетель (Хозяин изделия).

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

• Release Train Engineer (RTE) — Голова Обоза.

  Главный погонщик. Человек с самым громким голосом и самыми расшатанными нервами. Отвечает за то, чтобы все телеги ехали в одну сторону, даже если лошади сдохли.

• System Architect — Главный Зодчий.

  Старец, рисующий на бересте красивые схемы, которые невозможно воплотить в жизнь. Живет в башне из слоновой кости (или в отдельном кабинете).

• Developers — Мастеровые.

  Трудовая кость. Люди, которые своими руками превращают безумные фантазии Радетелей в работающий (иногда) код.

Раздел II. О Деяниях и Обрядах

• PI Planning — Великий Сход.

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

• Team Breakouts — Артельные Посиделки.

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

• Confidence Vote — Пятерня Веры (Рукоприкладство).

  Обряд всеобщего поручительства. Поднятая рука с пятью пальцами означает: «Зуб даю, сделаем». Один палец (особенно средний) показывать не рекомендуется во избежание гнева Попечителей.

• ROAM — Укрощение Лиха.

  Ритуал заговаривания проблем. Делится на четыре вида заклинаний:

  1. Избыто (R) — проблему решили (спрятали под ковер).

  2. Взято на душу (O) — нашли крайнего.

  3. На всё воля Божья (A) — смирились с неизбежным крахом.

  4. Соломка подстелена (M) — придумали оправдание заранее.

Раздел III. О Мерах и Вещах

• Feature — Затея.

  Крупная хотелка Попечителей. Обычно формулируется как «Хочу, чтоб было красиво и само работало».

• User Story — Поделка.

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

• Story Points — Вершки (или Пяди).

  Мера сложности, понятная только самим Мастеровым. Один вершок — работа легкая. Восемь вершков — без пол-литры не разобраться.

• Dependency — Путы.

  То, что мешает жить. Красные нити на Скрижали Пути, символизирующие, что одна Артель ждет, пока другая перестанет лениться.

• Capacity — Тяга.

  Сила лошадиная. Способность Артели тащить воз. Обычно переоценивается в два раза в начале пути и недооценивается в конце.

• Program Board — Скрижаль Пути.

  Доска позора и надежды. На ней видно, кто работает, а кто создает Путы.

Другие подобные рассказы можно прочитать тут https://dovlatov-ai.web.app/

Строительство: много материальных затрат на этапе производства

В строительстве классическое распределение затрат выглядит так:

• Проектирование: 5-10% от общей стоимости

• Материалы: 50-60%

• Строительно-монтажные работы: 30-40%

• Пуско-наладка и сдача: 5-10%

Физическая реальность создает "точку невозврата". После заливки фундамента изменить его параметры практически невозможно без полного демонтажа. Каждый этап жестко зависит от предыдущего, и ошибка на ранней стадии многократно усиливается на последующих. Тиражирование в строительстве означает создание типовых проектов, но даже при этом каждый объект уникален из-за особенностей грунта, климатических условий и инфраструктуры.

Машиностроение: баланс между разработкой и производством

Машиностроение занимает промежуточное положение:

• НИОКР и проектирование: 20-30%

• Создание прототипов и испытания: 15-25%

• Освоение производства (оснастка, станки, линии): 30-40%

• Серийное производство: 10-20% на единицу продукции

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

IT-разработка: "бесплатное" тиражирование

В IT-разработке принципиально иное распределение:

• Проектирование и анализ: 30-40%

• Разработка: 40-50%

• Тестирование и внедрение: 20-30%

• Поддержка и развитие: 15-25% годовых от стоимости разработки

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

Почему в IT можно начинать с весьма "сырого" продукта?

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

В строительстве аналогичная ситуация. Фундамент гаража не выдержит нагрузки от многоэтажного дома. Стены сарая не станут несущими для башни. Физические законы не обойти.

Но в IT физических ограничений нет. Вы можете начать с простого веб-сайта-одностраничника, добавить базу данных и админку (MVP), интегрировать платежные системы и мобильное приложение (первая версия приложения), а затем создать распределенную облачную платформу с искусственным интеллектом. Каждый этап строится на предыдущем, но при необходимости можно переписывать отдельные компоненты полностью без полного перезапуска проекта.

Это возможно благодаря:

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

2. Модульной архитектуре - компоненты можно заменять независимо друг от друга

3. Быстрому циклу обратной связи - пользователи тестируют изменения в реальном времени

Стоимостные риски и их управление

Строительство: страхование через детализацию

В строительстве основной риск — физическая невозможность или чрезвычайная стоимость исправления ошибок. Поэтому:

• 80-90% рисков управляются на этапе проектирования

• Используются детальные 3D-модели и BIM-технологии

• Предусматриваются запасы прочности в конструкциях

• Стоимость изменений после начала строительства кратно превышает стоимость проектирования

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

Машиностроение: управление через прототипирование

В машиностроении риски распределены между разработкой и производством:

• Создаются физические прототипы для проверки концепций

• Проводятся ресурсные испытания в экстремальных условиях

• Используются CAD/CAM системы для виртуального моделирования

• Освоение производства идет поэтапно с постоянной доработкой

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

Разработка ПО: управление через итерации

В программировании и разработке ПО риски управляются иначе:

• Риск несоответствия требованиям минимизируется через постоянную обратную связь

• Технические риски снижаются через рефакторинг и технический долг

• Рыночные риски управляются через A/B тестирование и постепенный rollout

• Безопасность обеспечивается через непрерывное тестирование и обновления

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

Практические примеры от нейросети Qwen

Строительство: Burj Khalifa
Стоимость проектирования составила около $100 млн из общего бюджета $1.5 млрд. Изменения в процессе строительства были минимальны — любое отклонение от проекта могло привести к катастрофе. Тиражирование невозможно — это уникальный объект.

Машиностроение: Tesla Model 3
Разработка и освоение производства обошлись в $2+ млрд. Но при производстве 500,000 автомобилей в год себестоимость единицы становится конкурентоспособной. Изменения в процессе производства требуют остановки линий и перенастройки оборудования.

IT разработка: Facebook
Начинался как простой сайт для студентов Гарварда. Стоимость тиражирования для миллиарда пользователей — доли цента на пользователя в месяц. Изменения вносятся ежедневно без остановки сервиса. Первоначальная разработка стоила тысяч долларов, текущая стоимость компании — сотни миллиардов.

Почему аналогии вредны в проектном управлении и как найти баланс

Следовательно сравнение разработки ПО со строительством некорректно именно из-за разного распределения затрат. Поэтому проектное управление в разработке ПО просто обязано опираться прежде всего на итерации и сбор обратной связи, а не на исходное ТЗ и проектные документы.

практические советы для IT проектов:

1. Архитектурный фундамент - закладывайте понятную архитектуру с возможностью масштабирования, но не надо сразу ударяться в создание микросервисов и прочие архитектурные излишества https://t.me/limsaccreditation/1857

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

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

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

Вывод

Итерации и необходимость обратной связи в it сфере обусловлены фундаментальными причинами, связанными со стоимостью этапов проектирования и разработки. Без итеративного подхода можно впустую прожигать бюджет на никому не нужное проектирование и дальнейшую разработку продукта, которым никто не будет пользоваться.
Как написали в комментариях к мой предыдущей статье, сам Уинстон Ройс — автор термина Waterfall — в той самой статье 1970 года описывал недостатки каскадной модели, предлагая заменить их итеративной моделью. Таким образом дело не в Agile и настроениях разработчиков, итерации - это самая эффективная модель разработки с экономической точки зрения.