Kanban для одного. Упрощай планирование вслед за японцами

Как работают над проектом

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

Scrum-команда разбивает время работы над проектом на равные отрезки — спринты. Спринт может длиться и день, и месяц, а в последние годы стандартом стал спринт в 2 недели.

Поскольку все спринты одинаковы по длительности, в работе команды появляется ритм. Ритм — важный аспект методологии.

Спринт состоит из четырех последовательных этапов.

  • Планирование. Команда проверяет задачи в бэклоге и выбирает самые приоритетные. На спринт берут столько задач, сколько успеют сделать.
  • Выполнение. В идеальной команде специалисты работают параллельно: пока программист создает код, тестировщик пишет к нему тесты, а технический писатель — документацию.
  • Релиз. Команда представляет результаты своей работы миру. К моменту каждого релиза продукт должен быть работоспособным, полезным для пользователя и более совершенным, чем до спринта. Больше про эти требования я написал в статье про Agile.
  • Ретроспектива. Команда обсуждает спринт и возникшие проблемы. Все вместе думают, как улучшить работу и сделать в следующем спринте больше.

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

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

По сравнению со Scrum-директивами Kanban — это оплот либерализма и хаос.

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

Вспомним этапы scrum-спринта:

  • Планирование.
  • Выполнение.
  • Релиз.
  • Ретроспектива.

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

Поскольку выраженных спринтов нет, появляются особенности:

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

Зачем?

У каждой из этих ролей свой запрос для планирования.

Руководителю проекта нужно дать ответ Заказчику, когда проект будет реализован.
Скрам-мастеру – помочь Владельцу продукта рассчитать (или, что чаще бывает, рассчитать за Владельца продукта и сообщить ему) время релиза.
Владельцу продукта – спланировать дату релиза и подготовить все необходимые мероприятия (маркетинг, продвижение, реклама, коммуникации и т.д.).
Бизнесу просто нужно знать, когда будет релиз

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

Команды в Kanban и Scrum

Основа обеих методологий — Agile, поэтому и в Scrum, и в Kanban работают небольшие автономные команды из 5—9 человек. В командах нет формального руководителя, и никто извне не диктует, как организовывать работу над продуктом.

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

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

А вот дальше в Kanban и Scrum начинаются различия.

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

При этом универсальные команды не запрещены.

В Kanban внутри команды нет ролей.

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

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

В scrum-команде помимо собственно специалистов есть две роли.

Scrum-мастер — человек, который организует работу. Это не управленческая должность, и он не раздает указания. Его задачи:

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

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

Владелец продукта — product owner — определяет ход проекта, он может представлять внешнего заказчика. Владелец знает все о рынке и целевой аудитории. Он ставит приоритеты задачам. Результат работы команда представляет владельцу продукта.

Виды

Тарный канбан

Представляет собой единицу тары с жёстко закреплённой канбан-биркой, со следующей информацией о содержимых деталях:

  • наименование;
  • артикул;
  • количество;
  • получатель;
  • отправитель.

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

Топовые статьи :  Как скачать видео из Facebook на любое устройство

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

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

Карточный канбан

Представляет собой карточку, имеющую:

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

Один из вариантов цветовой гаммы:

  • Синий — производственный канбан (между производственной линией и зоной выдачи);
  • Красный — складской канбан (между складом и зоной выдачи);
  • Зелёный — межцеховой канбан (между цехами, производствами, заводами и так далее).

Внедрение

Задача: оцифровать все, что происходит в департаменте, и объяснить команде правила игры.

Поскольку все проекты были связаны с чат-ботами, а их продолжительность была невелика, я принял решение не вести отдельный проект в Jira под каждый из них, а создать один проект под названием Chat Bots, в котором будут все проекты.

Мне необходимо было иметь стандартизированный процесс выполнения работ командой и общепринятые правила в разработке программного обеспечения. Первым делом я решил создавать минимальный процесс и настроить интерфейсы для работы команды. В глубине души я понимал, что ребята из команды Atlassian уже решили почти все мои боли, осталось только найти это решение и собрать все вместе, не нужно изобретать велосипед. Первым делом я пошел на официальные ресурсы Atlassian и почитал user guides по Jira и Tempo.

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

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

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

Вот так выглядела информация для принятия операционных решений вначале:

Проект Процент выполнения Комментарий
XXX 50% Блокер-клиент
YYY 70% Ждем интеграцию

Эта таблица не несла никакого смысла, кроме агрегирования всех проектов в одном месте. Процент выполнения проставлялся исключительно на калькуляциях и формулах в голове PM. Это очень субъективно и неправильно.

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

А так выглядела информация до внедрения Jira и после таблицы в Excel

Kanban для одного. Упрощай планирование вслед за японцами

Эта доска была промежуточным этапом между Excel и Jira и прожила около 3 недель. Через 2 недели после ее создания я попросил команду перенести все в Jira и дал на это неделю. Через неделю информация была стерта с доски, и те, кто не успел перенести, заполняли пробелы из своей головы. И так наступила эра цифровизации.

Предисловие

Задайте себе вопрос: по какой методологии или фреймворку мы ведем разработку программного обеспечения? Наверняка многие из вас ответят: Scrum. Это можно объяснить несколькими фактами:

  • Scrum у всех на слуху как в интернете, так и в офлайне. Kanban, Waterfall или другие подходы менее популярны.
  • Количество курсов по Scrum просто зашкаливает. Курсы не только об основах фреймворка, но и о разных ролях в нем, таких как Product Owner или Scrum Master. Их названия зачастую начинаются c «Как стать…», «Что делать…» или «Agile…». Зайдите, например, на scrum.ua, там о Kanban всего 2 курса.
  • Опрос среди аналитиков и проектных менеджеров в чате дал цифру в 34% в пользу Scrum. Опрос был проведен в апреле, тогда в чате было около 500 человек.

Kanban для одного. Упрощай планирование вслед за японцами

Убедил? А теперь задайте еще несколько вопросов себе или своему менеджеру:

  • Устраивает ли нас нынешний подход в разработке программного обеспечения?
  • Насколько эффективно работает наша команда? (О том, что я считаю эффективным, написано в другой моей статье.)
  • Выполняются ли поставленные задачи вовремя?

И так далее обо всем, что связано с метриками и процессами.

Давайте я немного расскажу о том, как я вижу картину мира, где есть 3 подхода в разработке software, и о том, для чего нужен каждый из них (мое скромное мнение):

  • Waterfall;
  • Scrum;
  • Kanban.

Конечно же, их больше, но пока что поговорим об этих.

Название Мое мнение
Waterfall

Видел и участвовал при внедрениях в госпроектах. Это были решения на разных платформах типа CRM, ERP от мощных поставщиков, таких как IBM, SAP, Microsoft.

Неприменим в текущих реалиях украинского IT-рынка и требований западных клиентов.

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

Уже давно не встречал.

Scrum

Лучшее применение находит в случае, когда есть команда или несколько команд, которые работают только над одним проектом.

Например, у вас есть 2 и более полноценные команды, один Project Manager и один проект.

Пример состава команд:

  • FE — 2 FTE;
  • BE — 2 FTE;
  • QA — 1 FTE;
  • BA — 1 FTE.

Повышения производительности можно достичь при масштабировании количества команд и накоплении доменной экспертизы. Основной принцип — итерационность.

Kanban

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

Приоритетом может служить дедлайн или негодование клиента.

Повышения производительности можно достичь увеличением пропускной способности сервиса (QA/BE/FE) или формированием скоупа для разработки с горизонтом 2–4 недели вперед.

Какие ограничения соблюдают

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

В Kanban число активных задач ограничено их весом по каждому статусу отдельно

При этом неважно, каков общий вес задач на доске.. Посмотрите на kanban-доску

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

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

Kanban для одного. Упрощай планирование вслед за японцами

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

Ограничение колонки «Разработка» — не больше трех задач. Сейчас колонка заполнена, поэтому программисты не могут взять новую работу из бэклога. Казалось бы, бред: задача решена, карточки в «Готовом» а специалисты простаивают.

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

Если разработчики возьмут новую работу, пробка станет еще плотнее. Вот почему в колонке «Разработка» ограничение для текущих и готовых задач общее.

Kanban предписывает, что в такой ситуации разработчики перемещаются к интеграторам и вместе с ними расчищают завал. Только когда в «Интеграции» появится место, разработчики протолкнут туда задачу из «Готово» и возьмут новую.

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

Настройка ограничений — важнейшая часть работы по Kanban.

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

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

Kanban предписывает экспериментировать. Поменяли ограничение на колонку — посмотрели, что получилось. И так все время.

Преимущества и недостатки канбан

Kanban имеет такие достоинства:

  1. Гибкость планирования. Команда концентрируется только на текущей работе, приоритет задачи выставляется менеджером.
  2. Высокое вовлечение команды в процесс разработки. Благодаря постоянным собраниям, прозрачности процессов и возможностям самоорганизации работники сплачиваются и проявляют искренний интерес.
  3. Меньшая продолжительность цикла. Если несколько человек обладает схожими навыками, продолжительность сокращается, если же только один — появляется узкое место. Поэтому сотрудники должны делиться знаниями и тем самым оптимизировать продолжительность цикла. Тогда вся команда сможет взяться за работу, которую забуксовала,и восстановить плавный поток.
  4. Меньше узких мест. Лимиты РВП позволяют быстро находить узкие и проблемные места, которые появились из-за дефицита внимания, людей или навыков.
  5. Наглядность. Когда все исполнители имеют доступ к данным, то узкие места легче заметить. Kanban-команды, помимо самих карточек, обычно используют два общих отчета: графики управления и совокупного потока.

На практике система отлично себя показывает в сферах неосновного производства:

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

Канбан имеет и недостатки:

  1. система плохо работает с командами численностью более 5 человек
  2. он не предназначен для долгосрочного планирования.

Происхождение

Как и концепция бережливого производства (Lean), система канбан была разработана менеджерами Toyota. Автора системы, японского инженера Тайити Оно, вдохновил принцип работы американских супермаркетов, где покупатель сам выбирал нужные себе товары. Роль «супермаркета» в корпорации Toyota выполнил склад.

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

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

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

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

Kanban для одного. Упрощай планирование вслед за японцами

А что насчет ограничений в других колонках?

Колонка «Готово» свободна от лимитов — чем больше работы сделано, тем лучше!

Есть ли смысл накладывать ограничения на колонку «В ожидании», где скапливаются задачи, к которым разработчик еще не приступал, и нужна ли она вообще? Ведь Agile-методологии подразумевают постоянное общение с заказчиком — новые задачи можно получать, когда завершена предыдущая.

И все-таки иметь небольшой «буфер» задач полезно. У них может быть разный приоритет и сложность

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

Но разработчик уже взялся за дизайн, и на Kanban-доске нет места для новой задачи.

Если бы обе задачи висели на доске в графе «В ожидании», разработчик взялся бы сначала за более важную, а незначительные, но объемные правки отложил на свободное время.

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

Как теперь планировать проекты и релизы в Agile?

Как вы уже догадались, для планирования в Agile нужно использовать оценку в условных единицах.

Вот мы оценили проект и поняли, что он, например, равен 150 условным единицам. Или это проект размера L. Что делать дальше?

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

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

Для наглядности используется график скорости команды. Или по-английский Velocity Chart (рис. 1).

Kanban для одного. Упрощай планирование вслед за японцамиРис. 1. График скорости работы команды (velocity chart).

Обладая статистикой скорости работы команды, вы можете просчитать примерное время выполнения проекта. Если команда выполняет 30 условных единиц за итерацию, а весь проект оценен командой в 150 условных единиц, следовательно для реализации проекта вам потребуется 5 итераций. Если длина ваших итераций 2 недели, получаем срок реализации проекта – 10 недель или два с половиной месяца.

Также для контроля выполнения проекта точно в срок в Agile используется диаграмма сгорания или Burndown Chart (рис. 2).

Kanban для одного. Упрощай планирование вслед за японцамиРис. 2. Диаграмма сгорания работ (burndown chart).

Она наглядно демонстрирует, как «сгорает» работа в проекте после каждой итерации.

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

Красиво? Не то слово. Удивительно? Еще бы. К сожалению, в таком подходе много «если». Он работает, если:

  1. В вашей команде есть все компетенции для реализации проекта.
  2. Вы и только распоряжаетесь ресурсами команды. Никто не может забрать у вас людей на другие проекты.
  3. В процессе работы у вас нет внешних блокировок, которые мешают реализации проекта.
  4. В процессе работы в вашем проекте не появляется новых дополнительных требований от Заказчиков. Вы и только вы контролируете объем проекта.
  5. Команда отлично знает среду проекта, поэтому на старте смогла достаточно точно оценить проект в условных единицах.

Если какое-нибудь из условий нарушается, происходит то, что знакомо любому руководителю проектов – «поехали сроки».

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

Стратегия внедрения системы

Стратегия внедрения предполагает осуществления 6 шагов:

  1. Обеспечение следующих процессов от поставок предыдущих процессов.
  2. Изготовление на предыдущих стадиях только того, что изъято для последующих.
  3. Обеспечение перемещения только качественных изделий без дефектов.
  4. Создание выровненного производства.
  5. Закрепление за каждой деталью канбана.
  6. Снижение со временем числа канбанов.

Все этапы внедрения можно разделить на 3 фазы:

№ 1. Планирование в рамках системы

  • Определяется число необходимых карточек.
  • Рассчитывается время такта, то есть, такого ритма, при соблюдении которого потребительский спрос удовлетворяется.
  • Высчитывается  количество операторов, которые нужны для каждого процесса, что достигается следующими действиями:
    • составляется карта процессов,
    • чертится график выполнения операций для каждого оператора,
    • выравнивается нагрузка на операторов.
  • Выравнивается производство в целом (хейд-зунка).

№ 2. Циркуляция канбанов

  • При поступлении деталей на линию сборки, карточки снимаются и перемещаются в стойку для хранения «карточек изъятия».
  • Сотрудник извлекает «карточку изъятия» и, согласно информации в ней, восполняет запас деталей для линии сборки.
  • Сотрудник извлекает «карточку производства» из ячейки и перемещает  в стойку для хранения  «карточки производства» текущего процесса. А «карточку изъятия» крепит к контейнеру с деталями, которые нужны для сборки. При этом сам контейнер снова транспортируется на линию сборки.
  • «Карточку производства» берут с контейнера и используют как рабочую инструкцию для изготовления изделий, изъятых для последующего процесса.
  • Пустые контейнеры перемещают в отстойник.
  • Обработанные детали комплектуются «карточками производства» и отвозятся в зону хранения. Из этой зоны рабочий с последующего участка должен их суметь взять в любой момент, поэтому зона располагается близко от линии.
  • «Карточки изъятия» перемещаются на предыдущую стадию для восполнения количества необходимых узлов.

№ 3. Усовершенствование производства

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

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

Почему я не выбрал Scrum?

Ответ для меня показался очевидным из-за разношерстности проектов, их дедлайнов и неопределенности. Основная неопределенность была в том, что я мог подписать проект продолжительностью 3 недели, который надо начинать делать уже сегодня, потому что клиент подвязан под публичное событие (например, фестиваль или рекламу на ТВ/YouTube). Такого рода задачи подразумевают гибкость в планировании и реализации.

Scrum подразумевает четкую итеративность и фиксированную функциональность в итерации. К сожалению, я не мог и пока не могу так делать — как минимум из-за небольшой продолжительности проектов (1–3 месяца) и, конечно же, из-за отсутствия возможности выделить отдельную команду под каждый проект.

Как составляют список задач

Для начала команда берет проект и делит его на десятки, а то и сотни задач поменьше. Это часть философии Agile, поэтому так делают и в Kanban, и в Scrum.

Все задачи проекта, которые предстоит выполнить, складывают в общий список — бэклог. Бэклог — это банк задач проекта. Каждая задача должна быть актуальна. Если потребуется, их можно добавлять в бэклог или удалять из него «на лету».

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

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

Оцените статью
Добавить комментарий