Visual Paradigm Desktop | 
Visual Paradigm Online
Студенты-инженеры, вступающие в индустрию разработки программного обеспечения, сталкиваются с ландшафтом, определяемым быстрыми изменениями и итеративной доставкой. Методология, лежащая в основе большинства современных циклов разработки, — это гибкая разработка. Понимание специфической лексики, связанной с этой структурой, — это не просто академическое упражнение; это профессиональная необходимость. Данное руководство предоставляет всесторонний разбор ключевых терминов, обеспечивая ясность как для студентов, так и для профессионалов.
Независимо от того, участвуете ли вы в университетском проекте по итоговой аттестации или присоединяетесь к корпоративной инженерной команде, язык гибкой разработки облегчает коммуникацию. Он устанавливает общее понимание рабочих процессов, стандартов качества и динамики команды. В следующих разделах рассматриваются основные компоненты, роли и артефакты, составляющие экосистему гибкой разработки.
Прежде чем углубляться в конкретные термины, крайне важно понять их происхождение. Манифест гибкой разработки был опубликован в 2001 году группой разработчиков программного обеспечения. Он ставит во главу угла людей и взаимодействие перед процессами и инструментами. Он ценит рабочее программное обеспечение перед всесторонней документацией. Он подчеркивает сотрудничество с клиентом перед переговорами по контракту. Он акцентирует внимание на способности реагировать на изменения, а не на строгое следование плану.
Эти четыре ценности поддерживаются двенадцатью принципами. Эти принципы руководят процессом принятия решений во время разработки. Они выступают за частую доставку программного обеспечения, приветствие изменяющихся требований и поддержание устойчивого темпа. Для студентов-инженеров понимание этих ценностей — первый шаг к эффективной практике.
Разные фреймворки организуют команды по-разному, но наиболее распространенной структурой является Scrum. В этом разделе описываются конкретные обязанности в рамках этой структуры.
Продуктовый владелец представляет голос клиента и бизнеса. Он отвечает за максимизацию ценности продукта, который получается в результате работы разработческой команды. Эта роль включает в себя управление продуктовым бэклогом.
Мастер Скрума служит команде, обеспечивая соблюдение процесса. Он не является традиционным менеджером, а скорее посредником и наставником. Его внимание сосредоточено на устранении препятствий, которые мешают прогрессу команды.
Это группа профессионалов, которые выполняют непосредственную работу по доставке приращения. Они межфункциональные, то есть обладают всеми навыками, необходимыми для создания продукта без внешних зависимостей. Они саморегулируемые, то есть сами решают, как выполнять работу.
Артефакты представляют работу или ценность. Они обеспечивают прозрачность и возможности для проверки. Три основных артефакта — это список продукта, список спринта и приращение.
Это упорядоченный список всего, что известно как необходимое для продукта. Это единый источник требований. Он никогда не бывает полным. Подробности меняются по мере развития продукта и окружающей среды. Он динамичный.
Это набор элементов из списка продукта, выбранных для спринта. Он включает план по доставке приращения продукта и достижению цели спринта. Он принадлежит команде разработки.
Приращение — это конкретный шаг к достижению цели продукта. Каждое приращение добавляется к предыдущим приращениям. Оно должно быть в пригодном для использования состоянии, независимо от того, решит ли владелец продукта его выпускать.
События создают ритм и возможности для проверки и адаптации. Они ограничены по времени, что означает наличие максимальной продолжительности.
Спринт — это сердцебиение гибкого подхода. Это событие фиксированной продолжительности не более одного месяца, в течение которого создается «готовый», пригодный для использования и потенциально доставляемый продукт. Спринты включают в себя планирование спринта, ежедневные стендапы, итоговое собрание спринта и ретроспективу спринта.
Это событие запускает спринт. Весь команда Scrum совместно работает над планом. Владелец продукта обсуждает цель и текущее состояние бэклога продукта. Команда разработки прогнозирует функциональность, которая будет в следующем спринте.
Также известен как ежедневный стендап, это 15-минутное событие для команды разработки. Он не предназначен для отчета о статусе руководству, а для синхронизации деятельности команды и составления плана на ближайшие 24 часа.
Это событие происходит в конце спринта для проверки инкремента и при необходимости адаптации продукта-бэклога. Команда Scrum и заинтересованные стороны обсуждают, что было достигнуто.
Команда Scrum анализирует, как прошлый спринт прошел с точки зрения индивидуальных достижений, взаимодействия, процессов, инструментов и их определения готовности. Цель — выявить способы улучшения и реализовать их в следующем спринте.
Помимо основной рамки Scrum, инженерные команды сталкиваются с конкретной терминологией, связанной с самой работой.
История пользователя — это неформальное, общее описание функции программного обеспечения, написанное с точки зрения конечного пользователя. Она следует определённому формату для обеспечения ясности.
Метафорически, технический долг представляет собой скрытые затраты на дополнительную переработку, вызванные выбором простого (ограниченного) решения в данный момент вместо использования более качественного подхода, который занял бы больше времени. Он накапливает проценты, если не погашается.
Скорость — это мера объема работы, которую команда может выполнить за один спринт, и является ключевым показателем в Scrum. Она рассчитывается путем суммирования очков завершенных пользовательских историй.
Определение готовности — это формальное описание состояния инкремента, когда он соответствует требованиям качества продукта. В момент, когда инкремент соответствует определению готовности, он может быть выпущен.
Эти метрики часто используются в Kanban и общем инженерном потоке.
Хотя Scrum популярен, это не единственный подход. Студенты-инженеры должны понимать связанные методологии.
Kanban фокусируется на визуализации работы, максимизации потока и ограничении работы в процессе. Он не предписывает конкретные роли или фиксированные итерации, как Scrum.
XP делает акцент на техническом превосходстве и инженерных практиках. Часто используется совместно с Scrum.
Lean применяет принципы производства к программному обеспечению. Оно фокусируется на устранении потерь и быстрой доставке ценности.
Данные движут улучшениями. Инженерные команды полагаются на конкретные метрики для оценки состояния и производительности.
График, показывающий объем оставшейся работы в спринте или проекте. Он помогает команде понять, находятся ли они на правильном пути для завершения работы.
Похож на график сгорания, но отображает объем выполненной работы с течением времени, а также общий объем работ.
Количество единиц работы, выполненных за определенный период. Полезно для измерения производительности команды с течением времени.
| Термин | Определение | Категория |
|---|---|---|
| Спринт | Ограниченный по времени период, в течение которого выполняется работа | Событие |
| Продуктовый бэклог | Упорядоченный список всех известных требований | Артефакт |
| История пользователя | Краткое описание функции с точки зрения пользователя | Артефакт |
| Скорость | Мера выполненной работы за один спринт | Метрика |
| Определение готовности | Критерии, которые должны быть выполнены для завершения работы | Стандарт |
| Технический долг | Стоимость повторной работы из-за упрощений | Понятие |
| Скрам-мастер | Модератор и наставник для команды | Роль |
| Продуктовый владельцы | Представляет интересы клиента и управляет бэклогом | Роль |
| Инкремент | Полезное дополнение к продукту | Артефакт |
| Канбан | Метод, ориентированный на поток и ограничения WIP | Фреймворк |
Студенты-инженеры часто переходят от академических проектов к профессиональной среде, не имея четкого понимания этих терминов. Такой разрыв может привести к конфликтам с заинтересованными сторонами или недопониманию в командах. Знакомство с этим глоссарием устраняет эту пропасть.
Когда вы сталкиваетесь с термином, который не понимаете, уточните его значение. Не предполагайте смысла. Отрасль ценит точность. Использование правильной терминологии демонстрирует компетентность и уважение к процессу.
Более того, понимание этих концепций позволяет вам выступать за улучшение практик. Если вы замечаете, что команда накапливает технический долг, вы можете использовать этот фреймворк, чтобы предложить время на рефакторинг. Если процесс неясен, вы можете сослаться на Определение готовности, чтобы установить ясность.
Непрерывное обучение — часть инженерного мышления. Агильный манифест призывает к рефлексии о том, как стать лучше в выполнении работы. Этот гайд служит отправной точкой для такой рефлексии. По мере продвижения вы будете сталкиваться с новыми терминами и нюансами. Ведите личный глоссарий. Добавляйте в него по мере обучения.
Среда программного обеспечения динамична. Фреймворки развиваются. Однако основные принципы сотрудничества, итеративной доставки и качества остаются неизменными. Овладение этим словарем гарантирует, что вы останетесь гибкими и эффективными в любой инженерной среде.
Помните, что инструменты меняются, но принципы остаются. Независимо от того, работаете ли вы в стартапе или крупной компании, потребность в четкой коммуникации и структурированной доставке сохраняется. Используйте этот глоссарий как отправную точку для вашего профессионального пути.