Scrum (Rugby Team), модель разработки программного обеспечения, представляет собой разновидность гибкой разработки, которая постепенно становится популярной за последние десять лет.
Основное предположение Scrum
Разработка программного обеспечения похожа на разработку нового продукта. Окончательные процедуры программного продукта не могут быть определены с самого начала. Процесс требует исследований и разработок, творчества, проб и ошибок, поэтому не существует фиксированного процесса, который может гарантировать успех проекта.
Scrum сравнивает команду разработчиков программного обеспечения с футбольной командой. Он имеет четкую и высшую цель, знаком с лучшей моделью и технологией, необходимой в процессе разработки, обладает высокой степенью автономии, тесного общения и сотрудничества и обеспечивает ежедневное решение различных задач с высокой степенью гибкости; Каждый этап имеет четкое продвижение к цели.
Скрам-процесс
Процесс разработки Scrum обычно начинается с 30-дневной (или более короткой) фазы, начиная со спецификации требований клиента к новому продукту, при этом команда разработчиков и заказчик выбирают, какие части спецификации должны быть завершены в начале каждой фазы. команда должна сделать все возможное, чтобы предоставить результаты через 30 дней, и группа встречается 15 минут в день, чтобы просмотреть прогресс и расписание каждого участника, понять возникшие трудности и попытаться устранить неполадки.
Преимущества гибкого подхода
В чем преимущество Scrum перед традиционной моделью разработки. Отличительной чертой модели Scrum является то, что она реагирует на изменения. Он может реагировать на изменения максимально быстро.
Когда традиционная система фокусируется на предварительном планировании, где важны такие факторы, как стоимость, объем и время, гибкий подход отдает предпочтение командной работе, сотрудничеству с клиентами и гибкости. По мере изменения спецификаций требований Agile-команда может оставаться мобильной и иметь возможность реагировать на эти изменения. Однако это не обязательно означает, что стратегия адаптивного планирования всегда лучше, чем стратегия прогнозирующего планирования. Давайте сравним эти две стратегии развития проекта более подробно.
Таким образом, традиционный подход к разработке (водопадный, также известный как плановый) является линейным, при этом все фазы процесса происходят последовательно. Этот подход зависит от предсказуемых инструментов и предсказуемого опыта. Каждый проект проходит один и тот же жизненный цикл, включая технико-экономическое обоснование, планирование, проектирование, строительство, тестирование, производство, поддержку и т. д., как показано ниже.
Весь проект планируется заранее без возможности изменения требований, например, PMI PMBOK и PRINCE2 являются строгими и строго контролируются. Они описывают различные этапы планирования проекта от начала до конца и предполагают, что у вас уже есть все необходимые требования и информация заранее.
Agile считается более современной стратегией разработки программного обеспечения, поскольку она была в первую очередь предназначена для преодоления некоторых недостатков более предсказуемого каскадного подхода. Это модель разработки программного обеспечения, которая поощряет итеративную разработку и тестирование на протяжении всего жизненного цикла разработки программного обеспечения проекта.
Обзор процесса Scrum
Scrum — это структура, которая предписывает роли , события , артефакты и правила/рекомендации для реализации этого мышления. Другими словами, Agile — это образ мышления, а Scrum — это структура, предписывающая процесс реализации философии Agile.
Scrum и agile — это не одно и то же, но Scrum — это один из agile-процессов. Они основаны на итеративной разработке. Требования и решения гибкой разработки, полученные в результате объединения межфункциональных и самоорганизующихся команд, и при правильном внедрении могут помочь командам решать сложные проблемы путем постепенного предоставления продуктов с наивысшей ценностью при снижении рисков.
Scrum включает в себя быструю проверку и адаптацию, командная работа усиливается философией лидерства, подотчетности и самоорганизации, лучшими инженерными практиками, которые помогают в быстрой доставке высококачественного программного обеспечения.
Ключевые термины Scrum
Бэклог: все задачи, которые можно спрогнозировать, включая все функциональные и нефункциональные задачи.
Спринт: период времени для развития поколений, обычно не более 30 дней в виде цикла. В течение этого времени команда разработчиков должна завершить сформулированный бэклог, а конечным результатом будет постепенный и поставляемый продукт.
Бэклог спринта: задачи, которые необходимо выполнить в цикле спринта.
Тайм-бокс: временной интервал для встречи. Например, время каждой ежедневной встречи Scrum составляет 15 минут.
Совещание по планированию спринта: проводится перед началом каждого спринта. Обычно один день (8 часов). Задача, которую необходимо сформулировать на этой встрече: владелец продукта и члены команды разбивают бэклог на небольшие функциональные модули, решают, сколько мелких функциональных модулей необходимо выполнить в предстоящем спринте, и определяют приоритет задачи этого бэклога продукта. Кроме того, на совещании необходимо подробно обсудить, как завершить эти небольшие функциональные модули по мере необходимости. Нагрузка этих модулей исчисляется в часах.
Ежедневное собрание Scrum: проводится членами команды разработчиков, обычно 15 минут. Каждый участник разработки должен сообщить скрам-мастеру о трех проектах: Что было завершено сегодня? Сталкивались ли вы с препятствиями? Чем ты планируешь заняться? Благодаря этой встрече члены команды могут понять ход проекта друг с другом.
Совещание по обзору спринта: после каждого спринта команда представляет результаты спринта владельцу продукта и другому соответствующему персоналу. Обычно эта встреча длится 4 часа.
Ретроспектива Спринта проводится после Обзора Спринта и до Планирования следующего Спринта . Это максимум трехчасовая встреча для месячных Спринтов . Ретроспективная сессия — это, по сути, собрание «улучшений», проводимое для поиска путей и средств выявления потенциальных ловушек, прошлых ошибок и поиска новых способов избежать этих ошибок, на котором присутствуют все — владелец продукта , скрам-мастер , члены команды разработки . и, возможно, с заинтересованными сторонами.
Скрам-мастер: член команды, ответственный за надзор за всем процессом Скрама и пересмотр плана.
Владелец продукта , который владеет продуктом от имени компании, является частью Scrum-команды . Однако владелец продукта не имеет власти над другими членами команды, как и Скрам-мастер . Владелец продукта отвечает за присмотр за продуктом в течение длительного периода времени и несет ответственность за достижение успеха продукта. Как владелец продукта, вы должны напрямую взаимодействовать с клиентами и пользователями, командой разработчиков и другими ключевыми заинтересованными сторонами, как показано на рисунке ниже.
Скрам — команда — это группа людей (обычно от пяти до девяти человек), работающих вместе над созданием необходимых приращений продукта. Фреймворк Scrum поощряет высокий уровень общения между членами команды, так что команда может:
- Следуйте общей цели
- придерживаться одних и тех же норм и правил
- проявлять уважение друг к другу
Как работает скрам?
Процесс Scrum отличается от других agile-процессов особыми концепциями и практиками, разделенными на три категории ролей ( владелец продукта , мастер Scrum , команда разработчиков и другие заинтересованные стороны), события, артефакты и правила.
Чтобы запустить процесс Scrum, владелец продукта создает список приоритетных пожеланий, называемый бэклогом продукта . Во время планирования спринта отставание оценивается по сложности и ценности для бизнеса (приоритет). Владелец продукта (клиент) и команда разработчиков определяют, какие элементы невыполненной работы будут добавлены в спринт. У команды есть определенное количество времени (называемое спринтом , обычно от двух до четырех недель), чтобы завершить свою работу, но она собирается каждый день, чтобы оценить свой прогресс ( ежедневный скрам ). Попутно скрам-мастер держит команду сосредоточенной на своей цели. В конце спринта команда анализирует свой прогресс, показывает клиенту работающий продукт и анализирует, что получилось хорошо, а что нужно улучшить для следующего спринта. Затем цикл повторяется.