Гибкое программирование
Гибкий процесс играет важную роль в цикле разработки программного обеспечения и управления им. В Agile есть ряд принципов, которые прямо направлены на ценность для клиента, итеративную и поэтапную доставку. Гибкие методы фокусируются на двух разных аспектах: один - это гибкие методы, которые представляют собой экстремальное программирование и парное программирование, другие - на управлении проектами с использованием подхода scrum. Гибкий процесс используется, когда компания или организация имеют четкое представление о своей цели, но путь к решению неясен, используется управление гибким процессом.
Экстремальное программирование с гибкой практикой считается лучшей практикой для извлечения пользы из цикла программирования. Экстремальное программирование возникло после того, как возникли проблемы в традиционной модели цикла разработки программного обеспечения. Его введение было сделано просто для того, чтобы сосредоточиться на «просто выполнить работу», и оно оказалось эффективным для развития. экстремальное программирование опробовано и проверено на практике гибкой разработки; он уделяет максимальное внимание взаимодействию с клиентами, чтобы знать точное требование, а затем только приступить к разработке продукта.
Функционирование гибкого программирования
Он делит весь цикл обработки на меньшие или короткие циклы. На этапе разработки, или мы можем сказать, что этап перед доставкой (может быть также и последним этапом), клиент может вносить изменения в зависимости от своих требований. Работает в пять этапов
- Исследование - Экстремальное программирование инициирует цикл разработки продукта, собирая требования от пользователя. Пользователь отмечает свои идеи или требования на карточке истории, которую они хотят увидеть во время выпуска. Слоты карт истории определяют атрибут, который будет добавлен в продукт. На этом же этапе команда документирует записи практики, инструментов и технологий, необходимых для разработки продукта, в соответствии с требованиями пользователя. Технология, необходимая для создания нового продукта, проверена, и новые возможности изучаются путем создания прототипа системы. Это может занять одну неделю или несколько месяцев, чтобы завершить фазу исследования, это полностью зависит от программиста, насколько программа знакома с технологией.
- Планирование - Собранные данные затем делятся на небольшие циклы, чтобы понять каждый бит требований пользователя. Данные располагаются по приоритетам для первого выпуска продукта, после чего начинается разработка. Оценка и график работ для первого релиза рассчитываются и затем согласовываются с релизом. Первый период выпуска составляет менее двух месяцев.
- Итерации. На этом этапе перед первым выпуском продукта происходит несколько итераций систем. Итерации делятся на несколько небольших итераций, и для их реализации предоставляется от двух до четырех недель. Теперь фаза итерационного планирования активна, что означает принятие решения относительно разделения цикла, приоритета и рабочей силы, необходимой для разработки. Итерации создают схему системы, затем система достигается путем выбора карт из карт истории, сделанных пользователем. Решение принимает пользователь, для которого выбрать первым. Заказчик запускает итерацию в конце каждого интервала, который он выбрал для каждой части итерации.
- Производство - Этот этап считается важным, поскольку перед этим продуктом перед покупателем проводится финальное тестирование, тестируется производительность. В течение этого времени могут быть обнаружены новые изменения, которые должны быть корректными в продукте до первого выпуска продукта. Команда готова принять изменения на любом этапе разработки, потому что новые требования могут появиться на любом этапе. Для исправлений время итерации должно быть уменьшено с трех до одной недели. Другие идеи и предложения сохраняются для последующей реализации. Производство продолжается после первого выпуска продукта для того же продукта или для него могут быть новые итерации. На этом этапе у группы технического обслуживания запрашиваются исправления дефектов, это делается после первого выпуска продукта. Общение с клиентом также можно запросить через службу поддержки клиентов. Добавление новых членов команды и изменения в команде, структура может потребоваться во время технического обслуживания.
- Фаза смерти - это фаза, когда клиент соглашается больше не использовать карточку истории. Это фаза, на которой можно сделать окончательную документацию по продукту, полагая, что больше не вносятся изменения в архитектуру, дизайн или код. Он должен убедиться, что продукт доставил желаемый продукт, иначе система будет считаться смертью. Это должно держать расходы в пределе для дальнейшего развития.
Команда (Роль и Ответственность)
Agile циклы имеют несколько членов (команды) для создания нового продукта. Каждое задание делится между командами и собирается после того, как все сделано хорошо.
- Программист - программист является одним из основных органов, он создает код для продукта и сохраняет код простым и определенным для возможности. Лучший способ правильно написать код - это общение с другими программистами и товарищами по команде. Это может быть для того, чтобы знать точные требования к продукту.
- Клиент - Клиент является основным органом, который пишет истории для своих требований и решает, какое требование удовлетворит его потребности. Приоритет реализации устанавливается заказчиком.
- Тестер - Тестер отвечает за выполнение функциональных тестов, он помогает заказчику писать функциональные тесты. Тестирование проводится повсеместно (регулярно), а инструменты тестирования поддерживаются.
- Трекер - Трекер обеспечивает обратную связь и отслеживает оценки, сделанные командой, а также предоставляет предложения по улучшению.
- Тренер - Тренер - руководство для членов команды на протяжении всего процесса разработки. Он опытный человек, который много лет занимается переработкой.
- Консультант - Консультант - это внешний участник, который руководит командой, обладающей конкретными техническими знаниями, которые могут потребоваться для разработки проекта.
- Менеджер - он является решающим органом. Менеджер держит команду на правильном пути, чтобы выполнить работу. Он открыт для общения с членами команды по вопросам, с которыми сталкивается команда во время разработки. Он следит за тем, чтобы работа шла гладко, пока проект не будет завершен.
Рекомендуемые статьи
Это было руководство по гибкому программированию. Здесь мы обсуждаем функционирование, командную роль и ответственность гибкого программирования. Вы также можете взглянуть на следующие статьи, чтобы узнать больше -
- Что такое гибкая разработка программного обеспечения?
- Такое язык программирования MySQL?
- Что такое Agile и Scrum?
- Что такое язык программирования Kotlin?