Что такое agile: Что такое Agile, зачем и где используется, разница Scrum и Kanban

Обзор методов agile

Предисловие.

Я назову этот текст обзором методов agile, расскажу как выбирать между agile и каскадной методологией разработки, дам ссылки на подробные статьи и книги о методах, так как каждую часть этого обзора можно писать как отдельную статью. Буду писать иногда сумбурно, иногда субъективно. Я не журналист, который стремится показать разные точки зрения. А мудрый читатель с высокоразвитым критическим мышлением придет к своему «правильному» ответу. Поэтому, точка зрения авторская. Любые совпадения считать верными, додумки и стереотипы точными. Шутка.) Главной задачей ставлю себе написать простым языком для начинающих знакомиться с миром Agile. Тем более я сейчас сам начинающий продакт-менеджер, учусь в product University. Когда буду давать ссылки на разную литературу и источники, увы много на английском. Зато прокачаете язык. Для будущего продакт-менеджера — это хороший навык.

История методов и появления семейства agile.

Начнем с истории методов. Я привык читать и слышать бизнес истории о том, как много работали и придумывали методы. Много табличек, экспериментов, компаний пилотников. После всего, через 100500 лет, появилась методика, которую внедряли, через жуткое сопротивление сотрудников, полусуициидальные настроения топов и т.д. История про Agile, по-моему, вообще не про это. В начале стоит сказать, что Agile — это не метод, а группа методов управления проектами. Что самое крутое, большинство методов появилось раньше самого семейства agile.

Оговорочка: то, что в себя включает Agile не всегда именно метод, это может быть подгруппа, свод правил, набор инструментов и, Боже упаси, фреймворк.

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

Что входит в методы:

1. 1992 – Crystal Methods. Позже в 1997 году упростили до Crystal. Скажем спасибо Алистеру Коберну, за его идеи в своём подходе, потому что именно они легли в основу начала движения Agile. В его методе мы также можем увидеть основы agile-манифеста, о нем чуть позже. Его подход базировался на принципах разумного улучшения, частой поставке кода и работа в группах 6-8 человек, активной коммуникации в группе разработчиков.

2. 1993 – Refactoring. Об этом методе можно прочитать в оригинале жми сюда

3. 1994 – Dynamic Systems Development Method (DSDM). Разработан консорциумом и отличнно раскрыт здесь

4. 1995 – Scrum and Pair Development. Вот он мой любимчик. Основан Джефом Сазерл

Как рассказать что такое Agile на заводе? Топ 5 самых популярных Agile-практик

Если оторваться от Хабра, заглянуть в реальную российскую компанию старше 30 лет и больше чем с тысячью сотрудников и произнести слово Agile, то реакция будет как минимум настороженная. Люди там уже слышали истории похожие на «Как рассказать бабушке» или «Как рассказать дедушке» и посмотрели все выступления Грефа, получили с десяток предложений внедрить гибкость за неделю, кто-то из сотрудников даже поработал год со Scrum, но остается один вопрос:

«Что с этим нам делать то, у нас из программирования только сайт?»

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.

Но вот парадокс — в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

_{*Из большого ежегодного опроса компаний от VersionOne}

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

Вместо определения. Что сказать про Agile, когда собрались разные люди из разных отделов

Agile — это не метод разработки программного обеспечения. Википедийные определения плохо годятся для понимания, если ты не разработчик.

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

Команда в игре «Что? Где? Когда?» существует по принципам Agile. Взаимодействиям отдана ключевая роль. Капитан выполняет роль заказчика продукта (верного ответа), 2-3 эрудита перебирают массивы информации, кто-то следит за временем, есть человек, который анализирует, задает вопросы и побуждает общение, любой может высказаться и привести к результату или все провалить, за пределами игры есть разбор полетов (ретроспектива).

Противовес Agile — это конвейерный (каскадный) метод с жесткой иерархией и точными задачами поставленными как можно ближе к SMART. По этим принципам в «Что? Где? Когда?» капитан должен был бы раздавать точные задачи — кому в каком направлении думать и пытаться собрать это в ответ. Каждый участник должен был бы соблюдать приличия и высказываться когда дойдет очередь. В случае провала нужно было бы кому-нибудь понизить мотивацию или уволить и принимать это решение будет капитан.

Главной причиной появления и развития Agile является то, что все больше проектов не имеют 100% понимания, что должно быть в конце. Расписать точные задачи попросту невозможно. И решили, что свободные взаимодействия важнее инструкций, а готовность к изменениям важнее планов.

Гибкие методологии — это ответ на неопределенность; до конца неизвестно, что нужно сделать и что должно получиться в результате. Казалось бы, а что непонятного в разработке, например, сайта или в строительстве дома или в приготовлении гамбургера в Макдональдсе? Эти проекты поставлены на поток, где неопределенность?

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

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

Хорошо, в изготовлении гамбургера в Макдональдсе нет никакой неопределенности. Процесс отработан за 70 лет и воспроизведен в 125 странах. Да, это конвейер, куда лучше не влезать с гибкостью. Agile не применим в хорошо отлаженных годами процессах. Правда, открытие нового ресторана по очень точной франшизе — это всегда уникальный проект. Где к месту будет итеративный подход, сокращение итераций, распределение ролей, открытое взаимодействие, визуализация проекта на Agile-доске, ретроспектива, ежедневные планерки.

Итого ключевые ценности Agile (манифест):

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

Что такое команды с ролями?

В привычной команде есть две роли: Начальник и Подчиненный, один умный другой дурак. В Agile принципиально важны три: Заказчик продукта, Методист, Участник команды.

В упрощенной форме:

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

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

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

Со стороны гибкая команда от привычной отличается именно наличием или отсутствием так называемого повествовательного диалога (narrative collaboration).

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

Главный вопрос: «Как управлять ресурсами когда все так гибко?»

Все эти рассказы про ответственные команды и истории появления метода воспринимаются как полная фигня, если нет ответа на вопросы:

«А как точнее управлять ресурсами?», «Как раньше понять, что в проекте ресурсов стало не хватать для окончания?», «Мы всегда ставили и распределяли задачи по исполнителям и могли прогнозировать результат, а что теперь?». Что бы рассказать про Agile, можно раскрыть только этот вопрос.

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

Есть несколько важных принципов и методов, явно направленных именно на прогнозирование ресурсов:

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

Вопросы предсказуемости результатов и управления приоритетами решаются именно за счет наглядности.

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

3. Короткие итерации (спринты). Этот подход, как никакой другой позволяет компаниям пробовать что-то из Agile. Руководство согласно на промежуточный результат через пару недель без того, чтобы влезать и всем проставлять задачи. Согласиться на такой режим работы на полгода было бы невозможно.

Спринт (итерация) — это отрезок времени в несколько недель. У нас чаще всего это 2 недели. Самое важное в спринте — это определение того, какой промежуточный результат должен быть получен. Этим результатом хорошо называть итерацию, например, «Выпуск досок с правами» или «Выпустить сайт на тест». Если работа идет по отрезкам времени, но каждый отрезок не приводит к какому-то конкретному результату, то это уже не итерационный подход.

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

Мы используем третий, но оценки бывают только 1h, 2h, 4h, 8h.

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

5. Burndown chart (график сгорания)

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

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

• самая частая ошибка — попытка попадать в оценки очень точно, команда перестает работать на результат
• самый успешный подход — заложить запас по времени, планировать на 80% ресурсов

Инсайд из самой большой, старой и известной seo-студии в России — они закладывают запас в ресурсах два раза, первый при обсуждении с клиентом, второй при внутреннем планировании.

Топ 5 самых популярных Agile-практик понятных всем

Еще раз подчеркну, Agile на базовом уровне применения — это просто. Нет никаких сверхсложных приемов, которые надо долго изучать. Ниже для примера приведено 5 самых популярных практик (по данным все того же опроса от VersionOne)

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

1. Итерационное планирование — спринты (90% команд используют)

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

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

2. Ежедневные планерки (88% команд используют)

Задача — чтобы каждый день команда подтверждала единое направление движение всех участников.

По классическому описанию каждый в команде раскрывает три вопроса:

Что сделано к этому моменту из спринта?

Что планируется на сегодня?

Какие проблемы возникли или что мешает?

По нашей практике это быстро надоедает командам и становится рутиной или формальной отчетностью. Что помогает:

Менять время планерки — 6 мес. утром, 6 мес. вечером.

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

Заказчик продукта, делиться историями о клиентах в начале планерки.

Обсуждать общие темы и только потом переходить к вопросам.

Не пускать на планерки никого кроме участников команды.

3. Ретроспективы (83% команд используют)

Совещание в конце итерации. Обсуждение, что получилось, а что не очень. Самая важная цель — сделать выводы о том, как меняться.

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

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

4. Итерационные показы (81% команд используют)

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

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

5. Короткие итерации (71% команд используют)

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

Это задача методиста, стоит вспоминать про это хотя бы раз в полгода.

Как понять ведется ли проект по Agile-методологии или еще нет?

Диаграмма того, сколько компаний меняют Agile под себя выглядит так:

Гибкость подхода распространяется и на сам подход. Это первое, что стоит узнать команде, если им предстоит стать гибче. Нельзя быть на 100% Agile, выполняя все предписания. Никто строго не соблюдает правила в чистом виде, на практике у каждой компании есть свои модификации.

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

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

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

P.S. Опрос: Agile в России 2017

В статье приводится несколько фактов о распространении Agile в мире, взятых из опроса от компании VersionOne.
Проблема в том, что эти данные имеют мало общего с нашей действительностью.
Мы в YouGile проводим большой опрос о гибкой методологии в России.

Примите участие — пройдите опрос «Agile в России 2017»

10 вопросов, 3 минуты

Результаты обязательно будут опубликованы на Хабрахабр.

Методология Agile в двух словах 

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

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

Потребность в гибкой методологии

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

Что такое Agile методология?

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

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

Короткие итерации

Унаследованные процессы разработки программного обеспечения, такие как Waterfall, имели такие фазы, как сбор требований, планирование, проектирование, кодирование, тестирование и выпуск.

Методология Agile, напротив направлена на предоставление всего выпуска в виде приращений за пару недель и полностью функциональной версии за несколько месяцев.

Коммуникация, общение внутри команды

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

Обратная связь

Так как команда предоставляет функциональность небольшими порциями, они получают быструю обратную связь от Dev, QA, PO и клиентов. Именно так методология Agile помогает регулярно отслеживать ход цикла разработки.

Доверие

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

Согласование

Гибкая команда может быстро выровнять и настроить процесс в зависимости от необходимости. Принцип KIS или Keep It Simple — это то, чем они должны руководствоваться.

Сроки разработки гибкого программного обеспечения

Индустрия программного обеспечения пережила небольшой кризис в начале 1990-х годов. Некоторые назвали это «кризисом разработки приложений», а некоторые назвали его «задержкой доставки приложений». Проблема заключалась в неспособности удовлетворить потребности клиентов. Кроме того, процессы в то время занимали много времени. Они использовали подход, основанный на временной шкале, когда процесс разработки был последовательным, и клиентам приходилось ждать до самого последнего шага. Чем больше время доставки, тем больше у клиентов шансов изменить свои потребности. Таким образом, к тому времени, когда заявка была готова, первоначальные требования утратили бы актуальность.

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

Что такое Agile манифест?

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

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

Agile манифест подразумевает четкую и измеримую структуру и поощряет итеративную разработку, совместную работу и принятие изменений.

Вы можете прочитать о ценностях и принципах Agile манифеста ниже:

Ценности Agile:

1. Доверяйте людям и предпочитайте взаимодействие, а не процессы и инструменты
2. Сосредоточьтесь на предоставлении рабочего программного обеспечения, а не написанию документации
3. Больше вовлечения клиентов, чем просто обсуждения условий
4. Готовность приспосабливаться к изменениям вместо того, чтобы быть жестко идти по плану

Принципы Agile:

1. Короткие циклы разработки, быстрая доставка и довольный клиент
2. Принять изменения объема, пересмотреть цели
3. Непрерывная поставка рабочего программного обеспечения
4. Сотрудничество между всеми заинтересованными сторонами на протяжении всего проекта
5. Показать доверие к вовлеченным людям
6. Разрешить прозрачные взаимодействия
7. Рабочее программное обеспечение определяет прогресс
8. Agile процессы для нормализации скорости разработки
9. Связь между дизайном и технической реализацией
10. Простота
11. Самоорганизация — ключ к хорошей архитектуре, требованиям и дизайну.
12. Пересмотр, как стать более эффективным

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

Agile Управление проектами

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

• Сотрудничество,
• Гибкость,
• Постоянное улучшение и
  Качественные результаты.

Он использует шесть основных «результатов» для мониторинга прогресса и выпуска продукта.

Видение продукта

Резюме, которое определяет цели продукта.

Дорожная карта продукта

Общий обзор требований к реализации.

Backlog продукта

Полный список возможностей, которые будут добавлены в проект.

План выпуска

Графический документ, показывающий ход релиза.

Backlog cпринта

Список пользовательских историй, выбранных в последнем спринте.

Инкремент

Рабочий продукт с функциями, реализованными в текущем цикле спринта.

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

Наиболее известные из них — Scrum и Kanban, поддерживающие жизненный цикл разработки Agile.

Подводя итоги

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

Как рассказать что такое Agile на заводе? Agile методология.

18 Oct 2017

Если заглянуть в реальную российскую компанию старше 30 лет и больше чем с тысячью сотрудников и произнести слово Agile, то реакция будет как минимум настороженная. Люди там уже слышали истории похожие на «Как рассказать бабушке» или «Как рассказать дедушке» и посмотрели все выступления Грефа, получили с десяток предложений внедрить гибкость за неделю, кто-то из сотрудников даже поработал год со Scrum, но остается один вопрос:

«Что с этим нам делать то, у нас из программирования только сайт?»

В итоге примерно для 100% компаний Agile смахивает на шарлатанство.

Но вот парадокс — в мире 77% компаний*, использующих Agile в проектах, занимаются совсем не разработкой программного обеспечения.

*Из большого ежегодного опроса компаний от VersionOne

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

Вместо определения. Что сказать про Agile, когда собрались разные люди из разных отделов

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

Команда в игре «Что? Где? Когда?» существует по принципам Agile. Взаимодействиям отдана ключевая роль. Капитан выполняет роль заказчика продукта (верного ответа), 2-3 эрудита перебирают массивы информации, кто-то следит за временем, есть человек, который анализирует, задает вопросы и побуждает общение, любой может высказаться и привести к результату или все провалить, за пределами игры есть разбор полетов (ретроспектива).

Противовес Agile — это конвейерный (каскадный) метод с жесткой иерархией и точными задачами поставленными как можно ближе к SMART. По этим принципам в «Что? Где? Когда?» капитан должен был бы раздавать точные задачи — кому в каком направлении думать и пытаться собрать это в ответ. Каждый участник должен был бы соблюдать приличия и высказываться когда дойдет очередь. В случае провала нужно было бы кому-нибудь понизить мотивацию или уволить и принимать это решение будет капитан.

Главной причиной появления и развития Agile является то, что все больше проектов не имеют 100% понимания, что должно быть в конце. Расписать точные задачи попросту невозможно. И решили, что свободные взаимодействия важнее инструкций, а готовность к изменениям важнее планов.

Гибкие методологии — это ответ на неопределенность; до конца неизвестно, что нужно сделать и что должно получиться в результате. Казалось бы, а что непонятного в разработке, например, сайта или в строительстве дома или в приготовлении гамбургера в Макдональдсе? Эти проекты поставлены на поток, где неопределенность?

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

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

Хорошо, в изготовлении гамбургера в Макдональдсе нет никакой неопределенности. Процесс отработан за 70 лет и воспроизведен в 125 странах. Да, это конвейер, куда лучше не влезать с гибкостью. Agile не применим в хорошо отлаженных годами процессах. Правда, открытие нового ресторана по очень точной франшизе — это всегда уникальный проект. Где к месту будет итеративный подход, сокращение итераций, распределение ролей, открытое взаимодействие, визуализация проекта на Agile-доске, ретроспектива, ежедневные планерки.

Итого ключевые ценности Agile (манифест):

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

Что такое команды с ролями?

В привычной команде есть две роли: Начальник и Подчиненный, один умный другой дурак. В Agile принципиально важны три: Заказчик продукта, Методист, Участник команды.

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

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

Со стороны гибкая команда от привычной отличается именно наличием или отсутствием так называемого повествовательного диалога (narrative collaboration).
Если идет обсуждение вопроса «Как реализовать продукт?» на всех уровнях, значит команда гибкая. Если ищут кто виноват, что не выполнен список конкретных задач, значит все как обычно.

Главный вопрос: «Как управлять ресурсами когда все так гибко?»

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

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

Есть несколько важных принципов и методов, явно направленных именно на прогнозирование ресурсов:

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

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

3. Короткие итерации (спринты). Этот подход, как никакой другой позволяет компаниям пробовать что-то из Agile. Руководство согласно на промежуточный результат через пару недель без того, чтобы влезать и всем проставлять задачи. Согласиться на такой режим работы на полгода было бы невозможно.
Спринт (итерация) — это отрезок времени в несколько недель. У нас чаще всего это 2 недели. Самое важное в спринте — это определение того, какой промежуточный результат должен быть получен. Этим результатом хорошо называть итерацию, например, «Выпуск досок с правами» или «Выпустить сайт на тест». Если работа идет по отрезкам времени, но каждый отрезок не приводит к какому-то конкретному результату, то это уже не итерационный подход.

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

Мы используем третий, но оценки бывают только 1h, 2h, 4h, 8h.

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

5. Burndown chart (график сгорания)
Очень простая вещь — это график с двумя линиями; первая — сколько времени сгорело и это всегда прямая, на второй — сколько задач в пересчете на ресурсы закрыто и тут возможны колебания. Фактически это графический ответ на вопрос идет ли команда по плану или отстает.

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

• самая частая ошибка — попытка попадать в оценки очень точно, команда перестает работать на результат
• самый успешный подход — заложить запас по времени, планировать на 80% ресурсов

Инсайд из самой большой, старой и известной seo-студии в России — они закладывают запас в ресурсах два раза, первый при обсуждении с клиентом, второй при внутреннем планировании.

Топ 5 самых популярных Agile-практик понятных всем

Еще раз подчеркну, Agile на базовом уровне применения — это просто. Нет никаких сверхсложных приемов, которые надо долго изучать. Ниже для примера приведено 5 самых популярных практик (по данным все того же опроса от VersionOne)

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

1. Итерационное планирование — спринты (90% команд используют)
Работать небольшими забегами с промежуточным результатом — хорошая практика. Спринт — это несколько недель. Слишком короткие или слишком длинные отрезки — плохо. Одинаковый интервал на все случаи жизни тоже не годится. У спринта должна быть максимально точная цель, исходя из этого и определяется длительность.
Самый частый ошибкой является то, что команды привыкают просто расписывать задачи раз в две недели, теряются процессы постановки промежуточных целей и подведение итогов в конце. Работа сваливается в обычный поток задач с обновлением раз в спринт. Проблему должен решать методист.

2. Ежедневные планерки (88% команд используют)
Задача — чтобы каждый день команда подтверждала единое направление движение всех участников.
По классическому описанию каждый в команде раскрывает три вопроса:

• Что сделано к этому моменту из спринта?
• Что планируется на сегодня?
• Какие проблемы возникли или что мешает?

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

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

4. Итерационные показы (81% команд используют)
Это демонстрация от команды раз в несколько итераций результатов проекта, как правило в виде выступления. Главный смысл в том, чтобы была «сессия» и ничего страшного, если это станет похоже на отчетность перед руководством.
Главная трудность в том, чтобы собрался кто-то кроме команды, да еще и понимал смысл происходящего. По нашей практике приживается только при очень крутом руководстве.

5. Короткие итерации (71% команд используют)
Смысл в том, что нужно постоянно стараться сокращать цикл получения маленьких промежуточных результатов. Если этого не делать, циклы будут естественным образом расти или будет постоянными, независимо от промежуточных целей. Чем короче цикл, тем меньше ошибок при итерационном планировании.
Это задача методиста, стоит вспоминать про это хотя бы раз в полгода.

Как понять ведется ли проект по Agile-методологии или еще нет?

Диаграмма того, сколько компаний меняют Agile под себя выглядит так:

Гибкость подхода распространяется и на сам подход. Это первое, что стоит узнать команде, если им предстоит стать гибче. Нельзя быть на 100% Agile, выполняя все предписания. Никто строго не соблюдает правила в чистом виде, на практике у каждой компании есть свои модификации.

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

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

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

Что такое гибкая разработка программного обеспечения?

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

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

Гибкая разработка программного обеспечения

Scrum и другие ведущие гибкие методы

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

Scrum Agile-зонт

Scrum

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

Постное

Lean возникла из производственной системы Toyota, или TPS, которая произвела революцию в производстве физических товаров в 1950-х, 60-х годах и позже. Lean сохраняет свои позиции в производстве, но также нашла новые применения в интеллектуальной работе, помогая предприятиям во всех отраслях устранять отходы, улучшать процессы и стимулировать инновации .Разработка программного обеспечения — естественное применение методологии Lean, потому что, как и производство, она обычно следует определенному процессу, имеет определенные условия принятия и приводит к получению материальной ценности. Ключевые концепции, которыми руководствуется вся практика методологии бережливого производства, которую мы называем столпами бережливого производства. Их:

• Постоянное совершенствование
• Уважение к людям
• Легкое лидерство

Канбан

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

Канбан основан на 3 основных принципах:

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

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

Метод разработки динамических систем (DSDM)

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

DSDM — это методология, которая ставит график и качество выше функциональности, фиксирует стоимость, качество и время на начальном этапе и использует метод определения приоритетов MoSCoW, который разбивает проект на четыре различных типа требований:

• Должен иметь (M)
• Должно быть (S)
• Может быть (C)
• Не будет (Вт)

В основе DSDM Atern лежит восемь принципов [13].Эти принципы направляют команду на то отношение, которое они должны занять, и образ мышления, которого они должны придерживаться для последовательной работы.

1. Ориентация на потребности бизнеса
2. Доставить вовремя
3. Сотрудничать
4. Никогда не идите на компромисс с качеством
5. Построить постепенно за счет твердого фундамента
6. Итеративная разработка
7. Общайтесь постоянно и четко
8. Продемонстрировать контроль

Экстремальное программирование

Extreme Programming (XP), первоначально описанная Кентом Беком, стала одной из самых популярных и спорных методологий Agile.XP — это дисциплинированный подход к быстрой и непрерывной доставке высококачественного программного обеспечения. Он предназначен для повышения качества программного обеспечения и повышения скорости его отклика перед лицом меняющихся требований клиентов. Он способствует активному участию клиентов, быстрой обратной связи, непрерывному тестированию, непрерывному планированию и тесной командной работе для предоставления работающего программного обеспечения с очень частыми интервалами, обычно каждые 1-3 недели.

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

Исходный метод XP основан на четырех простых ценностях — простоте, общении, обратной связи и смелости.

Также имеется двенадцать вспомогательных практик:

• Планирование игры
• Небольшие релизы
• Приемочные испытания заказчиком
• Простой дизайн
• Программирование пар
• Разработка через тестирование
• Рефакторинг
• Непрерывная интеграция
• Коллективный код собственности
• Стандарты кодирования
• Метафора
• Устойчивый темп

Экстремальное программирование

Разработка с использованием функций (FDD)

Feature-Driven Development (FDD) был представлен в 1997 году Джеффом Де Лука, когда он работал в проекте разработки программного обеспечения для крупного сингапурского банка.Это итеративный и инкрементный процесс разработки программного обеспечения, а также гибкий метод разработки программного обеспечения. FDD объединяет ряд признанных в отрасли передовых методов в единое целое. Эти практики основаны на функциональных возможностях, которые ценятся клиентом. Его основная цель — постоянно и своевременно доставлять реальное, работающее программное обеспечение. Преимущество использования FDD заключается в том, что его можно масштабировать даже для больших команд благодаря концепции «достаточно дизайна на начальном этапе» (JEDI). Это отличное решение для сохранения контроля над гибкими, инкрементальными и по своей сути сложными проектами, поскольку он ориентирован на функции.Он состоит из пяти основных видов деятельности:

1. Разработка общей модели
2. Создание списка функций
3. Планирование по признаку
4. Проектирование по признаку
5. Строение по признаку.

Разработка на основе функций (FDD)

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

Кристалл

Методы Crystal — это семейство методологий (семейство Crystal), разработанное Алистером Кокберном в середине 1990-х годов. Методы взяты из многолетних исследований и интервью Кокберна с командами. Исследование Кокберна показало, что команды, с которыми он беседовал, не следовали формальным методологиям, но все же реализовывали успешные проекты. Семья Кристал — это способ Кокберна каталогизировать то, что они сделали, что сделало проекты успешными. Кристаллические методы ориентированы на:

• Люди
• Взаимодействие
• Сообщество
• Навыки
• Таланты
• Связь

Agile Manifesto

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

Agile манифест

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

Принципы Agile Manifesto

Дополняя Agile Manifesto, Agile Alliance также определил набор из 12 основных принципов, которые обеспечивают руководство и более подробное объяснение в дополнение к Agile Manifesto:

Принципы Agile Manifesto

1. Нашим наивысшим приоритетом является удовлетворение потребностей клиентов путем своевременной и непрерывной поставки ценного программного обеспечения.
2. Приветствуем меняющиеся требования даже на поздних стадиях разработки. Изменения в гибких процессах используются для обеспечения конкурентного преимущества клиента.
3. Поставляйте работающее программное обеспечение часто, от пары недель до пары месяцев, с предпочтением более коротких сроков.
4. Деловые люди и разработчики должны ежедневно работать вместе на протяжении всего проекта.
5. Создавайте проекты вокруг мотивированных людей. Обеспечьте им среду и поддержку, в которых они нуждаются, и доверьте им выполнение работы.
6. Самый действенный и действенный метод передачи информации команде разработчиков и внутри нее — это личное общение.
7. Работающее программное обеспечение — главный показатель прогресса.
8. Agile-процессы способствуют устойчивому развитию.
9. Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп неограниченное время.
10. Постоянное внимание к техническому совершенству и хороший дизайн повышают маневренность.
11. Простота — искусство максимизировать объем незавершенной работы — очень важна.
12. Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами. Через регулярные промежутки времени команда размышляет о том, как стать более эффективной, а затем соответствующим образом настраивает и корректирует свое поведение.

Сводка

Agile Development — одно из самых модных словечек в индустрии разработки программного обеспечения, которое представляет собой другой способ управления проектами разработки программного обеспечения. Это не конкретный метод разработки программного обеспечения, а общий термин для набора методов и практик, основанных на ценностях и принципах, выраженных в Agile Manifesto.Решения развиваются в результате сотрудничества между самоорганизующимися кросс-функциональными командами, использующими подходящие методы для своего контекста.

.

Что такое Agile? Что такое скрам?

Agile — это образ мышления и философия, которые описывают набор принципов в Agile Manifesto. С другой стороны, Scrum — это структура, которая предписывает роли, события, артефакты и правила / рекомендации для реализации этого образа мышления. Другими словами, Agile — это образ мышления, а Scrum — это структура, которая предписывает процесс реализации гибкой философии.

Зонтик Agile

Agile — это общий термин для набора методов и практик, основанных на ценностях и принципах, выраженных в Agile Manifesto, который представляет собой образ мышления, который позволяет командам и компаниям внедрять инновации, быстро реагировать на меняющийся спрос, одновременно снижая риски.Организации могут быть гибкими, используя многие доступные фреймворки, такие как Scrum, Kanban, Lean, Extreme Programming (XP) и т. Д.

Scrum Umbrella

Что такое Agile?

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

Что такое Scrum?

Scrum и Agile — это не одно и то же, но scrum — один из гибких процессов. Они основаны на итеративной разработке. Требования и решения Agile, полученные в результате объединения кросс-функциональных групп и групп самоорганизации, и при правильном внедрении могут помочь командам решать сложные проблемы, постепенно предоставляя продукты максимальной ценности при одновременном снижении рисков.

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

Как работает Scrum?

Процесс Scrum отличается от других Agile-процессов особыми концепциями и практиками, разделенными на три категории ролей (владелец продукта, мастер схватки, команда разработчиков и другие заинтересованные стороны), события, артефакты и правила.

Чтобы запустить процесс Scrum, владелец продукта создает список желаемых приоритетов, который называется бэклог продукта. Во время планирования спринта размер бэклога определяется сложностью и бизнес-ценностью (приоритет). Владелец продукта (клиент) и команда разработчиков определяют, какие элементы невыполненной работы нужно добавить в спринт. У команды есть определенное количество времени (называемое спринтом, обычно от двух до четырех недель), чтобы завершить свою работу, но она собирается каждый день для оценки своего прогресса (ежедневный скрам). Попутно Скрам Мастер помогает команде сосредоточиться на своей цели.В конце спринта команда проверяет свой прогресс, показывает клиенту рабочий продукт и рассматривает, что прошло хорошо или что им нужно улучшить в следующем спринте. Затем цикл повторяется.

Структура Agile Scrum

Обратите внимание, что:

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

.