Один из девизов agile ошибись раньше ошибаться раньше полезно

Обновлено: 21.12.2024

Agile methodology, что в переводе значит «гибкая методология», — тренд среди программистов и разработчиков. Но принципы agile популярны во всех сферах бизнеса, ведь идея agile — в гибкости, способности адаптироваться под текущую ситуацию и корректировать сроки и отношение к продукту в зависимости от изменений. Пожалуй, это самый адекватный подход для российского бизнеса именно сейчас, в условиях нестабильности и невозможности долгосрочного планирования. Вот только на самом деле agile вовсе не универсален. Так в каких случаях этот метод не для вас?

1. Стоимость переделки очень высокая

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

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

Реклама на Forbes

2. Все по инструкции

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

3. «Команда» из одного-двух человек

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

Однако стоит понимать, что команда — это когда над задачей трудятся от трех человек и больше. Нет смысла внедрять Agile там, где у вас работает два сотрудника. Они и так легко договорятся, какого-то специального процесса для этого просто не требуется. Хотя на практике мы видим, что и до и после непосредственного этапа производства есть еще люди и процессы. Если рассматривать весь поток работы, от идеи до удовлетворения пользователя, то понятие «команда» будет включать в себя не только разработчиков. И тогда Agile — ваш вариант.

4. Нет четкого понимания, что и зачем мы делаем

Если у вас нет требований и видения продукта — хотя бы на уровне понимания вашего сегмента пользователей, их потребностей и ценностного предложения — то зачем вам Agile? Мы можем научиться делать быстро, увлекать сотрудников идеей, поставлять продукт на рынок, но если мы не попадем в пользователя, то у нас ничего не купят. По этому поводу вспоминается высказывание Сенеки (IV в. до н.э.): «Когда корабль не знает, в какой порт направляется, ни один ветер не будет для него попутным».

Например, в одном из банков решили сделать систему автоматизированного документооборота с регулирующими органами. Заложили большой бюджет, набрали команду разработки. Но разработчики за месяц успели реализовать маленькую, минимально жизнеспособную версию этой системы, а у менеджеров были масштабные планы на дальнейшую разработку. Наняли Agile-коучей, чтобы наладить рабочий процесс и сделать все быстро. Но первое же планирование работ с командой на ближайший месяц показало, что исходные продуктовые посылки никто не подумал проверить. Оказалось, что весь «поток» составлял 2-3 документа в неделю. После анализа оказалось, что дешевле нанять специального человека, который бы вел этот небольшой документооборот, используя ту небольшую систему, которую успели сделать разработчики, и больше ничего разрабатывать не потребуется. В данном случае все кончилось хорошо, но представьте, какие ненужные убытки и какой бесполезный продукт появился бы, если бы вовремя не проанализировали — а какова реальная бизнес-потребность в данном продукте?

  • Уроки моря: принципы яхтенного спорта, которые помогают в жизни и бизнесе

5. Ваш ключевой подрядчик не умеет и не хочет работать по Agile

Определенная (а часто и главная) часть работ делается подрядчиком. Внутренние процессы подрядчика становятся ключевыми для нас, и как бы мы ни хотели снизить Time To Market (время выхода первой версии продукта на рынок), стать более гибкими, лучше реагировать на обратную связь от пользователя, пока мы не имеем влияния на то, как именно подрядчик работает — ничего не сдвинется с мертвой точки. Например, подрядчик отказывается вносить срочные изменения, потому что техническое задание утверждено и подписано на год вперед и ваши доработки он сможет внести только в следующем году за дополнительную плату.

Что делать? Наладить оперативный контакт с подрядчиком, в каком-то смысле перетянуть его на свою сторону. Например, переходить на аренду команды разработки и оплату времени работы этой команды (time & material), а чтобы команда делала именно то, что нужно — выделить со своей стороны продуктового менеджера к подрядчику, чтобы тот напрямую доносил видение продукта команде и осуществлял приемку. Вариантов организации масса. Но все они должны быть направлены на максимально тесное, прозрачное и оперативное взаимодействие с разработчиками подрядчика. Только после этого можно двигаться в сторону Agile.

6. Руководство не доверяет своим людям и не готово предоставить им свободу действий

Когда мы идем в сторону Agile, то делаем ставку на людей. Это командная работа, мы делегируем им принятие решений. Если они работают, находясь рядом друг с другом (в одном помещении), то могут быстро согласовать все вопросы. Но опыт показывает, что руководство само не всегда готово к такой самостоятельности. А если у сотрудников нет возможности принимать решения, пусть даже в рамках какого-то «коридора возможностей», то они не вовлекаются и всегда будут ждать указаний сверху.

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

В заключение хочется напомнить, что Agile — это не методология и не алгоритм, а четыре ценности:

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

Опираясь на эти ценности, вы станете более гибкими, а ваш продукт быстрее завоюет рынок.

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

О философии аджайла на примере пирожков читайте в справочнике Unusual Concepts «Аджайл для новичков», а пока давайте разберемся с мифами, которыми аджайл оброс в России.

Миф 1: аджайл — это методология

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

Неверно называть аджайл и «семейством методологий». Под семейством подразумевают фреймворки Скрам, Канбан, Crystal, DSDM и другие — все это правила о том, как философию аджайла применять в жизни. Эти правила описаны общими словами, они тоже не относятся к методологиям.

Рассмотрим на примере, как одна ценность аджайла объяснена в «Манифесте» и руководстве о скраме, и как ее пришлось бы описывать в методологии.

  • Манифест аджайла: «Работающий продукт важнее исчерпывающей документации».
  • Скрам: работайте короткими итерациями, в конце каждой представляйте работающий продукт, который имеет ценность для клиента. Этот продукт может быть простым, без части функций и фич. Но не может быть пачкой документов и техзаданием, потому что бумаги ценности для клиента не представляют.
  • Методология: работайте над продуктом девять дней. В первый день проведите мероприятие А, чтобы узнать ожидания клиентов. По типологии Б определите тип продукта, а по таблице В выберите подходящий сценарий разработки. Разрабатывайте проект строго по сценарию, чтобы закончить к восьмому дню. Проведите презентацию проекта по сценарию «Вау» и соберите обратную связь (анкеты Д и Е).

Вывод: аджайл — это особый образ мышления. Он похож на философию и религию, и не является методологией разработки продуктов.

Миф 2: если у нас Скрам, значит, мы автоматически аджайл

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

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

— Игорь Петрович, добрый день. Середина спринта, сервер сгорел. Давайте новый купим.

— Ок, оформляйте заявку.

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

— Нет, вы же знаете правила. Сначала заявка и визы, потом покупка.

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

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

Миф 3: аджайл — это для айтишников

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

В России аджайл прижился в:

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

Миф 4: аджайл — это для маленьких компаний

Все наоборот. Философия аджайла — это сумма положительного опыта запуска больших и очень сложных проектов. Если изучить список людей, которые разработали Манифест аджайла, можно заметить, что они — основатели и президенты действующих консалтинговых и технологических компаний. Например, один из авторов Скрама Джеф Сазерленд — главный технический директор в PatientKeeper. Это одна из первых компаний, которая начала производить медицинское ПО и мобильные приложения для врачей.

На корпорации аджайл действует как «пилюля молодости». Он помогает избавиться от бюрократии и вернуть гибкость стартапов. В России сейчас так «молодеет» «Альфа-Банк» (20 000 сотрудников). А «Додо пицца» растет быстро, но не бюрократизируется.

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

Миф 5: чтобы перейти на аджайл, достаточно сходить на тренинги

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

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

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

Вывод: аджайл — история об изменении мышления. Тренингов и книг для таких глубоких трансформаций мало.

Миф 6: аджайл нужно «внедрять»

Аджайл — это философия, набор ценностей. Эти ценности можно только принять, сделать своими. «Внедрить» новое мышление не получится.

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

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

Вывод: философию аджайла можно изучить и разделить ее ценности. «Внедрить» новый способ мышления нельзя.

Миф 7: аджайл — это быстро и сразу принесет много денег

Нет, настоящий аджайл — это медленная и трудная трансформация людей и компании.

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

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

Вывод: аджайл — это долго, а результат можно измерить счастьем сотрудников и клиентов, но не деньгами.

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

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

Чтобы избежать иллюзий и правильно использовать идеи аджайла, самостоятельно изучите «Манифест» и «Принципы аджайла». Посмотрите, насколько эти ценности близки вам и как реализуются в вашей компании. Если все нравится и хочется пробовать, ищите наставника — сертифицированного коуча. Он поможет вашей команде трансформироваться и использовать настоящую силу аджайла.

Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

Agile возник в IT-среде, но затем распространился и в другие сферы – от промышленной инженерии до искусственного интеллекта.

Смысл Agile сформулирован в Agile-манифесте разработки ПО: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

Agile-манифест – главный документ всех «гибких» подходов к разработке. Он был создан в 2001 году группой энтузиастов-программистов, которые хотели понять, что именно лежит в основе разработки востребованного и полезного IT-продукта. Agile предполагает, что при реализации проекта не нужно опираться только на заранее созданные подробные планы. Важно ориентироваться на постоянно меняющиеся условия внешней и внутренней среды и учитывать обратную связь от заказчиков и пользователей. Это поощряет разработчиков и инженеров экспериментировать и искать новые решения, не ограничивая себя жесткими рамками и стандартами.

К отдельным agile-подходам относятся scrum и kanban.

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

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

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

Вся команда едина – в kanban нет ролей владельца продукта и scrum-мастера. Бизнес-процесс делится не на универсальные спринты, а на стадии выполнения конкретных задач: «Планируется», «Разрабатывается», «Тестируется», «Завершено» и др.

Главный показатель эффективности в kanban – это среднее время прохождения задачи по доске. Задача прошла быстро – команда работала продуктивно и слаженно. Задача затянулась – надо думать, на каком этапе и почему возникли задержки и чью работу надо оптимизировать.

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

Примеры употребления

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

(Из интервью «Ведомостей» с Фрэнком Сосьером, коучем компании Freestanding Agility)

Главная идея Kanban – визуализация рабочего процесса. Она заключается в создании физической панели, на которой можно наглядно отмечать прогресс.

(Из перевода колонки Forbes на Rusbase)

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

(Управляющий партнер ScrumTrek Алексей Пименов в статье на Rusbase)

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

За популярность в России Agile может быть признателен Герману Грефу. Именно он во всеуслышание высказался в поддержку этого гибкого метода и продолжает обосновывать, почему это важно для банковской сферы (и не только). Хотя, надо признать, что Agile в России применялся еще до того, как Герман Оскарович съездил в Кремниевую долину, где познакомился с системой. Сегодня Agile внедряется в государственных учреждениях, банках, коммерческих организациях и используется для достижения совместных бытовых планов в некоторых семьях.

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

Реклама на Forbes

Для тех, кто торопится и не хочет читать долго — объясню подход в четырех строках. Это цитата из манифеста Agile-разработчиков: «Люди и взаимодействие важнее процессов и инструментов. Работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта. Готовность к изменениям важнее следования первоначальному плану».

А для тех, кто все-таки хочет копнуть глубже — 7 фактов об Agile.

Тезис №1. Agile нужен, чтобы в сжатые сроки показать клиенту результат

Для этого большой проект разбивается на отрезки (итерации) длиной от 1 до 4 недель, в конце каждого из которых клиент должен получить работающий продукт. После получения обратной связи от клиента продукт с каждой новой итерацией становится лучше и ценнее для клиента. Например, заместитель директора информационной службы штата Вашингтон Майкл де Анджело рассказал, что еженедельно они рассылают во все государственные учреждения своего региона практические планы. Задача — регулярно в 7 дней, пусть маленькими шагами, но что-то менять в лучшую сторону. Служба выдает потенциально готовый продукт, который учреждения могут начинать применять сразу же. Не всегда это что-то материальное, важно, чтобы это было что-то, создающее ценность (например, полезные рекомендации к работе).

Тезис №2. Agile позволяет быстро запустить продукт, обогнав конкурентов

Забудьте о многолетней подготовке продукта — как говорится, лучше времени, чем сейчас, никогда не будет. Гораздо выгоднее дополнительно инвестировать в команду и оперативно занять никем не освоенный сегмент рынка, опередив всех своих конкурентов. Вспомним октябрь 2016 года и Сбербанк — тогда он первым на российском рынке предоставил возможность оплаты через Apple Pay. Как результат — 10 млн пользователей, которых банк сразу же собрал и записал себе в актив. Вот это было по-Agile.

Тезис №3. Agile нужен для гибкого управления бизнесом в постоянно меняющемся мире

Слово «agile» переводится с английского как «проворный, расторопный». И хотя agile-методы действительно позволяют быстро выводить на рынок качественные продукты, суть этого подхода не в скорости, а в гибкости. Хороший пример — компания «Кнопка», которая работает на бухгалтерском рынке. Типичная компания этой сферы — это 200 клиентов на 20 сотрудников. Привлечь большее количество клиентов можно, но зачастую это приводит к раздуванию штата. В «Кнопке» смогли применить гибкость и творческий подход agile-системы, тем самым увеличив портфель клиентов практически до 1000, не расширяя свой штат. В компании отказались от жестких KPI, регламентов и микроконтроля. Кроме того, было решено «облегчить жизнь» бухгалтерии: в компании поняли, что довести бухгалтерский баланс до совершенства невозможно, и стали применять принцип Парето — риск доначисления нескольких сотен рублей не должен стать поводом бессонных ночей бухгалтера и бесконечных звонков клиенту с требованиям предоставить все возможные данные. Так сократились часы сотрудников, уменьшился градус напряженности в коллективе и нашлось место для «творческого подхода» в области дебета и кредита.

Тезис №4. Agile мотивирует команду, не прибегая к материальным стимулам

По итогам каждого отрезка заказчик оценивает результат и даёт обратную связь. Забеги на короткие дистанции дают ощущение быстрой победы, а благодаря регулярному общению и тесной связи с бизнесом команда ощущает значимость своей работы для общего дела. Неудивительно, что 98 % компаний, внедривших Agile, отмечают рост мотивации своих сотрудников. Например, разработчик облачных решений Salesforce применил Agile-подход, когда компания выросла до 200+. В этот момент руководство поняло, что, «как раньше» работать не получается. Поэтому все команды переформировали в кросс-функциональные (сотрудники разных отделов могли больше взаимодействовать, были ориентированы на один общий результат и узнавали о параллельных процессах много интересного). В итоге, компания за три месяца достигла того, чего не могла добиться весь предыдущий год. Как результат — счастливые заказчики и команды без дополнительных мотивационных вложений.

Тезис №5. Agile и микроконтроль несовместимы

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

Тезис №6. Agile подходит не только для IT-бизнеса

Agile-подходы применяются не только в разработке программного обеспечения, но и в производстве физических вещей и даже в госуправлении. Например, испанец Амансио Ортега — богатейший человек мира на август 2017 г. — применяет agile-подходы почти во всех компаниях, входящих в принадлежащий ему розничный гигант Inditex: Zara, Massimo Dutti, Bershka, Pull and Bear и другие. Быстрая обратная связь от потребителей и регулярные эксперименты, позволяющие оперативно проверять гипотезы, позволяют Zara выпускать до 40 коллекций в год (у среднего аналогичного бренда — от 4 до 8 коллекций). Другой пример — госучреждения Великобритании, где Agile — негласный стандарт. Например, метод применяется в области государственных услуг. Данные о потребностях граждан постоянно анализируются и работа сервисов госуслуг корректируется, исходя из собранной информации (например, становятся более удобными часы работы).

Тезис №7. Внедрение Agile может привести к краткосрочному снижению издержек, но это не главное

Реклама на Forbes

Хорошие профессионалы стоят дорого, поэтому пока формируется команда, расходы оказываются высокими. Однако суммарные затраты на проект будут низкими за счет быстрого запуска продукта. Например, поставщик медицинских информационных решений корпорация Cerner внедрил Agile, когда встала необходимость ускорить выпуск своих продуктов на рынок. Благодаря гибкому подходу компания сократила выход на рынок и издержки до 75%.

Читайте также: