Экстремальное программирование в Agile: практическое руководство для менеджеров проектов и nTaskers

Опубликовано: 2020-07-08

Мы получили очень много запросов об экстремальном программировании в водопаде — и о том, как это может быть полезно руководителю проекта. На всякий случай, если вы не знали, что такое экстремальное программирование, скажу, что это форма гибкой среды, в которой менеджеры по проектам получают максимальную отдачу от доступных ресурсов в среде разработки программного обеспечения.

Экстремальное программирование (XP) в среде Agile SDLC

Источник: Udacity.com

Extreme Programming (XP), гибкая среда разработки программного обеспечения, специально разработана для улучшения качества программного обеспечения, рабочего процесса команды разработчиков и повышения удовлетворенности клиентов.

Это метод, разработанный для более плавного и эффективного жизненного цикла разработки программного обеспечения (SDLC) для ваших проектов, и впервые он был реализован в проекте 6 марта 1996 года.

Почему экстремальное программирование (XP)?

Extreme Programming работает над созданием повторяющихся и повторяющихся выпусков программного обеспечения на протяжении всего проекта; вместо всего вместе после одного длительного жизненного цикла разработки проекта.

Эти короткие итерационные циклы помогают как членам команды, так и клиентам оценивать и анализировать ход проекта на протяжении всего его развития.

Из чего состоит экстремальное программирование (XP)?

Ценности

XP включает в себя следующие 5 значений:

Коммуникация : проекты по разработке программного обеспечения или проекты в любой отрасли в значительной степени зависят от коммуникации. XP фокусируется на эффективной коммуникации между командой и заказчиком.
Простота : XP ищет самые простые способы добиться цели. Это означает делать то, что необходимо, тем самым сокращая количество отходов, решать только известные проблемы и сохранять простоту дизайна для эффективного создания и обслуживания.
Обратная связь : обратная связь играет важную роль в улучшении проекта. XP поощряет мгновенную обратную связь. Это помогает команде определить возможности для улучшения и пересмотреть практику.
Уважение : команда должна уважать друг друга как лично, так и профессионально, для достижения целей.
Мужество : XP поддерживает смелость на всех уровнях. Это может включать выступление против того, что не работает, и всего, что влияет на эффективность проекта, или принятие отзывов и улучшение методологий.

Практики

Ядром XP является взаимосвязанный набор методов разработки программного обеспечения. Хотя эти методы можно применять изолированно, многие команды обнаружили, что некоторые методы усиливают другие и должны выполняться в сочетании. Это может позволить полностью устранить риски, с которыми вы часто сталкиваетесь при разработке программного обеспечения.

Первоначальные двенадцать практик для XP включают:

Игра в планирование
Небольшие релизы
Метафора
Простой дизайн
Тестирование
Рефакторинг
Парное программирование
Коллективная собственность
Непрерывная интеграция
40-часовая рабочая неделя
Клиент на месте и
Стандарт кодирования.

За прошедшие годы команды обнаружили, что одни практики усиливают другие. Для устранения рисков они должны быть унифицированы. Следующие описания включают некоторые уточнения, основанные на опыте различных команд:

Вся команда : команды должны состоять из кросс-функциональных групп людей с разными навыками. Таким образом, они могут дополнять друг друга для достижения определенного результата.

Сядьте вместе: большинство людей согласны с тем, что разговоры лицом к лицу — лучшая форма общения. Команды должны сидеть вместе без барьеров для общения, например, стен кабинета.

Информативное рабочее пространство : команды должны располагаться таким образом, чтобы работа команды была прозрачна друг для друга и для аффилированных лиц вне команды.

Энергичная работа : это означает, что человек должен быть психически и физически здоров, чтобы сосредоточиться на работе. Это также означает, что не должно быть чрезмерной работы и уважения к командам для поддержания их психического и физического здоровья.

Читайте также:

Как управлять проектом как профессионал в сегодняшней рабочей среде?

Парное программирование : Идея этой практики заключается в том, что два мозга лучше, чем один. Парное программирование относится к созданию программного обеспечения двумя людьми, сидящими за одной машиной. Таким образом, происходит непрерывный обзор работы, и проблемы получают более быстрое решение. Было показано, что этот метод улучшает качество и позволяет оставаться более сфокусированным.

Истории : Истории определяют функции, которые должны быть у продукта, которые были бы значимы для клиентов и пользователей. Эти истории используются для планирования, а также служат напоминанием для дальнейших разговоров.

Еженедельный цикл : в первый день каждой недели команда собирается, чтобы обсудить достигнутый прогресс. Истории, которые должны быть представлены в течение недели, выбираются заказчиком. Команда определяет, как подойти к этим историям. Целью этого является создание работающей, поддающейся проверке функции к концу недели. Фиксированный период позволяет создать функцию, которую можно показать клиенту для обратной связи.

Квартальный цикл: цель квартального цикла — проверить детальную работу каждого недельного цикла в контексте всего проекта. Заказчик предоставляет общий план работы команды на конкретный квартал. Это не только дает команде представление о проекте, но и помогает заказчику работать с другими заинтересованными сторонами.

Slack : это подразумевает добавление нескольких задач или историй с низким приоритетом в еженедельные и квартальные циклы. Если команда отстает от более важных задач, от них можно отказаться. В противном случае они также будут завершены, что повысит шансы на соблюдение предполагаемых графиков.

Десятиминутная сборка : Вся система и все тесты должны быть запущены в течение 10 минут. Если время превышает этот предел, многократные повторные запуски будут стоить больших периодов между ошибками. Эта практика способствует автоматизации процесса сборки, позволяя регулярно запускать все ваши тесты.

Непрерывная интеграция: эта практика поощряет немедленное тестирование нового кода в существующей большой кодовой базе. Это помогает быстрее выявлять и устранять проблемы с интеграцией. Эта практика требует дисциплины и зависит от практик десятиминутной сборки и сначала тестирования.

Тестовое программирование : вместо того, чтобы следовать обычному пути, т.е.

Разработать код -> Написать тесты -> Запустить тесты

Практика Test-First Programming идет по пути:

Написать неудачный автоматический тест -> Запустить неудачный тест -> Разработать код для прохождения теста -> Запустить тест -> Повторить

Эта практика также сокращает цикл обратной связи для выявления и решения проблемы. Это приводит к уменьшению количества ошибок, которые появляются в рабочей среде.

Инкрементальный дизайн : эта практика предполагает выполнение определенного объема работы заранее, чтобы понять общую перспективу проектирования системы. После этого продолжайте работать над деталями конкретного аспекта дизайна, когда будут реализованы определенные функции. Такой подход снижает стоимость изменений и позволяет вам принимать проектные решения, когда это необходимо, на основе самой последней доступной информации.

Роли

XP включает в себя определенные методы для вашей команды и не устанавливает конкретных ролей для членов команды. Однако, согласно требованию, 4 наиболее распространенными ролями являются:

Заказчик: Ожидается, что Заказчик XP будет активно участвовать в проекте. Заказчик принимает все бизнес-решения по проекту, такие как:

Что должна делать система? Это относится к функциям, которые включены, и к тому, что они выполняют.
Когда система готова? Отсюда вытекают критерии приемлемости
Сколько нужно потратить? Что означает бюджет проекта, и
Что делать дальше? Порядок доставки функций.

Разработчик : Разработчики реализуют истории, указанные Заказчиком, что означает создание проекта с определенными характеристиками.

Следопыт : роль следопыта необязательна и зависит от того, требуется ли он команде. Это выполняется одним из разработчиков для отслеживания соответствующих показателей гибкости, и это важно для оценки прогресса и определения ключевых областей для улучшения. Это важно для отслеживания прогресса и определения ключевых областей для улучшения. Некоторые из этих показателей могут включать в себя количество отработанного времени, количество сверхурочных часов, пройденные и не пройденные тесты, скорость и причины отклонений от скорости.

Тренер : Эта роль полезна, особенно если команда только начинает свою работу. Коуч может быть внешним консультантом, который уже использовал XP раньше, и может помочь наставлять команду в вопросах практики XP, а также в самодисциплине. Использование тренера помогает избежать потенциальных ошибок, которые могут совершать новые команды, ускоряя проект.

Преимущества экстремального программирования

Экстремальное программирование позволяет разработчикам программного обеспечения сосредоточиться на кодировании и не беспокоиться о непродуктивной деятельности, связанной с проектом.
Наиболее важным преимуществом экстремального программирования является то, что оно позволяет компаниям-разработчикам программного обеспечения сократить расходы ресурсов, таких как деньги и время, на бесполезные действия, когда они могут быть потрачены на такие действия, как реализация проекта и другие сеансы мозгового штурма.
Экстремальное программирование также снижает риск провала проекта или сбоя в кодировании, гарантируя, что клиент в конечном итоге получит желаемый продукт.
Экстремальное программирование — это удивительная методология, которая не требует, чтобы код был сложным и трудным для понимания всеми, и это проявляется в коде разработчиков, которые используют эту методологию, потому что всякий раз, когда кто-то другой занимает их место, они могут очень хорошо понять код. без труда
Одна из лучших особенностей XP заключается в том, что все прозрачно и открыто для всех, что помогает держать всех и все подотчетными.
Постоянная обратная связь также является невероятной особенностью экстремального программирования, которая позволяет разработчикам кодировать бесстрашно и без страха осуждения, потому что они всегда могут исправить мелкие ошибки, которые они делают, с помощью получаемой обратной связи.
Регулярное тестирование всех элементов программного обеспечения, обнаружение ошибок во всем коде и использование клиентских валидационных тестов гарантируют, что клиент получит рабочий прототип или действительно работающее программное обеспечение за меньшее время, чем обычно.
Экстремальное программирование также помогает компаниям удовлетворить своих клиентов и сохранить свой бизнес в течение более длительного времени.
В методологии экстремального программирования каждый является равным членом стада, и каждый должен разделить бремя наравне со своими коллегами, а это означает, что от требований до кода разработчики будут работать бок о бок, чтобы никто не чувствовал себя недооцененным или забытым.

Жизненный цикл экстремального программирования (XP)

Жизненный цикл XP можно объяснить относительно недельного цикла и квартального цикла.

Для начала заказчик определяет набор историй. Команда оценивает размер каждой истории, что наряду с относительной выгодой, оцененной покупателем, указывает на относительную ценность, используемую для определения приоритетов историй.

В случае, если некоторые истории не могут быть оценены командой из-за неясных технических соображений, они могут ввести Spike. Всплески называются короткими временными рамками для исследований и могут возникать до начала регулярных итераций или одновременно с текущими итерациями.

Далее идет план выпуска: план выпуска охватывает истории, которые будут представлены в определенном квартале или выпуске.

В этот момент начинаются недельные циклы. В начале каждого недельного цикла команда и заказчик встречаются, чтобы определить набор историй, которые будут реализованы на этой неделе. Затем эти истории разбиваются на задачи, которые необходимо выполнить в течение этой недели.

Выходные с обзором прогресса на сегодняшний день между командой и заказчиком. Это приводит к решению, следует ли продолжать проект или была ли достигнута достаточная ценность.

Практические примеры экстремального программирования (XP)

XP для Krizp System

Проблема

Krizp Solution была начинающей компанией по веб-разработке в Индии. Их бизнес-план предусматривал создание веб-порталов для других небольших компаний или учебных заведений. Компания начинала как бизнес с частичной занятостью, нанимая людей, которые уже работали в других крупных ИТ-организациях. План состоял в том, чтобы продолжать работать полный рабочий день только в том случае, если стартап добьется успеха. У них не было рамок для их процессов разработки программного обеспечения, поскольку это была просто стартап-компания с небольшим количеством проектов и несколькими сотрудниками.

Компании не хватало структурированного подхода к разработке программного обеспечения. После того, как первоначальные требования были записаны на бумаге, дальнейшая информация и разъяснения были получены от заказчика по телефону. Обычно серьезные изменения в требованиях не вносились до проверки заказчиком, которая проводилась уже после разработки решения.

Помимо исправления ошибок, разработчики практически не общались друг с другом. Они работали отдельно над разными функциями. Это стало препятствием для обсуждения вопросов улучшения методов работы.

Более того, проекты не были задокументированы. Не было менеджера проекта, который бы следил за проектами или следил за тем, чтобы требования, изложенные заказчиком, выполнялись. Разработчики работали только над тем, что просили сделать.

Путешествие

сертификация экстремального программирования

Команда Krizp System познакомилась с концепциями различных фреймворков Agile. Метод XP применялся в течение одного месяца, и оценивались результаты.

Генеральный директор компании взял на себя 2 роли: представителя заказчика и трекера. Для своей первой роли он отдавал приоритет пользовательским историям, делегируя их команде разработчиков, и регулярно общался с заказчиком. Как следопыт, он следил за временем выполнения конкретных задач. Генеральный директор также инициировал игру планирования каждую неделю (или хотя бы раз в четыре дня), так как проект был небольшим, и разработчики могли быстрее выполнять задачи в одной пользовательской истории. Однако клиент был доступен для прямого общения только два раза в месяц, а в остальное время он был на связи посредством телефонных звонков и электронной почты.

Был принят метод парного программирования, при котором оба разработчика работали вместе. После выполнения задачи оба разработчика просматривали код вместе с генеральным директором.

Были введены клиентские тесты, и команда работала над непрерывными улучшениями дизайна, которых было около 12-15 в месяц.

Резюме

Подход, основанный на XP, оказал положительное влияние на цикл разработки программного обеспечения в компании. Некоторые из положительных изменений включали:

Лучшее сотрудничество в команде, общение и обратная связь
Лучшее управление задачами и временем, а также
Расширение участия генерального директора без технического участия.

Практики экстремального программирования для IBM и Sabre Airlines

Проблема

Чтобы оценить практическое применение Waterfall vs. Extreme Programming, было проведено исследование с использованием двух тематических исследований: одно в IBM, а другое в Sabre Airlines. В каждом тематическом исследовании каскадный подход сравнивался с подходом XP.

Путешествие

В первом тематическом исследовании в IBM исследователи хотели изучить влияние подхода XP на производительность, качество и удовлетворенность клиентов. В группе из 7–11 человек было проведено годичное исследование по внедрению практики XP. Эта группа отвечала за разработку приложений Servlet/XML для инструментария, используемого другими командами IBM для создания продуктов для внешних заказчиков. В тематическом исследовании были проанализированы 2 подхода к последовательным выпускам одного и того же продукта. Первым был традиционный водопадный подход, а вторым — XP.

Во втором тематическом исследовании в Sabre Airline Solutions использовался тот же метод, т. е. сравнение двух подходов в разных выпусках одного и того же продукта. Команда работала над созданием графической среды с поддержкой сценариев для внешних клиентов, чтобы разрабатывать индивидуальные приложения для конечных пользователей и бизнес-приложений. Команда состояла из 6-10 человек. Старый выпуск был завершен за 3 года до этого (охватывал 18 месяцев) с использованием метода водопада, тогда как новый выпуск был завершен недавно (охватывал 3,5 месяца) с использованием XP.

Первым шагом было создание системы оценки экстремального программирования (XP-EF), которая состояла из трех частей: Факторы контекста XP (XP-cf), Метрики приверженности XP (XP-am) и Показатели результатов XP (XP-om):

Факторы контекста XP (XP-cf) : XP-cf использовался для записи важной информации, связанной с проектом. Эти факторы включали размер команды, размер проекта, критичность и опыт персонала.
Показатели приверженности XP (XP-am) : с помощью XP-am была выражена степень, в которой команда использует методы XP. XP-am также помог в исследовании взаимодействий и зависимостей между практиками XP, а также степени, в которой методы могут быть отделены или удалены.
Показатели результатов XP (XP-om) : XP-cm позволяет оценивать результаты, связанные с бизнесом, т. е. производительность, качество и т. д.

В дополнение к структуре были проведены интервью с членами команды и клиентами, чтобы помочь понять, как команда внедряет XP для удовлетворения клиентов.

Резюме

В IBM метод XP показался более продуктивным по сравнению с методом водопада по следующим показателям:

Дефекты тестирования : для предварительной версии дефектов было на 50% меньше, а для пострелизной версии дефектов было примерно на 40% меньше в версии благодаря подходу XP.
Производительность : при использовании XP-подхода продуктивность персонала значительно увеличилась, чем при водопадном методе.
Удовлетворенность клиентов. Удовлетворенность клиентов была отмечена как высокая в XP и задокументирована как Н/Д для водопада.
Моральный дух: Моральный дух заинтересованных сторон был зафиксирован как высокий в XP и задокументирован как Н/Д для водопада.

В Sabre Airlines были замечены аналогичные результаты:

Период сбора дефектов : поскольку первый релиз создавался в течение 18 месяцев, период сбора дефектов также был больше при каскадном подходе. В версии для XP он был значительно короче.
Дефекты тестирования : в пререлизе дефектов было на 65% меньше, а в пострелизе дефектов было примерно на 46% меньше в релизе благодаря подходу XP.
Производительность : Производительность персонала при использовании XP-подхода была примерно на 46% выше, чем при водопадном методе.
Удовлетворенность клиентов. Удовлетворенность клиентов была отмечена как высокая в XP и задокументирована как Н/Д для водопада.
Боевой дух: моральный дух заинтересованных сторон составлял около 68% XP и документально подтвержден как N/A для водопада.

Варианты использования и применение

Вариант использования 1: веб-разработка

Постановка проблемы: Сайт компании нуждается в редизайне.

Действующие лица: Заказчик, Разработчики, Трекер

Регулярный поток событий:
Заказчик сообщает исходные требования.
Команда разработчиков приступает к программированию.
Команда QA тестирует ошибки и информирует команду программистов
У заказчика больше требований
Цикл повторяется.

Использование XP:

Встреча лицом к лицу называется с участием заказчика и разработчиков.
Заказчик определяет требования, бюджет и сроки в виде истории.
Менеджер проекта становится Трекером и отслеживает ход проекта.
Команда разработчиков начинает работать в парах. Код пишется и отлаживается одновременно.
Каждую неделю проводится собрание для обсуждения прогресса. Заказчик может определить новые требования.
Каждую четверть проводится собрание для обсуждения статуса историй.
После завершения старых историй формируется новый набор историй (требования на следующий квартал)

Вариант использования 2: разработка игр

Постановка задачи: Клиент требует, чтобы игра была разработана с нуля.

Действующие лица: Заказчик, Разработчики, Трекер

Регулярный поток событий:

Заказчик указывает требования, время и бюджет.
Разработчики начинают программировать.
Команда QA тестирует игровые модули.
У заказчика больше требований.
Цикл повторяется.

Использование XP :

Встреча лицом к лицу называется с участием заказчика и разработчиков.
Заказчик определяет требования, бюджет и сроки в виде сюжета (модулей игры).
Менеджер проекта становится Трекером и отслеживает ход разработки игры.
Команда разработчиков начинает работать в парах. Код для разных модулей пишется и отлаживается одновременно.
Каждую неделю проводится собрание для обсуждения прогресса. Заказчик может определить новые требования.
Каждую четверть проводится собрание для обсуждения статуса историй.
После завершения старых историй, т.е. завершения высокоприоритетных модулей, формируется новый набор историй (требования на следующий квартал)

nTask для экстремальных практик программирования (XP)

nTask — это система управления задачами, поддерживающая Agile-метод экстремального программирования. Это онлайн-приложение для управления задачами, разработанное специально для командной работы и выполнения проектов. Независимо от отрасли, nTask поддерживает методологию XP и способствует эффективному планированию проектов и согласованию процессов.

Ниже приведены некоторые из способов, которыми nTask может помочь вам лучше планировать и достигать целей вашего проекта, и все это в рамках XP.

Планирование встреч

Вы можете запланировать свои сидячие забастовки, еженедельные собрания, а также ежеквартальные собрания заранее. Повестку дня и время проведения встреч можно уточнить. Вы можете определить фиксированное время для встречи или разослать команде предложенное время, которое будет окончательно согласовано после ответа команды.

Это приложение также позволяет записывать все важные моменты, обсуждаемые на встрече. Затем протокол можно просмотреть и опубликовать для остальной части команды.

Распределение команды

Вы можете организовать свою команду и роли, которые они будут выполнять, в разделе распределения команд. Вы можете легко определить роли для разработчиков, трекеров и клиента.

Создание проекта

Заказчик может создать проект и указать требования. Заказчик также может определить бюджет и сроки.

Создание и назначение задач

Заказчик может создавать истории, создавая задачи в рамках проекта. Задания будут состоять из списка действий, которые необходимо выполнить в рамках одной истории. Затем эти истории можно передать программистам.

Если истории завершены досрочно некоторыми членами команды, заказчик может назначить им «незавершенные» задачи, т. е. задачи с более низким приоритетом в пределах оставшегося срока. Это экономит время, ускоряя работу над завершением проекта.

Также см:

Представляем nTask 2.0 — наше самое долгожданное обновление

Ход проекта

Менеджер проекта или трекер могут помочь отслеживать поток проекта через модуль расписания. Этот модуль позволяет эффективно отслеживать и оценивать ход проекта. Это также помогает индивидуально оценить график выполнения различных задач, а также достигнутые или ожидающие вехи.

Простое сотрудничество

Иногда невозможно проводить встречи лицом к лицу, например, когда определенная команда работает над другим сайтом. В таких случаях автоматические обновления проектов, задач и собраний могут обеспечить своевременную и эффективную совместную работу и обсуждение в команде. Это позволяет избежать траты времени на ручную организацию выполнения проекта и выполнения задач, передачу протоколов совещаний или обновление проекта.

Комментарии в реальном времени — это простой способ общения с командой. Будь то обмен информацией или новые идеи, это позволяет команде оставаться на одной волне.

Взаимозависимые задачи выделяются, и каждый член команды может мгновенно проверять обновления, которые обновляются другими членами команды. Это позволяет команде быть в курсе меняющихся ситуаций и соответственно планировать следующую задачу.

Более того, клиент может напрямую сотрудничать с командой и обновлять любые изменения в требованиях.

Прозрачность

nTask дает прозрачное представление обо всех проектах и соответствующих задачах и подзадачах через свою панель задач. О любом созданном или измененном проекте немедленно сообщается команде. Нет необходимости перепроверять обновления прогресса, приглашения на встречи или отчеты по проектам.

Обновленные, измененные или удаленные задачи позволяют всей команде полностью осознавать и точно знать, что и когда выполняется.

С помощью параметра «Фильтр» вы можете выбрать отображение обновлений для выбранных проектов в зависимости от приоритета или текущей задачи. С помощью параметра Статус можно увидеть статус выбранной задачи, запущена она или нет, завершена или выполняется.

Вывод

В этой статье подробно рассказывается, как вы можете извлечь выгоду из XP в качестве Agile-работника. Кроме того, nTask создан для выполнения таких требований в области экстремального программирования и методов водопада. Поэтому прочтите его и не забудьте поделиться своими мыслями в разделе комментариев ниже. Кроме того, вы можете написать нам по адресу [email protected] .