Фреймворк что это в эджайл
1.4 ФРЕЙМВОРКИ AGILE
Scrum, по определению его создателей, это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески создавать для клиентов продукты с максимально возможной ценностью. Scrum компактен и прост для понимания, но достаточно трудно овладеть им в совершенстве.
Нужно также учитывать следующие особенности:
Scrum, по определению его создателей, это фреймворк, который помогает решать изменяющиеся в процессе работы задачи, чтобы продуктивно и творчески создавать для клиентов продукты с максимально возможной ценностью. Scrum компактен и прост для понимания, но достаточно трудно овладеть им в совершенстве.
Нужно также учитывать следующие особенности:
Kanban, согласно одному из определений, это «популярный подход к реализации Agile-разработки ПО. Он предполагает обсуждение производительности в режиме реального времени и полную прозрачность рабочих процессов. Этапы работы визуально представлены на Kanban-доске, что позволяет членам команды видеть состояние каждой задачи в любой момент времени». Kanban обеспечивает прозрачность, понимание и вовлеченность членов команды, регулярную коммуникацию и обратную связь. Этот подход хорошо работает и приживается в организации независимо от корпоративной культуры, его можно использовать не только в проектных командах, но и для визуализации процесса работы с однородными процессными задачами. Данный подход может быть использован для наглядной демонстрации изменений и быстрых побед.
Кроме того, существует ряд фреймворков, связанных с масштабированием Agile-подходов, например в крупных компаниях или применительно к объемным проектам. На Западе они применяются несколько реже, чем основные Agile-подходы, а в РФ — значительно реже. На момент написания данного документа (май 2019 г.) практик внедрения данных фреймворков в российском госуправлении не было (но есть практики внедрений в крупных государственных и «около-государственных» компаниях, например в Центробанке, Сбербанке, «Газпромнефти»). Поскольку есть вероятность, что со временем такие практики появятся, мы кратко упоминаем об этих фреймворках. К наиболее известным фреймворкам такого плана относятся:
• Scaled Agile Framework (SAFe) — гибкий фреймворк для разработки продуктов для конечных клиентов, позволяющий использовать Agile-подходы в больших командах численностью более 50 человек. Уже существует SAFe for government — фреймворк SAFe, адаптированный именно для госуправления (западного).
Фреймворки для управления проектами
A. Что такое фреймворк для управления проектами?
Фреймворк для управления проектами — это набор инструментов, задач и процессов, используемых для организации и выполнения проекта от начала и до завершения. Фреймворк описывает все, что вам нужно для успешного планирования ваших проектов, контроля и управления ими.
Стандартный фреймворк для управления проектами можно разбить на три большие части:
Фреймворк Agile скорее всего будет использовать модифицированный жизненный цикл, лучше отражающий гибкую и итеративную природу Agile-методологии.
Цель фреймворка для управления проектами состоит в том, чтобы дать четкое и последовательное описание проекта, которое обеспечит надежное и повторяемое выполнение проектов разными командами и компаниями. Фреймоворки документируют и предоставляют в общий доступ лучшие рекомендации, и это выгодно всем. Также они помогают создавать единые стандарты в организациях и целых отраслях.
Руководство PMBOK описывает фреймворк как базовую структуру для понимания сути управления проектами. Менеджеры проектов выбирают фреймворк, который больше всего подходит для их проекта или команды. Мы объясним, как выбрать соответствующий фреймворк для проекта в разделе Е.
В чем разница между методологией и фреймворком?
Методология описывает принципы управления проектами, ценности и лучшие рекомендации, которые нужно соблюдать, в то время как фреймворк показывает способ соблюдения. Другими словами, методология объясняет вам, чего вы ходите добиться, а для фреймворка важно, как вы этого добьетесь.
Например, принципы Lean и Agile гласят, что жизненно необходимо реагировать на изменения. Но эти методологии не объясняют, как сделать так, чтобы ваши проекты хорошо реагировали на изменения — такая информация изложена во фреймворке.
Б. Что общего у Agile-фреймоворков?
Agile-методология управления проектами — это подход к управлению проектами, использующий четыре главных ценности и 12 принципов организации проектов. Agile-фреймворки разработаны для поддержки этих ценностей и принципов.
Agile-процесс отличается от остальных подходов к управлению проектами, так как нацелен на итеративную разработку, гибкость, постоянную обратную связь и убеждение, что люди важнее процессов. Поэтому Agile-фреймворки должны строиться на основе этих базовых ценностей.
Хотя у каждого фреймворка есть свои уникальные аспекты, каждый из них помогает вам следовать основам управления проектами, чтобы довести проект до победного конца. Agile-фреймворки считаются более простыми в сравнении с традиционными фреймворками, поскольку сводят к минимуму объемы правил и документации. Но каждый Agile-фреймоворк должен включать в себя все важнейшие процессы и этапы проекта.
В. Фреймворк Scrum
Методология Scrum была разработана в 1990-х гг., и ее основы были изложены в статье в Harvard Business Review под названием «Разработка нового продукта. Новые правила игры». Большинство менеджеров проектов считают Scrum самым популярным Agile-фреймворком.
Как и в случае других Agile-фреймворков, Scrum использует итеративный подход к управлению проектами. Методология Scrum предписывает разбить проект на спринты длительностью от одной до четырех недель. Каждый спринт заканчивается созданием работоспособной версии черновика продукта.
Короткие итерации, свойственные методологии Scrum, позволяют команде последовательно создавать работающий конечный продукт.
Scrum изначально разрабатывался с помощью программной модели, предусматривающей набор ролей и обязанностей и регулярные совещания. Он достаточно гибок, чтобы его можно было применить в ходе любого сложного проекта в любой отрасли, но лучше всего он подходит для случаев, когда в рамках проекта создается конкретный продукт, а не оказывается услуга.
Scrum считается достаточно простым и гибким, но его трудно освоить из-за трех главных ценностей:
Scrum требует определенных ролей и обязанностей для участников Agile-команды, в том числе следующих:
Scrum также имеет собственную уникальную терминологию. Далее приведены важнейшие термины, часто используемые при работе с фреймворком Scrum:
Г. Другие популярные Agile-методики управления проектами
Хотя Scrum — одна из самых популярных Agile-методик управления проектами, это не единственный доступный для вас вариант. Вы можете задать себе вопрос: что представляет собой Agile-планирование и какой фреймворк следует выбрать? Вы можете выбрать любую из пяти других Agile-методологий управления проектами:
1. Kanban
Kanban — это простой и наглядный способ управления проектами. Он изначально разрабатывался как метод планирования и помогает командам создавать продукцию точно в срок (JIT), позволяя всем участникам видеть, как продвигается проект и что будет дальше.
Kanban ориентирован на визуализацию рабочего процесса, когда задачи разбиваются на небольшие части. Фреймворк Kanban во многом похож на Scrum. Здесь также используется доска для отображения информации и отслеживания хода работ, причем задачи распределяются по трем основным столбцам: «К исполнению», «В работе» и «Выполнено». Но в отличие от Scrum, Kanban-доска отражает всю работу по созданию продукта без разделения на спринты.
Kanban помогает выявить препятствия и лишние затраты, а также снизить время ожидания.
2. Экстремальное программирование (XP)
Экстремальное программирование (XP) — Agile-фреймворк, изначально созданный для Agile-проектов по разработке программного обеспечения. Как и Scrum, этот фреймворк нацелен на постоянную разработку и доставку продукта заказчику и использует интервалы или спринты.
Однако фреймворк XP опирается на принципы проектирования и включает 12 основных приемов, специфичных для сферы разработки программного обеспечения. Это следующие приемы:
3. Функционально-ориентированная разработка (FDD)
Функционально-ориентированная разработка — еще один Agile-фреймворк, специфичный для сферы разработки программного обеспечения. Он нацелен на создание моделей через каждые две недели. Также он требует отдельного плана разработки и проектирования для каждой функции модели, то есть превосходит все остальные Agile-фреймворки по объему документации. Из-за жестких требований к документации FDD лучше подходит командам с расширенными возможностями проектирования и планирования.
Фреймворк FDD разбивает проекты на пять базовых повторяющихся видов деятельности:
4. Метод разработки динамических систем (DSDM)
Метод разработки динамических систем (DSDM) возник из-за потребности в общем отраслевом фреймворке для быстрого создания программного обеспечения. DSDM предусматривают доработку, и любые вносимые изменения в ходе разработки должны быть обратимыми. Как и Scrum, XP и FDD, фреймворк DSDM разбивает проекты на мелкие спринты.
Этот фреймворк основан на восьми основных принципах:
5. Crystal
Crystal — это семейство Agile-методологий, включающее в себя Crystal Clear, Crystal Yellow, Crystal Orange, Crystal Red и т. п. У каждой из этих методологий есть свой уникальный фреймворк, и выбирать методологию следует в зависимости от нескольких факторов, в том числе от размера команды, приоритетов и важности проекта. Принимая решение о том, как внедрить Agile-методологию, очень важно понимать, что для различных проектов в зависимости от их уникальных характеристик требуются различные наборы политик, практик и процессов.
Является ли бережливое управление проектами (Lean) Agile-фреймворком?
Хотя Lean часто вносят в список Agile-фреймворков, это отдельная методология. Lean и Agile часто группируют вместе, потому что их ценности во многом совпадают. Например, и для Lean, и для Agile важна способность легко адаптироваться к изменениям.
Д. Определение эпика Agile
В Agile-методологии управления проектами эпики — это «крупные истории пользователей».
История пользователя по своей сути — это то, что пользователь хотел получить. В данном случае, это результаты, которые запросил ваш клиент. В идеале история пользователя достаточно компактна, чтобы уместить ее в один спринт. Допустим, вы работаете над книгой. Если бы вы могли уложить каждую главу в отдельный спринт, то каждая глава была бы историей пользователя.
Но что если на написание каждой главы потребовалось бы восемь недель? История пользователя оказалась бы слишком большой для одного спринта и считалась бы крупной историей или эпиком.
Для эпиков нет жестких ограничений по размеру. Все зависит от длительности спринтов у вашей команды и от потребностей проекта.
Еще один важный термин — это «тема». Тема — это набор историй пользователей, которые связаны между собой или могут быть отнесены к одной категории. Например, если вы планируете строить дом, то можете сгруппировать все электротехнические требования в одной теме, а требования к качеству строительных конструкций в другой.
История, эпик и тема — это термины, которые используют многие Agile-команды, чтобы упростить обсуждение и планирование бэклога продукта. В бэклоге продукта может оказаться требование, слишком масштабное, чтобы назначить его одному спринту, но если вы обозначите его как эпик, каждый участник поймет, что его нужно разбить на части, прежде чем помещать в бэклог спринта.
Точно так же группировка требований по темам может помочь вам запланировать бэклог спринта. Ведь собранные вместе условия может быть удобно выполнить в рамках одного спринта.
Управление проектами с использованием эпиков сводится к управлению бэклогом исполняемым образом. Это гарантирует, что требования будут достаточно компактными, чтобы их можно было выполнить в период от одной до четырех недель.
Однако команды могут запутаться в эпиках и историях и часто прилагают слишком много усилий для их оценки, отслеживания и уточнения.
Эпики задумывались как полезный инструмент группировки в вашем бэклоге, но если они создают для вас сложности, возможно, вам лучше обойтись без них.
Предлагаем посмотреть видеоролик Knowledge Hut, более подробно демонстрирующий определение и ценность эпиков Agile.
Е. Лучшие рекомендации для менеджеров проектов по выбору оптимального фреймворка
Если вы можете выбирать из более чем шести популярных Agile-фреймворков, как узнать, который из них подходит для вашего проекта?
Ни один фреймворк не является универсальным, так что очень важно оценить отдельные проекты и потребности команды.
Вот семь лучших рекомендаций по управлению проектами, основанных на стандарте по оценке зрелости управления проектами в организациях (Organizational Project Management Maturity Model, OPM3) и руководстве по внедрению управления проектами в организациях от Института управления проектами (PMI).
Ж. Бесплатные инструменты для управления Agile-проектами
Все, что вы используете для управления Agile-проектами, является Agile-инструментом для управления проектами. Самый простой пример — это доска со стикерами, но и многие сложные цифровые инструменты также позволяют работать с Agile-фреймворками, такими как Scrum и Kanban.
Что такое SAFe, кому он нужен и где его применять
Scaled Agile Framework® (SAFe) — это онлайн-база знаний, состоящая из доказанных, интегрированных принципов, практик и компетенций внедрения Lean, Agile и DevOps при масштабировании.
Так что это, Scaled Agile Framework или SAFe?
Методология Scaled Agile Framework — это гибкий фреймворк для масштабирования процессов и проектов в организациях, плавающий в айти-вселенной на трех китах: Команда, Программа и Портфель.
Думаете, это выглядит так?
Нет. По сути, SAFe внедряет принципы равенства лишь внутри каждого из китов:
Вся же структура организации выглядит как-то так:
На первом этаже SAFe — Scrum
Это почти что классический скрам: команды по 3-9 человек, спринты по 2-3 недели, скрам-роли, скрам-артефакты и скрам-события. Но только команда теперь не полностью независима. И спринт не полностью самостоятелен.
Для того, чтобы связать между собой работу разных команд над одним продуктом, спринты теперь объединяются в программные инкременты (обычно 5 спринтов = 1 PI). И если в Scrum коррекция производилась по окончанию каждого отдельного спринта, то в SAFe — по окончанию PI. В чем-то это экономит время и упрощает работу в масштабе. С другой стороны, если мы ошиблись вначале, то часто тащим и развиваем этот груз до следующего PI Planning.
На втором этаже SAFe
Ходят Agile Release Trains (по-простому поезда). Здесь же “живут” носители новых ролей: системный архитектор (управляющий архитектурой), продакт-менеджер (старше владельца продукта по званию и полномочиям) и Release Train Engineer (тот же профессионал проектного менеджмента, по-простому PMP в SAFe).
На втором этаже SAFe добавляются некоторые наработки канбана — velocity metrics, scope, способ назначения приоритетов и, конечно же, доска.
Последний из 5 спринтов объявляется организационным. На собрания этого спринта приходят все команды, то есть, 100 и более человек. Здесь анализируется технический долг, производится планирование архитектуры и в целом синхронизируется работа команд.
На третьем этаже SAFe
Происходит координация больших систем и взаимодействия между директорами, отделами и клиентом. На этом этаже анализируются и проверяются гипотезы, а также создаются долгосрочные планы (ура waterfall).
Этот этаж может быть последним, если у компании нет портфеля. А вот если есть…
На четвертом этаже SAFe
Происходит бережливое управление портфелем — Lean Portfolio Management. Здесь выбираются перспективные направления и распределяются средства, принимаются решения о покупке или слиянии организаций, создаются новые направления и закрываются старые. На этом этаже рождается, корректируется и переназначается бюджет. Для оценивания существует ряд метрик, для синхронизации — свои ритуалы.
“Вишенка на торте” — стратегия. Но так глубоко фреймворк SAFe уже не заходит.
Ценности SAFe
Четыре основные ценности SAFe — это ключ и основа для эффективного применения этой методологии.
1. Согласованность
Согласованность необходима, чтобы идти в ногу с быстрыми изменениями, разрушительными силами конкуренции и географически распределенными командами.
Согласованность не подразумевает и не поощряет каскадный менеджмент. Согласование происходит, когда все работают в одном направлении. Оно обеспечивает расширение прав и возможностей, автономию и децентрализованное принятие решений, позволяя тем, кто реализует ценности, принимать более правильные решения на местном уровне.
2. Встроенное качество
Встроенное качество гарантирует, что каждый элемент и инкремент решения отражает стандарты качества на протяжении всего жизненного цикла разработки. Качество — это не то, что «добавляется позже».
Повышение качества является требованием бережливого производства и потока — без него организация, скорее всего, будет работать с большими партиями непроверенной работы. Вероятные результаты — чрезмерная потребность в переделках и снижение скорости.
3. Прозрачность
Без доверия никто не может создать высокопроизводительные команды и программы, а также укрепить (или восстановить) уверенность, необходимую для принятия и выполнения разумных обязательств. Без доверия рабочая среда намного менее увлекательна и меньше мотивирует.
Прозрачность, которую вы обеспечиваете с помощью некоторых практик SAFe, — первый шаг к доверию.
4. Программная реализация
Первые три ценности SAFe не имеют значения, если команды не могут работать и постоянно доставлять ценность. Поэтому SAFe уделяет большое внимание рабочим системам и бизнес-результатам.
Первые три ценности позволяют командам SAFe сосредоточиться на четвертой. И если они будут бороться (а они будут, потому что разработка сложных решений — непростая задача), у них есть краеугольный камень воркшопов по инспекции и адаптации. Таким образом, они замыкают цикл и работают все лучше и лучше во время каждого программного инкремента.
Все эти ценности невозможны без настоящего Lean-Agile лидерства и культуры непрерывного обучения. Только так, создавая постоянную и осмысленную культуру для команд и стейкхолдеров, можно организовать постоянную поставку ценности в потоке.
Принципы SAFe
1. Обосновывайте экономически. Традиционно бюджеты были известны только лицам, принимающим решения. Повседневные решения участников процесса на всех уровнях принимались без понимания экономической составляющей. Это приводило к задержкам, ограниченным возможностям и сниженной эффективности команд на всех уровнях.Экономика должна обосновывать и определять решения на всех уровнях, от портфолио до гибких команд.
2. Мыслите системно. Системное мышление предполагает целостный подход к разработке решений, включающий все аспекты системы и ее среды в ее проектирование, разработку, развертывание и обслуживание.Три аспекта системного мышления:
Понимание этих концепций помогает лидерам и командам ориентироваться в сложности разработки решения, организации и общей картине времени вывода на рынок в целом.
3. Предполагайте изменчивость. Сохраняйте варианты. Человеческая природа стремится к стабильности и устойчивости. Чем меньше изменений, тем нам спокойнее.Изменчивость сама по себе — это ни плохо, ни хорошо. Однако, именно экономика, связанная со сроками и типом изменчивости, определяет результаты. Наша цель в том, чтобы управлять изменчивостью и сохранять варианты. Так у нас будет и контроль, и гибкость, необходимые командам для разработки отличных решений.
4. Разрабатывайте поэтапно (инкрементально) с помощью быстрых интегрированных циклов обучения. Вместо того, чтобы на раннем этапе выбрать один вариант требований и дизайна, мы строим решение постепенно, каждый раз учитывая серию требований и вариантов дизайна.Каждый результат дает инкремент рабочей системы, который можно оценить отдельно. Дальнейшие временные рамки основываются на предыдущих шагах. Так решение развивается поэтапно вплоть до релиза.
5. Основывайте майлстоуны на объективной оценке рабочих систем. Обычно в отрасли применяется последовательный каскадный процесс разработки, где измерение и контроль прогресса происходит через ряд конкретных этапов: открытие идеи, подготовка требований, дизайн, разработку, тестирование и доставку.SAFe советует не привязываться к этим этапам, а определять контрольные точки для инспекции и адаптации исходя из конкретной рабочей системы, над которой работает команда команд. Благодаря этому систему можно будет проверять и улучшать чаще, и делать это будут стейкхолдеры, релевантные конкретному этапу разработки. Коммерческая ценность системы также повысится.
6. Визуализируйте и ограничивайте незавершенные работы (WIP), уменьшайте объем работ и управляйте длиной очередей. Ограничьте количество параллельно реализуемых решений. Поработайте над тем, чтобы уменьшить сложность каждого элемента и всей работы целиком.Небольшие задачи позволяют чаще проверять правильность направления и лучше контролировать очередь задач.
7. Применяйте каденции и выполняйте синхронизацию с помощью кросс-доменного планирования. Гибкая разработка лучше всего работает в «зоне безопасности», где достаточная неопределенность обеспечивает свободу для внедрения инноваций и реагирования на события, а также уверенность в работе бизнеса. Основное средство достижения этого баланса — объективное знание текущего состояния. Эти знания приобретаются путем применения каденции, синхронизации и периодического междоменного планирования.Каденция — это ритмичный паттерн событий, обеспечивающий устойчивое сердцебиение процесса развития. Он делает рутинным все, что может быть рутинным, поэтому разработчики могут сосредоточиться на управлении переменной частью разработки решения.Синхронизация позволяет одновременно понять, решить и интегрировать несколько точек зрения.В дополнение к общей каденции, периодическое междоменное планирование (пример: PI Planning в SAFe) дает возможность одновременно интегрировать и оценивать различные аспекты решения — деловые и технические.Вcе это позволяет управлять изменчивостью за счет частого пересмотра и обновления плана.
8. Раскройте внутреннюю мотивацию работников умственного труда. С SAFe, работники умственного труда могут больше:
9. Децентрализируйте процесс принятия решений. Централизировать нужно только решения стратегического характера. Они:
Все прочее нужно решать на местах.
10. Организовывайте вокруг ценности. Этот принцип описывает, как освободить предприятие от самоорганизации, оптимизируя доставку ценности. Это получается сделать за счет трех вложенных частей:
Agile фреймворки и чем они отличаются: Scrum vs Kanban
Все, кто работали и работают в сфере ИТ, хоть раз слышали про Agile, а еще про Scrum и Kanban. Сейчас практически любая компания хочет быть хоть немножечко аджайл, и это хорошо, когда есть выбор, но что именно подойдет вам? Чтобы окончательно не запутаться в этих понятиях и знать, в чем их преимущества, в этой статье мы предлагаем вам более детально ознакомиться с Agile и его основными фреймворками: Scrum и Kanban.
Что же такое Agile?
Agile — это методология “гибкой” разработки ПО. И, хотя это направление появилось в ИТ сфере, оно удачно применяется и в любой другой. Сейчас различные фреймворки и подходы Agile успешно прижились в таких корпорациях, как Microsoft, Salesforce, Trenches, Hewlett-Packard, Spotify, причем не только в сфере ИТ, но еще и в сфере маркетинга и управления. Это итеративный подход, суть которого отражается в Agile манифесте, и ее можно описать следующими тезисами:
В отличие от других подходов вроде Waterfall, где можно выполнять задачи только если они были запланированы ранее, с Agile команда сможет легко подстраиваться под новые требования и факторы. Особенно это актуально для крупных проектов, где стейкхолдеры постоянно хотят что-то поменять.
Проще говоря, Agile — это своеобразная философия, но как ее придерживаться, зависит от конкретного случая. Есть 2 основных фреймворка, которые основываются на базовых принципах Agile: Scrum и Kanban.
Scrum
Термин Scrum пришел из регби. Он означает особую фигуру, в которую собираются игроки перед началом матча, и выглядит это примерно так:
Фигура Scrum в регби
В бизнес среде слово Scrum у многих людей ассоциируется с ежедневными короткими собраниями команды в начале дня для обсуждения проделанной работы и планирования следующих задач.
Суть данного фреймворка в том, что вся работа делится на спринты — промежутки времени от 1 до 3 недель. Как только спринт выполняется, происходит его ревью — оценка и анализ проделанной работы, чтобы понять, что можно улучшить. В Scrum задачи необходимо оценивать в Story points или в часах. Без этой оценки у вас не получится сформировать спринт, ведь нужно знать, сколько часов потребуется на выполнение той или иной задачи. Еще один параметр — Velocity, то есть производительность команды за один спринт. Таким образом, Scrum подойдет для объемных проектов со строгим дедлайнами, где всю работу можно распланировать по четким спринтам, зная, сколько времени тратится на выполнение задачи и получая ценную статистику, благодаря которой можно предвидеть, где команда будет через 2 недели.
Kanban
Это еще один трендовый Agile фреймворк, который пришел в сферу ИТ прямиком с конвейера компании Toyota. В отличие от Scrum, где выполняются заранее запланированные задачи, здесь работникам можно время от времени “подбрасывать” новые таски.
Kanban визуализирует весь рабочий процесс и позволяет разделить все текущие задачи на 3 основных этапа: “Сделать”, “В процессе”, и “Сделано”. Еще один важный нюанс — Limit Work in Progress (WIP), то есть обычно ограничивается количество задач, которые сейчас находятся в процессе. Лучше синица в руках, чем журавль в небе, и стабильное выполнение небольшого количество задач лучше, чем если браться за множество тасков и толком не закончить и одного.
Независимо от количества задач, сначала будут выполняться таски с наивысшим приоритетом. В Kanban также не проводится оценка, и нет такого понятия, как “скорость работы команды”, можно просчитать только среднее время на задачу с помощью специального отчета Cycle Time. Если в Scrum цель команды — закончить спринт, то в Kanban — задачу.
Каждый Agile фреймворк хорош по-своему, и нам часто задают вопрос: “Какой фреймворк лучше выбрать?”. Наш ведущий эксперт Алекс Енин отвечает, что подобрать универсальное решение для всех — это из разряда фантастики, ведь то, что сработало в одной команде, далеко не всегда заработает в другой. Scrum держит всю работу над проектом под контролем, планируя все до мелочей, а Kanban позволяет сконцентрироваться на выполнении текущих задач, планомерно внося изменения в рабочий процесс. Нужно отталкиваться от конкретного случая, размеров команды, объема работы и сферы применения.
Обратитесь к экспертам Polontech, и наша команда проконсультирует вас по всем Agile фреймворкам, поможет подобрать и внедрить подходящий софт, а также сопроводит на начальных этапах. Расскажите нам о своем проекте, и мы подберем уникальное решение под ваши нужды.
Наши авторы
Профессионалы, работающие с Sony, NASA, Сбербанк, МТС, Nokia и многими другими компаниями. Спикеры на конференциях, авторы статьей