Экстремальное программирование — одна из самых ранних гибких методологий, которая появилась и постоянно развивается. Кент Бек, который развивал экстремальное программирование, разработал его с целью использовать лучшие методы программирования и довести их до крайности.
Экстремальное программирование в текущем сценарии фокусируется на лучших практиках, которые преобладают в отрасли на данный момент, и доводит их до крайности. Наиболее распространенными примерами являются разработка через тестирование, подход всей команды, устойчивое развитие и т. Д.
XP — гибкость как техника
Одна из причин популярности Extreme Programming — его гибкость. Более того, экстремальное программирование больше относится к технике, чем к процессу, и, следовательно, хорошо сочетается с процессно-ориентированными подходами. Таким образом, вы можете легко комбинировать функции экстремального программирования с другими идеями, где бы вы ни находились
-
Некоторые из методов экстремального программирования являются дополнительными в этом процессе.
-
Экстремальное программирование само по себе не подходит для реализации.
Некоторые из методов экстремального программирования являются дополнительными в этом процессе.
Экстремальное программирование само по себе не подходит для реализации.
Однако помните, что любая из выбранных вами Экстремальных практик программирования должна быть реализована по своей сути. В противном случае вы не сможете утверждать, что используете экстремальное программирование.
Фактически, это верно для любого процесса, который вы выполняете. Смешивание и сопоставление разрешено, но только в том случае, если вы используете дополнительные функции и не ставите под угрозу значения используемых функций.
Самым популярным гибридом Extreme Programming, который в настоящее время используется, является гибрид Scrum + Extreme Programming. Мы начнем с базовой и все еще распространенной методологии разработки программного обеспечения — модели водопада.
Модель водопада
В модели водопада развитие развивается поэтапно, и никакая фаза не может начаться до завершения более ранней фазы.
Модель водопада все еще используется в нескольких организациях, хотя некоторые воспринимают ее как традиционную методологию. Это установленная и эффективная методология, если требования полностью известны до начала разработки. Процесс прост и не требует обучения или наставничества.
Необходимо помнить, что ни одна методология не является идеальной для каждой ситуации, и каждая методология будет иметь свои достоинства и недостатки. Следовательно, вы должны понимать, какая методология соответствует вашему контексту, вашей среде и интересам ваших клиентов.
Давайте посмотрим на недостатки методологии водопада —
-
Поскольку все требования должны быть известны до начала разработки, они не подходят, когда требования являются неполными или расплывчатыми.
-
Поскольку методология направлена вперед в одном направлении, обратная связь с любой фазы не может быть возвращена ни на одну из более ранних фаз, хотя в отношении конечного продукта достигается большая ясность.
-
Тестирование проводится только после завершения разработки, когда группа разработчиков не участвовала в более ранних этапах, таких как сбор требований или разработка. Этот подход, основанный на последнем тестировании, часто приводит к локализации дефектов, высоким показателям дефектов, высоким доставленным дефектам, которые обнаруживаются заказчиком.
-
Рабочий продукт не будет доступен до конца разработки, и, следовательно, никто не будет иметь понятия о том, строится ли правильная вещь, хотя она разрабатывается правильно.
-
Исправления дефектов и изменения требований трудно поглотить, так как существует высокая вероятность разрушения конструкции, а также высокие расходы.
Поскольку все требования должны быть известны до начала разработки, они не подходят, когда требования являются неполными или расплывчатыми.
Поскольку методология направлена вперед в одном направлении, обратная связь с любой фазы не может быть возвращена ни на одну из более ранних фаз, хотя в отношении конечного продукта достигается большая ясность.
Тестирование проводится только после завершения разработки, когда группа разработчиков не участвовала в более ранних этапах, таких как сбор требований или разработка. Этот подход, основанный на последнем тестировании, часто приводит к локализации дефектов, высоким показателям дефектов, высоким доставленным дефектам, которые обнаруживаются заказчиком.
Рабочий продукт не будет доступен до конца разработки, и, следовательно, никто не будет иметь понятия о том, строится ли правильная вещь, хотя она разрабатывается правильно.
Исправления дефектов и изменения требований трудно поглотить, так как существует высокая вероятность разрушения конструкции, а также высокие расходы.
Если вы прогнозируете такие условия в своем развитии, Agile методологии являются наиболее подходящими.
Agile методологии
Сторонник Agile методологии —
-
Частые выпуски работающего продукта, позволяющие получать обратную связь в нужное время.
-
Командно-ориентированный подход, чтобы сделать каждого ответственным и ответственным за конечный продукт.
-
Гибкое планирование, ориентированное на обеспечение ценности для клиента, удовлетворение ожиданий клиента, возврат инвестиций.
-
Готовность принять изменения на любом этапе разработки, чтобы поставляемый конечный продукт не устарел.
Частые выпуски работающего продукта, позволяющие получать обратную связь в нужное время.
Командно-ориентированный подход, чтобы сделать каждого ответственным и ответственным за конечный продукт.
Гибкое планирование, ориентированное на обеспечение ценности для клиента, удовлетворение ожиданий клиента, возврат инвестиций.
Готовность принять изменения на любом этапе разработки, чтобы поставляемый конечный продукт не устарел.
Появилось несколько гибких методологий, из которых Scrum стал более популярным и широко используется.
Как Scrum делает разницу?
В Scrum проекты разбиты на релизы и временные короткие спринты. Для каждого спринта вы задействуете только те необходимые и достаточные функции, которые приоритетны для клиента и которые вы можете предоставить в спринте. В конце каждого спринта у вас будет рабочий продукт, который может быть выпущен.
Требования называются элементами невыполненных работ, а итерации — спринтами. Непрерывное тестирование с первым подходом к тестированию будет адаптировано. Разработчики и тестировщики также участвуют в написании пользовательских историй, которые являются элементами отставания. Это дает предварительное представление о поведении продукта всем в команде, а также помогает в достижении критериев приемлемости в начале самого спринта.
Scrum по определению, как мы уже говорили ранее, эффективен в определенных ситуациях, но имеет свои недостатки, как и любые другие методологии разработки.
-
Спринт с временными рамками не даст никакой гибкости в графике выпуска, что затруднит как разработку, так и тестирование.
-
Scrum, сам по себе не дает указаний для развития.
Спринт с временными рамками не даст никакой гибкости в графике выпуска, что затруднит как разработку, так и тестирование.
Scrum, сам по себе не дает указаний для развития.
Следовательно, Scrum обычно объединяется с другими Agile-методологиями, которые больше фокусируются на стратегиях развития.
Скрам + Экстрим Гибрид Программирования
Scrum используется довольно часто, включая методы экстремального программирования, которые дополняют друг друга, при этом экстремальное программирование фокусируется на инженерных аспектах, таких как непрерывное общение, частые циклы обратной связи, рефакторинг, коллективное владение, непрерывная интеграция, разработка через тестирование и т. Д., А scrum фокусируется на фиксированная область для спринтов, карт сгорания и т. д.
-
Поскольку Scrum — это определенная методология, ее легче адаптировать с первого дня проекта.
-
Поскольку Extreme Programming больше ориентируется на общение и сплоченность команды, команда больше сосредоточена на развитии.
Поскольку Scrum — это определенная методология, ее легче адаптировать с первого дня проекта.
Поскольку Extreme Programming больше ориентируется на общение и сплоченность команды, команда больше сосредоточена на развитии.
Таким образом, гибрид Scrum + Extreme Programming оказался эффективным.
Инструменты для гибридных проектов Scrum + XP
Такие инструменты, как SpiraTeam и Rapise, предназначены для гибридных проектов Scrum + Extreme. SpiraTeam предоставляет инструментальные панели отчетов о ключевых показателях качества и прогресса проекта в одном консолидированном представлении, специально разработанном для проектов Scrum и Extreme Programming.
Некоторые из показателей —
- Требования к тестовому покрытию
- Задача Прогресс
- Скорость проекта
- Основные риски и проблемы
Инструмент Rapise — это решение для автоматизации тестирования, которое может быть полностью интегрировано в ваш процесс разработки и адаптировано к вашим меняющимся потребностям. Вы можете использовать его для тестирования настольных, веб-и мобильных приложений. Этот инструмент может использоваться разработчиками, тестировщиками и бизнес-пользователями для создания приемочных тестов.