exam05 4
Реферат к лекции 5 Управление требованиями, изменениями, инцидентами
Выполнила: Сарыбаева Анна ИДБ-19-06
Проверила: Воробьева Ирина ИДБ-19-06
SCRUM - методология гибкой разработки ПО, которая делает акцент на качественном контроле процесса разработки.
В классическом Scrum существует 3 базовых роли:
- Product owner - человек, который имеет непосредственный интерес в качественном исполнении продукта. Он понимает, как это продукт должен выглядеть и сопровождает разработку на каждом этапе и помогает расставить приоритеты. Может быть участников или работать на стороне заказчика.
- Scrum master - проводит совещания (Scrum meetings) следит за соблюдением всех принципов SCRUM, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учёт, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения процесса SCRUM. Может быть дополнительной ролью для участника команда или отдельной. Довольно часто бывает Олин серам мастер на несколько команд.
- Команда разработки (Development team) - участники команды, которые непосредственно запиваются разработкой продукта.
Основой данной методологии является Спринт, в течении которого выполняется работа над продуктом. Спринт ограничен по времени и имеет фиксированную продолжительность. По окончанию Спринта должен быть получен инкремент продукта - готовую к использованию часть продукта.
Перед каждым Спринтом производится планирование Спринта, на котором производится оценка содержимого журнал пожеланий проекта (Project backlog), который содержит перечень требований к функциональности, упорядоченный по степени важности, и, соответственно, порядку реализации и формирование журнала пожеланий спринта (Sprint backlog), который содержит функциональность, выбранную владельцем продукта из Project backlog.
Каждый день производится ежедневное SCRUM-совещание. Его Задача — определение статуса и прогресса работы над Спринтом, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Спринта.
По окончанию Спринта также проводятся Sprint Review и Sprint Retrospective, задача которых получение обратной связи от заказчика, чтобы понять, на чём нужно делать акцент в дальнейшем, и какой должен быть следующий инкремент бизнес-продукта, а также оценивание эффективности работы команды в пройденном Спринте, выявление проблем и внесение изменений в необходимые процессы.
Основная ответственность за управление изменениями в данной методологии возлагается на владельца продукта, который определяет для команды наиболее приоритетные задачи для текущего проекта и решает стоит ли выпускать инкремент. В некоторых случаях, если цель спринта потеряла актуальность Product Owner может вообще полностью отменить текущий Спринт.
Главным инструментом для внесения изменений для владельца продукта является Project backlog, а также проводимый в конце Спринта Sprint review и сборка продукта с инкрементом.
Гибкий подход к управлению релизами называется непрерывной разработкой. Непрерывное развитие — это способность безопасно и быстро внедрять изменения всех типов, такие как новые функции, изменения конфигурации, исправления ошибок и эксперименты, в производство или в руки пользователей устойчивым способом. Как и в процессе гибкой разработки, выпуски также состоят из небольших пакетов высокоприоритетных, ценных функций (или иногда одной функции). Таким образом, гибкие команды выпускают меньшие и более частые релизы, чем традиционные.
Вот как гибкие команды ускоряют цикл выпуска. Существуют три тесно связанных, но разных метода. Давайте разберем их:
-
Непрерывная интеграция (CI) - Практика непрерывной интеграции рекомендует разработчикам как можно чаще объединять свой код с основным репозиторием. Автоматическая сборка извлекается для каждой регистрации и проходит через автоматические тестовые примеры, что помогает выявлять ошибки интеграции на ранней стадии. Это гарантирует, что основная ветвь кода постоянно обновляется. Преимущества простого выпуска без проблем с интеграцией перевешивают затраты на настройку автоматических тестов.
-
Непрерывная доставка (CD) - В то время как CI уделяет особое внимание автоматизированному тестированию, CD делает еще один шаг к автоматизации процесса выпуска. Это означает, что вы можете предоставлять своим клиентам надежные ИТ—релизы быстрым и устойчивым способом в любое время, когда это потребуется вашему бизнесу. Процесс выпуска автоматизирован вплоть до момента развертывания выпуска.Благодаря этой практике код почти всегда готов к выпуску. Это снижает координацию, усилия и ставки, связанные с каждым выпуском. Вам нужен только ручной триггер.
-
Непрерывное развертывание (CDP) - При непрерывном развертывании весь процесс автоматизирован, включая фактическое развертывание вашего кода. Все коммиты проходят автоматическое тестирование и автоматически передаются в производственную среду. Изменение кода откладывается только в том случае, если оно не проходит проверку качества. Поскольку новые изменения становятся доступными для конечных пользователей практически без промежуточного буфера, непрерывное развертывание требует пострелизного мониторинга для выявления любых ошибок, которые могли проскользнуть через автоматические тесты.
Эти три практики вместе называются непрерывной разработкой программного обеспечения и связаны с гибкими методологиями и DevOps. Все это эффективно ускоряет цикл выпуска программного обеспечения и помогает гибким командам часто поставлять надежное программное обеспечение устойчивым способом.
Репозиторий, хранилище место, где хранятся и поддерживаются какие-либо данные. Чаще всего данные в репозитории хранятся в виде файлов, доступных для дальнейшего распространения по сети. Репозитории используются в системах управления версиями, в них хранятся все документы вместе с историей их изменения и другой служебной информацией. Система управления версиями (от англ. Version Control System, VCS или Revision Control System)программное обеспечение для облегчения работы с изменяющейся информацией. Система управления версиями позволяет хранить несколько версий одного и того же документа, при необходимости возвращаться к более ранним версиям, определять, кто и когда сделал то или иное изменение, и многое другое.
Для удобной работы в гибкой работы репозитории используются для работы CI/CD/CDP процессами. Они могут являются источниками кода интегрированными с приложениями для автоматизации (Jenkins,airflow,gitlab).
Сборки по расписанию (англ. daily build — ежедневная сборка), как правило, проводятся в нерабочее время, ночью (англ. nightly build), планируются таким образом, чтобы к началу очередного рабочего дня были готовы результаты тестирования Для различия дополнительно вводится система нумерации сборок — обычно, каждая сборка нумеруется натуральным числом, которое увеличивается с каждой новой сборкой Исходные тексты и другие исходные данные при взятии их из репозитория (хранилища) системы контроля версий помечаются номером сборки Благодаря этому, точно такая же сборка может быть точно воспроизведена в будущем — достаточно взять исходные данные по нужной метке и запустить процесс снова. Это даёт возможность повторно выпускать даже очень старые версии программы с небольшими исправлениями.