pro.project

Доставка товаров летающими дронами

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

Изменения в приложении для заказа

Разработка самого мобильного приложения для доставки, это позволит пользователям заказывать доставку с помощью воздушных дронов. Графический интерфейс его должен быть легким в использовании и интуитивно понятным. Пользователь должен иметь возможность не только вводить адрес доставки, но и выбирать точку в 3D-пространстве. Мы говорим не просто об обычной плоской карте, а о пространственном представлении, где любой человек сможет выбрать точное место перед своим окном. Это может выглядеть как виртуальная модель, где юзер может «перетаскивать» точку доставки, определяя также высоту в пространстве.

Крепление груза и контроль веса

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

Искусственный интеллект и выбор точки доставки

Также в системе должен использоваться AI в системе доставки это значительно улучшит пользовательский опыт. AI будет анализировать адреса пользователей и предлагать оптимальные варианты для доставки, также анализировать предыдущие доставки использую Big data. Если пользователь живет на высоком этаже, система предложит точки доставки рядом с окнами его квартиры, которые будут максимально удобны для получения груза. Кроме того, AI может помогать пользователю при выборе конкретной точки в 3D-пространстве, учитывая высоту.

Влияние на архитектуру зданий

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

Инновации в ресторанах и кафе

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

Визуальная концепция идеи FLY-through для дронов в ресторанах и кафе

Преимущества транспортировки летающими дронами

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

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

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

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

• Удобство для пользователей: Доставка прямо к вашему окну, удобно и экономит время, что дает вам возможность больше времени провести с семьей или работать. И дает возможность избежать лишних контактов, что особенно актуально в условиях пандемии.

В заключение

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

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

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

Эта методика не представлена в своде знаний IIBA – BABOK, она находится в технике Document Analysis.

Задача Reverse Engineering возникает всегда в контексте какой-то другой задачи. Бизнес не заинтересован в самом процессе RE, так как это может быть дорогостоящей операцией, требующей участия различных заинтересованных сторон и высокой квалификации самого бизнес-аналитика. При этом часто акцент делается именно на его hard skills. Поэтому прежде чем приступать к выполнению RE, важно четко определить границы этой задачи и ее цель.

Кейсы для Reverse Engineering

• Нужно уточнить требования для обеспечения поддержки текущего функционала.

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

• Запланирован проект по полному update-ту устаревшей системы.

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

• Необходимо разработать требования для миграции данных между двумя действующими системами.

• Требуется составить требования для интеграции уже имеющихся решений.

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

Все перечисленные задачи бизнес-аналитика объединяет одно ключевое свойство: для их успешного выполнения необходимо иметь актуальные системные требования (в идеале). Именно на основе достоверного и глубокого понимания существующей системы (As-Is) бизнес-аналитик сможет сформулировать новый набор требований.\

Источники информации для RE:

• Интервью с тех-специалистами. Это могут быть разработчики, тестировщики, а также сотрудники служба customer support.

• Если есть возможность самостоятельно поэкспериментировать нажимая на различные кнопки, это станет отличным источником как для описания, так и для проверки гипотез.

• Анализ данных системы (data driven decision) может существенно помочь в принятии решений.

• Детальное Изучение структуры данных.

• Анализ исходного кода (если он доступен).

• Интервью с заинтересованными сторонами из бизнеса, конечными пользователями и наблюдение за их взаимодействием с продуктом (парой это единственный доступный метод).

• Понимание специфики домена.

• Существующая документация (к сожалению ее часто нету, либо сильно устарела).

• Анализ Тикетов в Jira, Asana, Trello или других системах

Нужно помнить следующие

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

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

• Внимательно выбирайте уровень детализации. Причины те же, что и в предыдущем пункте.

• Не путайте, как система функционирует, и как она должна функционировать. Вы можете вести параллельный список изменений, который будет добавлен в backlog, но восстановленные требования должны быть зафиксированы в формате As Is.

• Тщательно определяйте объем исследования и следите за ним в процессе работы. Легко увлечься и застрять на незначительных деталях или уйти в сторону. Что считать «мелочью», зависит от критичности исходной задачи, которая и вызвала реконструкцию требований.

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

Давайте напоследок рассмотрим группы пользователей из BABOK и особенности общения с ними

End User. Они напрямую работают с решением и могут показать его полезность, но:

• Им может быть неинтересно обсуждать текущее состояние системы, так как это их рутина.

• Часто перескакивают на свои идеальные сценарии работы.

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

• Знают только свою часть процесса и могут путать факты с предположениями.

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

Operational Support. Эта группа может предоставить полезную информацию, так как собирает данные из тикетов, но:

• Часто не замечает свои ошибки, ассоциируя себя с системой.

• Знания о процессе могут быть поверхностными.

• Малоинициативны и неохотно идут на диалог.

• Как технические специалисты могут сильно углубляться в детали.

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

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

• Получает обобщенную информацию, что может приводить к устаревшим представлениям.

• Занят, поэтому к нему сложно добраться.

Customers. клиенты бизнеса, который пользуется решением

• Редко вовлечены и доступны для интервью.

• Могут неверно трактовать работу системы и показывать низкую заинтересованность.

• Имеют проблемы, схожие с конечными пользователями.

Regulator. На начальном этапе не очень полезны, но могут указать на ограничения, о которых другие не знают.

Supplier/Vendor. Используют уже готовые компоненты, предоставляемые третьими лицами. В этом случае они могут быть дополнительным источником информации по деталям реализации, но

• Редко идут на контакт и могут саботировать работу при отключении их решения.

• Могут отсутствовать из-за выхода их компании с рынка и других причин

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

- Кросс-проверка информации.

- Сверка с другими источниками.

- Использование техник "Наблюдение" и "Анализ документов"

Особенности сбора информации от Тех. Специалистов

Implementation Subject Matter Expert / Тестировщики. Эта группа стейкхолдеров может стать ценным источником сведений о процессе реализации, однако имеет свои нюансы. Технические специалисты, как правило, не погружаются в детали бизнеса. Они прекрасно понимают, как работает система, но зачастую не могут объяснить, зачем это необходимо. Это затрудняет их способность оценивать актуальность функционала. В их окружении часто утверждают, что определённая функция нужна: имеется документация, поддерживающая это мнение, существуют зависимые функции и поступают баг-репорты от пользователей как по самой функции, так и по смежным аспектам. Опираясь только на мнения этой группы, легко воспроизвести старое поведение системы с его недостатками, включая несоответствие реальным потребностям бизнеса.

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

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

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

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

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

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

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

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

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

• При применении так называемой «горизонтальной» декомпозиции, задачи делятся на основе типа выполняемых работ (функций) и используемых компонентов. В данном подходе большая задача разбивается на части, где разработчик получает одну долю обязанностей, тестировщик — другую, а технический писатель — третью, и так далее. Важно отметить, что каждая из этих частей не приводит к завершенному результату самостоятельно; для успешного выпуска готового функционала требуется совместная реализация всех взаимосвязанных задач всеми участниками процесса. Пример горизонтальной декомозиции из саб-тасков в 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? Не забудьте также поставить лайк посту — это вдохновляет меня на написание новых материалов! Спасибо за вашу поддержку!