Agile методология описание: методология, метод или философия? — статья в блоге ScrumTrek

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

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

Онлайн-диаграмма Ганта с легкостью выполнит все эти задачи и упростит работу с проектом всем его участникам. 

Онлайн диаграмма Ганта GanttPRO

Ведите проекты, управляйте временем, ресурсами и финансами.

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

А какие Agile методологии управления проектами предпочитает ваша команда? Делитесь в комментариях ниже.

5 7 голоса

Рейтинг статьи

StecPoint — Как работает agile-методология?

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

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

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

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

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

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

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

Каким бы ни было видение, product owner отвечает за его определение, а затем работает с командой разработчиков, чтобы воплотить его в жизнь.

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

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

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

В agile-командах часто присутствуют другие роли:

• Техлиды или тимлиды обсуждают с владельцем продукта архитектуру, последовательность, другие технологические аспекты и вопросы безопасности. Техлиды имеют широкие обязанности, которые могут включать оценку эффективности работы и планирование деталей реализации вместе с командой.
• Scrum-мастера часто обучают новые команды процессам, обязанностям и инструментам agile. В обязанности scrum-мастера может входить устранение блоков, препятствующих прогрессу, анализ подходов к повышению скорости работы команды и подготовка бэклога.
• Бизнес-аналитики работают в партнерстве с владельцем продукта. В их обязанности часто входит создание схем будущего продукта, документирование пользовательских историй и анализ результатов тестирования. Бизнес-аналитики особенно полезны, когда команды разработчиков программного обеспечения разрабатывают микросервисы и другие технические продукты, и когда бизнес-аналитик обладает большими знаниями в области разработки программного обеспечения, чем владелец продукта.

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

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

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

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

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

• Планирование — product owner делится приоритетами, а команда решает, какой объем работы она может выполнить в течение спринта.  
• Митинги — помогают командам обсуждать статус пользовательских историй; члены команды делятся своими ежедневными целями, и каждый может эскалировать блоки, препятствующие прогрессу команды.
• Демо — встречи в конце спринта, на которых product owner оценивает результаты.
• Ретроспектива  — команда обсуждает, что было сделано хорошо, а что требует улучшения в процессах agile и разработки программного обеспечения.

Сегодня многие лучшие технические практики включают определение жизненного цикла разработки программного обеспечения (SDLC) и внедрение devops-процессов. SDLC обеспечивает руководство по написанию кода, управлению программными активами и разработке технических стандартов. Devops-автоматизация, такая как CI/CD, инфраструктура как код (IaC) и непрерывное тестирование, обеспечивает более надежный путь к созданию качественного продукта.

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

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

Agile-команды обычно используют такие инструменты, как Jira, Azure DevOps и Digital.ai для совместной работы над agile-бэклогами и канбан-досками. Эти инструменты помогают agile-командам определять приоритеты работы, фиксировать требования, дополнять пользовательские истории, просматривать отчеты и автоматизировать рабочие процессы с помощью контроля версий, CI/CD и других инструментов.  
Большинство специалистов рекомендуют начинать agile-практику с четко определенных бизнес-целей, нескольких команд и ограниченного, оптимально подобранного инструментария. Задача руководителей организаций состоит в том, чтобы найти правильный баланс разнообразных команд, принципов самоорганизации, стандартов, инструментов и интеграций, которые позволят их организациям создавать, расширять, масштабировать и поддерживать технологические возможности.

Гибкая методология: обзор | Зенкит

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

Согласно отчету Verison One о состоянии Agile за 2020 год, Agile никуда не денется. Принципы и практики методологии Agile масштабируются как внутри команды, так и в глобальном масштабе. Основные выводы из отчета:

• «95 % респондентов сообщают, что их организации применяют методы гибкой разработки».
• «81% респондентов заявили, что в их организациях есть Agile-команды, в которых члены одной и той же команды не все работают в одном месте (т. е. не в одном месте)».
• «71% респондентов заявили, что в их организациях применяется Agile с несколькими совместными командами, которые сотрудничают через географические границы».

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

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

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

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

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

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

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

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

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

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

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

Поскольку время, деньги и усилия были потрачены впустую, а некоторые проекты даже были отменены на полпути, профессиональные лидеры сообщества разработчиков программного обеспечения решили, что пришло время для нового, обновленного подхода. Затем, в 2001 году, в заснеженной лыжной базе в штате Юта собралась группа специалистов-практиков, чтобы обсудить отраслевые практики. Хотя основное внимание на встрече было уделено обсуждению циклов разработки, некоторые участники уже обдумывали идею нового метода разработки программного обеспечения. Все они стремились закрепить процесс, узаконивающий то, что практикуется, и так появился Манифест Agile.

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

Ценности и принципы «Манифеста гибкой разработки программного обеспечения»:

Значения Agile-манифеста:

1. 1. Индивиды и взаимодействие через процессы и инструменты
   2. Рабочее программное обеспечение поверх исчерпывающей документации
   3. Сотрудничество с клиентами по поводу переговоров по контракту
   4. Реагирование на переход по плану

Принципы Agile-манифеста:

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

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

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

Шаги методологии Agile

Вот результаты гибкого управления проектами:

1. 1. Заявление о видении продукта: Краткое изложение, в котором формулируются цели продукта.
   2. Дорожная карта продукта: Общее представление требований, необходимых для реализации видения продукта.
   3. Задолженность по продукту: Упорядоченный по приоритету, это полный список того, что необходимо для вашего проекта.
   4. План выпуска: График выпуска рабочего продукта.
   5. Журнал спринта: Пользовательские истории (требования), цели и задачи, связанные с текущим спринтом.
   6. Приращение: Функционал рабочего продукта, который представляется заинтересованным сторонам в конце спринта и потенциально может быть передан заказчику.

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

Двумя наиболее популярными из них, поддерживающими жизненный цикл Agile-разработки, являются Scrum и Kanban.

Scrum — это Agile-фреймворк, который используется для реализации идей Agile-разработки программного обеспечения. Это самая популярная Agile-инфраструктура, используемая в компаниях . Созданный Джеффом Сазерлендом и Кеном Швабером (которые также были частью 13 человек, закрепивших Манифест Agile), он включает в себя пять ценностей: приверженность, смелость, сосредоточенность, открытость и уважение. Его цель — разрабатывать, поставлять и поддерживать сложные продукты посредством сотрудничества, ответственности и итеративного прогресса.

Что отличает Scrum от других методологий Agile, так это роли, события и артефакты, из которых он состоит и с которыми он работает. Вот какие они:

Роли в Скрам-команде

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

Скрам-события

• Спринт : В Scrum спринт — это короткий период времени, в течение которого команда разработчиков работает над выполнением определенных задач, этапов или результатов. Спринты в гибкой методологии, также известные как «итерации», по существу делят график проекта на удобоваримые временные блоки, в течение которых могут быть достигнуты более мелкие цели. Сроки не превышают одного календарного месяца и являются постоянными на протяжении всего процесса разработки.
• Планирование спринта : Место, где вся команда Scrum собирается — в начале каждого спринта — для планирования предстоящего спринта.
• Ежедневный Скрам : 15-минутное собрание с ограниченным временем, проводимое в одно и то же время каждый день Спринта, на котором обсуждаются достижения предыдущего дня, а также ожидания на следующий день.
• Обзор Спринта : Неформальное собрание, проводимое в конце каждого Спринта, на котором Скрам-команда представляет свой Инкремент заинтересованным сторонам и обсуждает отзывы.
• Ретроспектива Спринта : Встреча, на которой Скрам-команда размышляет о работе предыдущего Спринта и устанавливает улучшения для следующего Спринта.

Артефакты Скрама

• Бэклог продукта : Управляется владельцем продукта, здесь перечислены все требования, необходимые для жизнеспособного продукта, в порядке приоритета. Включает возможности, функции, требования, усовершенствования и исправления, разрешающие внесение любых изменений в продукт в будущих выпусках.
• Незавершенная работа спринта : список задач и требований, которые необходимо выполнить в течение следующего спринта. Иногда сопровождается доской задач Scrum, которая используется для визуализации хода выполнения задач в текущем спринте и любых изменений, которые вносятся в формате «Делать, Делать и Готово».

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

Гибкая методология Канбан включает шесть общих практик:

1. 1. Визуализация
   2. Ограничение незавершенного производства
   3. Управление потоком
   4. Явное указание политик
   5. Использование контуров обратной связи
   6. Совместная или экспериментальная эволюция

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

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

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

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

Преимущества Lean Agile

• Меньше времени теряется
• Снижение затрат
• Повышение качества работы

Принципы Lean Agile

Методология Lean Agile включает 5 основных принципов:

• Идентифицировать значение
• Сопоставьте поток создания ценности
• Создать поток
• Установка вытяжной системы
• Стремись к совершенству

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

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

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

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

Кристалл

Crystal включает в себя семейство Agile-методологий, включая Crystal Clear, Crystal Yellow и Crystal Orange. Их уникальные характеристики определяются такими факторами, как размер команды, критичность системы и приоритеты проекта. Ключевые компоненты включают командную работу, общение и простоту, а также размышления для регулярной корректировки и улучшения процесса разработки. Эта структура Agile указывает, как для каждого проекта может потребоваться индивидуальный набор политик, практик и процессов для соответствия конкретным характеристикам проекта.

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

DSDM — это пример методологии Agile, ориентированный на полный жизненный цикл проекта. Он был создан в 1994 году после того, как пользователи Rapid Application Development (RAD) захотели большего контроля и дисциплины в этом итеративном способе работы. Философия компании, основанная на восьми принципах, заключается в том, что «любой проект должен быть направлен на четко определенные стратегические цели и направлен на скорейшее получение реальной выгоды для бизнеса».

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

• Профессиональные семинары
• Моделирование и итеративная разработка
• МОСКВА Приоритизация
• Таймбоксинг

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

Функционально-ориентированная разработка (FDD)

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

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

1. 1. Объектное моделирование предметной области
   2. Разработка по функции
   3. Владение компонентом/классом
   4. Специализированные группы
   5. Проверки
   6. Управление конфигурацией
   7. Обычные сборки
   8. Видимость прогресса и результатов

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

Сотрудничество с клиентами

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

Пользовательские истории

Инструмент, используемый для объяснения функции программного обеспечения с точки зрения конечного пользователя. Цель пользовательской истории — создать упрощенное описание требования. Это помогает представить тип пользователя продукта, то, что они хотят, и причины для этого. Распространенный формат User Story:

Как [роль] я хочу [особенность], потому что [причина].

Непрерывная интеграция

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