Agile Глоссарий

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

Agile
[Гибкая методология разработки]
серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля.
Scrum 
[Скрам]
это рабочая среда, используемая для гибкого управлении проектами. Scrum проекты реализуется через серию циклов (итераций) длительностью 2-8 недель каждый. Scrum позволяет быстро адаптировать проект под изменения рынка и бизнеса.
Crystal Clear
это легковесная гибкая методология, предназначена для небольших команд в 6-8 человек для разработки некритичных бизнес-приложений. Как и все гибкие методологии Crystal Clear больше опирается на людей, чем на процессы и артефакты. Crystal Clear использует три обязательные методики: Частая поставка продукта,  Улучшения через рефлексию, Личные коммуникации.
Extreme Programming (XP)
[Экстремальное программирование]
это упрощенная методология организации разработки программ для небольших и средних по размеру команд разработчиков, занимающихся созданием программного продукта в условиях неясных или быстро меняющихся требований. Основными целями XP являются повышение доверия заказчика к программному продукту путем предоставления реальных доказательств успешности развития процесса разработки и резкое сокращение сроков разработки продукта. При этом XP сосредоточено на минимизации ошибок на ранних стадиях разработки. Это позволяет добиться максимальной скорости выпуска готового продукта и даёт возможность говорить о прогнозируемости работы. Практически все приемы XP направлены на повышение качества программного продукта. Парное программирование является одной из практик XP.
Dynamic Systems Development Method (DSDM)
[Метод разработки динамических систем]
метод основан на концепции быстрой разработки приложений. Представляет собой итеративный и инкрементный подход, который придаёт особое значение продолжительному участию в процессе пользователя/потребителя.
Feature-driven development (FDD)
[Функциональноориентированная разработка]
по данной методологии разработка ведется в пять этапов: 1. Построение модели; 2. Создание списка функций; 3. Планирование реализации функций 4. Создание архитектуры для функций; 5. Реализация функций.
Достоинством этой методологии стоит считать изначальную поддержку больших групп разработчиков, так как отдельные функции разрабатываются отдельными мини- командами во главе с ведущим разработчиком. Разделение и координация происходят на на этапах 3-4.
Test Driven Development (TDD)
[Разработка через тестирование]
техника разработки программного обеспечения, которая основывается на повторении очень коротких циклов разработки: сначала пишется тест, покрывающий желаемое изменение, затем пишется код, который позволит пройти тест, и под конец проводится рефакторинг нового кода к соответствующим стандартам.
Kanban
[Канбан]
это метод управления бережливыми производственными линиями, использующий информационные карточки для передачи заказа на изготовление с последующего процесса на предыдущий.
Lean
[Бережливая разработка программного обеспечения]
это методология “обезжиривания” бизнес-процессов, при которой идет сокращение неизбежных потерь, исключение бесполезных действий и выполнение других манипуляций, направленных на увеличение скорости работы компании, количества производимой продукции или услуг и, как следствие, роста её доходов.
Team
[Команда разработчиков]
команда разработчиков состоит из профессионалов, выполняющих работу по разработке потенциально “готового” к выпуску Инкремента продукта в конце каждого Спринта. Оптимальный размер команды разработчиков 7±2 человек, которые реализуют требования владельца продукта. 
Product Owner
[Владелец продукта]
ответственен за достижение максимальной ценности продукта и работы, исполняемой Командой Разработчиков. Способы, которыми он этого достигает, могут отличаться и зависят от организаций, Скрам Команд и индивидуумов.
Владелец Продукта является единственным человеком в Команде, отвечающим за Журнал Требований к Продукту. Владелец Продукта это только один человек, а не группа.
Scrum Master
[Скрам-мастер]
ответственен за то, чтобы Скрам был гарантированно понят всеми участниками и работал. Скрам Мастер достигает этого, следя за тем, чтобы все участники Команды придерживались теории, практик и правил Скрама. Скрам Мастер является слугой-лидером для Скрам Команды. Скрам Мастер также помогает людям, не входящим в состав Скрам Команды понять, какие из их взаимодействий со Скрам Командой являются полезными, а какие нет.
Product Backlog
[Журнал Требований к Продукту]
приоритезированный список требований с оценкой трудозатрат. Обычно он состоит из бизнес-требований, которые приносят конкретную бизнес-ценность и называются элементы беклога. Ответственность за Журнал Продукта несет Владелец Продукта, включая его содержание, доступность и упорядочение.
Sprint
[Спринт]
имеет временные рамками в один месяц или менее, в результате которого создается ценный и потенциально “готовый” к выпуску Инкремент продукта. Длина Спринта является постоянной на протяжении всего периода разработки. Следующий Спринт начинается сразу же по окончании предыдущего. Спринт состоит из Планирования Спринта, Ежедневных Скрамов, работы по разработке, встрече по Обзору Спринта, а также Ретроспективы Спринта.
Burn down chart
[Диаграмма сгорания задач]
диаграмма, показывающая количество сделанной и оставшейся работы в спринте.
Обновляется ежедневно с тем, чтобы в простой форме показать подвижки в работе над спринтом.
Scrum meeting
[Скрам-митинг]
собрание членов команды (с возможностью приглашения владельца продукта) для синхронизации деятельности команды и обозначения проблем. Каждый член команды отвечает на три вопроса: Что было сделано с предыдущего скрам-митинга? Какие есть проблемы? Что будет сделано к следующему скрам митингу?
Запись опубликована в рубрике Agile. Теория. Добавьте в закладки постоянную ссылку.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *