Agile scrum что это

Scrum/Agile/Kanban/Lean — как выравнивать процессы, убирать посредников, максимизировать ценность

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

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

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

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

Но давайте вернемся ближе к нашему времени, в начало двадцатого века. В Европе и США идет бурное развитие промышленности, предприятия ищут возможности для повышения эффективности. В США Фредерик Тейлор начал свои подробные исследования в области научной организации труда и менеджмента, а его ученик Генри Гант изучал менеджмент на примере постройки кораблей во время Первой мировой войны и предложил свою диаграмму, состоящую из отрезков (задач) и точек (завершающих задач или вех), как средство для представления длительности и последовательности задач в проекте.

Нам они известны как “Диаграммы Ганта” или Каскадная модель. Они совершили настоящую революцию в управлении проектами в 20-х годах XX века. Диаграммами пользовались во многих грандиозных инженерных проектах, например при строительстве дамбы Гувера и при строительстве сети скоростных магистралей США.

Необходимость перехода к современным методам управления проектами

С момента массового появления в 1980-е годы персональных компьютеров, стало проще создавать самые разнообразные и сложные диаграммы — делать их по настоящему комплексными.Они превращались в подлинные художественные произведения. Абсолютно каждый шаг проекта детально размечен. Любая стадия. Всякая дата. Диаграммы Ганта производят глубокое впечатление. Но есть одна единственная проблема: они всегда неправильны.

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

Такая проблема начала остро вставать и перед разработчиками программного обеспечения в 1980-х. Дело дошло до того, что отсутствие новых стандартов и правил при разработке программного обеспечения привело к полноценному мировому кризису разработки.

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

• Проекты всегда превышали бюджеты;
• Реализация проекта всегда превышала первоначальные сроки и зачастую вообще не доходила до завершения;
• Готовое ПО неэффективно выполняло заявленную функцию;
• Финальный результат был низкого качества;

Scrum

В 1995 году Кеном Швабером и Джеффом Сазерлендом на OOPSLA 95 в Остине была представлена новая сформулированная и задокументированная методология ведения проектов при разработке ПО. Назвали ее Scrum (Схватка — термин взятый из регби).

Ее разработкой и внедрением Д. Сазерленд занимался во время своей работы в компании Easel в 1993 году. Перед ним стояла задача в очень сжатые сроки создать абсолютно новую линейку ПО. Он решил отказаться от каскадной модели ведения проекта и занялся поиском оптимального решения.

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

Те принципы и методы которые он почерпнул для себя из этой статьи, позволили ему успешно завершить проект небольшой командой и в максимально короткие сроки. А затем он сформулировал основные принципы Scrum.

Итак давайте рассмотрим основные принципы Scrum:

• Работа короткими циклами (Спринт). Проект разделяют на части, которые называют Спринтами. Продолжительность Спринта от 1 до 4 недель. За это время команда берет на себя некоторое количество задач. Которые она стремится выполнить в этот временной отрезок.
• Гибкость. После окончания каждого спринта, команда собирается для обсуждения и выявления слабых и сильных моментов, учитывает их и при необходимости корректирует Бэклог (список задач).
• Постоянное взаимодействие с заказчиком. В составе Scrum-команды есть «Владелец продукта», человек который взаимодействует с заказчиком, показывает ему результаты работы, уточняет потребности и его пожелания. Благодаря этому взаимодействию удается оперативно изменять и уточнять реальные потребности заказчика.
• Командная работа. В команду обычно входите не более 6-10 человек с необходимыми для выполнения проекта компетенциями и навыками.

Гибкость Agile методик

Scrum относится к гибким моделям разработки Agile. Это целая философия, которую сформулировали благодаря «Манифесту Agile» в 2001 году. В манифесте особое внимание уделяется взаимодействию участников разработки и возможности изменений в проекте, которых не хватает в жесткой методологии управления проектами.

Ценности и принципы Agile:

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

К основные методологиям Agile относятся Scrum, Kanban и Lean. Scrum мы уже рассмотрели, а что из себя представляют Kanban и Lean. Они тоже пришли к нам из Японии, и родственны философии бизнеса Кайдзен и Тойоту.

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

Что касается Lean, то это больше философия и набор методик для создания бизнеса и подхода к разработке. Она подробно описана в книге Lean startup Эрика Риса.

Характерно для Lean:

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

Основные преимущества Scrum в сравнении с каскадным методом

В чем же отличие Scrum от Каскадной системы управления проектом?

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

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

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

Поскольку в Scrum в каждом спринте команды выдают готовое решение (которое является частью всего продукта), они могут устанавливать измеримые цели, которые команда должна достичь. Это позволяет понять справляется ли команда с поставленными задачами, есть ли прогресс и успеваем ли мы реализовать продукт до установленного дедлайна. Благодаря такому подходу намного проще корректировать ход выполнения тех или иных задач, что в результате дает возможность мотивировать и поддерживать команду на максимальном уровне их самоотдачи проекту.

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

Agile scrum что это

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-подходов используют доски: физические и электронные. Они позволяют сделать рабочий процесс открытым и понятным для всех специалистов, что важно, когда у команды нет одного формального руководителя.

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

Один из принципов Agile стоит на личной ответственности человека, а не на отлаживании внутренних процессов.

(Из статьи на VC.ru)

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

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

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

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

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

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

Слово экспертам

В зависимости от задач мы применяем разные методы в рамках философии – agile, scrum, kanban. Scrum позволяет развить в сотрудниках необходимые качества – проактивность, самостоятельность, организованность, коммуникабельность и дальновидность. Основной смысл метода – это выполнение задач в самоорганизующихся командах, где у каждого есть своя роль и каждый несет ответственность за свою часть работы. Используя scrum, мы проводим опросы персонала, составляем графики ожидаемой скорости выполнения задач. Agile мы используем во внутренних коммуникациях. Недавно провели очередной спринт по ликвидации опозданий сотрудников. Все начальники и специалисты, задействованные в проекте, провели целый день на совещании, обсуждая достижения, проблемы и предстоящие задачи в новом спринте. Сейчас мы активно внедряем в компании метод kanban. Цель внедрения kanban – повысить гибкость производства, лучше приспосабливаться к изменяющимся требованиям рынка. На практике метод помог нам добиться соответствия между складскими запасами и реально используемыми в производстве продуктами.

Владимир Овелян
Владелец и генеральный директор Dostаевский

Важный момент: agile-методология – это общее направление, а kanban и scrum – уже ее разновидности. Мы используем связку scrum + waterfall, а также дорабатывали в течение года саму agile-доску. Главная причина использования: прозрачность и простота. По сути, это получается тот же самый конвейер Генри Форда: переход задачи от статуса к статусу со сменой исполнителя, поэтому основным принципом к самой agile-доске является уже простота. Мы используем agile как непосредственную часть нашего workflow, поэтому все проекты, от брендинга и разработки сайтов и вплоть до нашего стартапа по AI и нативной рекламе NativeOS, в бюро Chernika ведутся как раз по данному workflow. Работающий продукт важнее подробно прописанной документации. Это не говорит о том, что мы не ведем никакую документацию, нет. Это скорее взгляд в сторону эффективности с ударом по излишней бюрократии.

Виталий Сотников
Креативный директор Бюро визуальных коммуникаций «Черника»

Scrum принес в нашу команду ритмичность и понимание — успеваем или не успеваем в срок. Мы видим скорость работы команды, нет ощущения постоянного факапа. Раньше были ситуации, что перед жесткими релизами scrum куда-то пропадал и все начинали просто фигачить — сейчас у нас это пропало, есть постоянное ощущение, что успеваем в срок. Если появляются риски, мы обсуждаем их с PD на ранних этапах, корректируем план или уменьшаем объем задач каким-то образом. Работа стала прозрачнее, рабочий день стал укладываться в 8-часовую норму и, по ощущениям, мы стали успевать больше. Мы понимаем, что когда у тебя есть ощущение, что ты не успеваешь, чувствуешь, что надо работать больше — это очень плохо влияет на продуктивность, от этого надо избавляться.

Илья Шихалеев
Ведущий разработчик и скрам-мастер iSpring

Для наглядности и открытости работы отдела разработки мы повесили специальную доску с пометками “to do”, “in progress”, ”review”, ”test”, “done”, где все члены команды наклеивают стикеры с задачами (в колонке “to do”), а по мере их выполнения перемещают в последующие пункты. И счастливый финал – конечный пункт “done”. Это помогает составить общую картину и дает возможность видеть, над чем работает каждый участник. Очень важный момент метода (и организации рабочего процесса): после утверждения всех задач (“to do”), список блокируется на внесение. Так новые поступающие задачи не отвлекают от процесса и не тормозят работу. Все участники также оценивают каждую задачу на предмет временных и материальных затрат, которые потребуются на выполнение. И вишенка на торте – ежедневные встречи в определенное время (Daily Scrum), где каждый член команды коротко рассказывает о том, что собирается сделать сегодня, что сделал вчера (и столкнулся ли с какими-то препятствиями). Это важно на пути к долгосрочным задачам – именно так можно вовремя понять, что пора сменить стратегию.

Евгений Россинский Директор по технологии в онлайн-кинотеатре ivi

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

Ирина Черепанова
Директор по продукту uKit Group

Agile – это философия, scrum – структура, waterfall – метод, kanban – система управления. Scrum и kanban – варианты agile, но у них есть некоторые явные различия. Методика scrum требует фиксированных ролей, тогда как у kanban нет необходимых ролей. Scrum основана на итерациях, объединяющих планирование, оптимизацию процессов и выпуск. В kanban это можно делать регулярно или каждый раз, когда вам нужно. Команда scrum требует оценки своей работы, тогда как команде kanban это не нужно.

Инга Корягина
Доцент кафедры теории менеджмента и бизнес-технологий РЭУ им. Г.В. Плеханова

Что почитать по теме?

1. Agile-манифест разработки программного обеспечения (Manifesto for Agile Software Development)
2. Дж. Сазерленд «Scrum. Революционный метод управления проектами»
3. Д. Андерсон «Канбан. Альтернативный путь в Agile»
4. Э. Стелманн, Дж. Грин «Постигая Agile. Ценности, принципы, методологии»
5. K. Schwaber, J. Sutherland “The Scrum Guide”
6. M. Cohn “Agile estimating and planning”

RB.RU организует встречу проекта Founders’ Mondays для начинающих и опытных предпринимателей. Дважды в месяц по понедельникам.

Текст: Александр Петров.

Видео по теме:

Agile, Scrum и Kanban: в чем суть и как это работает

Agile, Scrum, Kanban – в последние годы эти термины переживают пик популярности, (по крайней мере в украинском социуме). Все больше людей стало интересоваться гибкими методологиями управления проектами и их особенностями. И это неудивительно, ведь по ним можно эффективно работать в любой отрасли, но особенно хорошо они подходят для ИТ. Но в чем суть каждой? И чтобы вы не путались в терминах, давайте разберемся как их успешно использовать.

Определение

Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile. Сам Agile (agile software development, от англ. agile – проворный) – это семейство «гибких» подходов к разработке программного обеспечения. Такие подходы также иногда называют фреймворками или agile-методологиями.

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

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

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

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

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

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

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

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

В чем разница между Scrum и Kanban?

Основу Scrum составляют короткие спринты, как правило, 2-3-х недельные. Перед началом спринта команда сама формирует список задач на итерацию, далее запускается спринт.

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

На Kanban дает больше гибкости, если под гибкостью понимать частоту смены приоритетов. Если вчера разработчик залил выполненную задачу, а сегодня получили данные с “передовой” и узнали, что вот эта штука не работает так, как было задумано, то дают новые требования. Дополненные новые задачи поднимаются вверх и программист берет эту задачу «сверху», выполняет ее и, к вечеру все работает как надо. Все счастливы и эффективны как никогда.

В Scrum задачи принято оценивать в Story points или в часах. Без оценки не получится сформировать спринт: ведь нам нужно знать, успеем ли мы сделать задачи за 2 недели. Через 2 недели мы получаем ценную статистику — сколько часов или Story points команда смогла сделать за спринт. Velocity — это производительность команды за один спринт. Этот параметр позволяет Scrum менеджеру предсказать, где команда будет через 2 недели.

В Kanban не принято делать оценку. Это опционально, команда решает сама. Здесь нет понятия «скорость работы команды», считается только среднее время на задачу. Время это считается с помощью специального отчета — Cycle Time.

Cycle Time для задачи = время выполнения задачи минус время начала работы над задачей. Например, у вас есть колонки: to do, reopened, developing, testing, stage testing, deployed. Cycle time для задачи будет равен deployed-developing, то есть сколько времени прошло от момента, когда задачу начали делать до момента пока она попала в deployed.
Итак, в Scrum наша цель — закончить спринт, в Kanban — задачу.

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

Scrum и Kanban на практике

В чистом виде отдельные методы встречаются редко. Чаще всего компании сочетают те части гибких систем, которые им больше всего подходят. К примеру, для продуктовой разработки больше подойдет Scrum. Для начальных этапов, таких как исследование или тестирование гипотез, – Kanban. С точки зрения других подразделений, используется облегченный вариант Kanban: для координации ежедневных задач, синхронизации, и уверенного пути вперед!

Scrum является очень удобным инструментом планирования. Он дает некую гибкость в непосредственном улучшении продукта. К примеру, во многих ИТ-компаниях, его используют раз в две недели для планирования самой разработки. Это помогает не тратить два-три месяца на решение проблемы, а запускать MVP (Minimal Viable Product, минимальный жизнеспособный продукт) и оперативно его дорабатывать после получения обратной связи от пользователей. Kanban,в свою очередь, отлично подходит для мониторинга хода выполнения работ. Ведь его ключевая задача — обеспечить процесс и ход разработки.

Что выбрать — Scrum или Kanban

Отметим, что каждая методология решает свою проблему. Поэтому все зависит от целей и ожиданий от проекта. К примеру, вы создаете новый удобный мессенджер. Если вы используете принцип Kanban, вы прописываете детальный план, чтобы создать идеальный продукт, — и через год разработки получаете желаемое. Kanban — строгая последовательность задач, равномерная загруженность, четкость на каждом этапе. А если у вас нет конкретного плана? Тогда, на помощь приходит метод Scrum, с которым мелкими «шажками» (спринтами) можно постоянно разрабатывать и улучшать продукт благодаря быстрой обратной связи. В итоге конечный продукт может быть совершенно другим, чем тот, который планировался в начале, но он будет максимально соответствовать ожиданиям пользователей.

Agile scrum что это

Комментарии

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

ЛУЧШИЕ СТАТЬИ ПО ТЕМЕ

�� ТОП-14 российских аналогов Jira и систем управления проектов

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

Бесплатные книги по управлению проектами для новичков и профи

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

Как найти ментора в IT-сфере и откуда начать поиски?

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