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

Гибкая методология разработки программного обеспечения представляет собой гибкий подход к процессу разработки программного обеспечения. Agile-разработчики программного обеспечения используют интерактивные методы доставки программных продуктов по частям (непрерывные выпуски MVP), включая отзывы заинтересованных сторон.

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

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

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

В сегодняшней быстрорастущей и конкурентной экономике идеально подходят гибкие и регулируемые итерации Agile.

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

Продолжайте читать эту статью, если вам нужно краткое введение.

Принципы, шаблоны и практика гибкой разработки программного обеспечения

4 Agile-ценности

В 2001 году группа менеджеров по программному обеспечению и заинтересованных лиц собралась, чтобы подумать о том, как улучшить SDLC. На этом собрании они разработали 4 ценности и 12 принципов Agile.

Вот самые известные 4 ценности Agile:

1. Индивиды и взаимодействие над процессами и инструментами:

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

Как вы, возможно, уже заметили, четыре ценности Agile отдают предпочтение одному достоинству перед другим. Иногда это может напоминать нам о сравнении Agile и Waterfall.

2. Рабочее программное обеспечение по исчерпывающей документации:

В последовательных жизненных циклах аутсорсинга программного обеспечения, таких как Waterfall, мы просматриваем много документации, прежде чем начать партнерство по аутсорсингу программного обеспечения. Некоторые из этих документов включают SRS или документ с требованиями пользователя, диаграммы последовательности, диаграммы UML и т. д. В Agile важнее всего работающее программное обеспечение, а не исчерпывающая документация.

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

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

3. Сотрудничество с клиентами в ходе переговоров по контракту:

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

4. Реагирование на изменения по плану:

В любом проекте аутсорсинга программного обеспечения у нас есть план, который важен, поскольку он является краеугольным камнем проекта. В последовательных моделях разработки программного обеспечения, таких как Waterfall, разработчики программного обеспечения и другие члены технической команды получают указание от руководства «придерживаться плана», но в Agile все наоборот. План имеет решающее значение для формирования представления о будущем пользовательском программном обеспечении. Однако, если обстоятельства меняются во время SDLC и изменение плана более выгодно, Agile-команды реагируют на изменения.

Например, управленческая команда выбирает один из популярных инструментов, используемых в Agile-разработке программного обеспечения, напр. Jira, Trello и Asana, но через некоторое время понимают, что инструмент не так эффективен, как они думали. Поскольку методология Agile разработки программного обеспечения ценит прозрачность SDLC, качество программного обеспечения и гибкую коммуникацию, команда без колебаний заменит неэффективный инструмент.

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

Основное различие между Agile и Waterfall или любыми последовательными моделями разработки

Жизненный цикл разработки ПО: Waterfall vs Agile

В проектах Waterfall у нас есть:

• Фиксированные требования
• Четкая техническая документация
• Расчетное время и ресурсы

В проектах Agile мы меняем значения.

У нас нет фиксированных требований, вместо этого у нас есть фиксированные ресурсы и время.

Планирование проектов в Agile-компаниях по разработке программного обеспечения

1. Видение продукта: команда четко определяет цель своего программного обеспечения. Какую проблему решает это программное обеспечение? Чем он отличается от других подобных программных решений? Видение продукта создается владельцем продукта и должно пересматриваться не реже одного раза в год, если мы говорим о крупных и стабильных предприятиях.
2. Дорожная карта продукта: Дорожная карта продукта, как и видение продукта, представляет собой тип высокоуровневого планирования. Это обзор высокого уровня требований к продукту, который создает видение продукта. Дорожная карта продукта должна обновляться и пересматриваться не реже двух раз в год.
3. Планирование выпуска: Планирование выпуска также включено в высокоуровневое планирование продукта, однако оно является более конкретным, чем видение продукта и дорожная карта продукта. Владелец продукта планирует выпуск, указывая последовательность выпуска и тип приращений продукта (версий), которые должны быть выпущены на рынок. Планирование выпуска должно осуществляться не реже одного раза в квартал.
4. Планирование спринта: в Scrum планирование спринта — это совместная деятельность членов команды Scrum, включая владельца продукта. Команда Scrum создает цели итерации, задачи и результаты и повторяет процесс каждые 1–4 недели.
5. Ежедневный скрам: в Agile-командах члены команды проводят ежедневные собрания, на которых обсуждают текущие задачи, которые помогут в достижении цели итерации.

В конце каждой итерации или спринта Agile-проекты имеют 2 формы планирования:

• Обзор спринта. Обзор спринта включает в себя демонстрацию созданного продукта и выполняется владельцем продукта и командой разработчиков программного обеспечения в конце каждого спринта.
• Ретроспектива спринта: собрание ретроспективы спринта организуется для оценки прогресса команды. Во время ретроспективы спринта члены Agile-команды обсуждают процессы и среды и составляют планы по улучшению процессов в следующем спринте.

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

Как составляется документация по техническим требованиям в методологии разработки программного обеспечения Agile?

Пользовательские требования в Agile записываются в форме, которая называется «пользовательская история».

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

Гибкие методологии

Существует 3 наиболее широко используемых и популярных методологии разработки программного обеспечения Agile. Это:

Скрам

Что такое методология Agile Scrum? Успешная разработка программного обеспечения Agile с использованием Scrum.

Scrum — это гибкая система управления проектами, которая помогает командам продуктивно работать вместе. Scrum описывает набор собраний, инструментов и ролей, которые работают вместе, чтобы помочь командам структурировать свою работу и управлять ею. В методологии Scrum Agile наиболее широко используемым инструментом является JIRA Atlassian.

Что такое инструмент Jira Scrum? Jira для Agile-компаний, занимающихся разработкой программного обеспечения.

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

Канбан

Что такое методология Agile Kanban? Успешная разработка программного обеспечения Agile с использованием Канбан.

Канбан — это подход к управлению, который иногда используется в Agile-проектах. Общая цель Канбана — визуализировать и оптимизировать рабочий процесс в цепочке добавленной стоимости.

Канбан — это не традиционный Agile-подход, такой как Scrum. Вместо этого он используется в работе и управлении задачами в целом. В методологии Канбан самым популярным инструментом является Trello.

Что такое инструмент Trello Kanban? Trello для компаний, занимающихся разработкой программного обеспечения Agile

Trello — продукт Atlassian, как и Jira. Таким образом, если вы уже зарегистрированы в Jira, вы можете использовать те же учетные данные для регистрации в Trello. В отличие от Jira, основанной на Scrum, Trello основан на Kanban. Его можно считать доской Канбан. Trello состоит из отдельных досок. Trello предоставляет шаблоны для Agile-управления проектами, продуктами и командами. Команды разработки программного обеспечения Agile используют любой доступный шаблон Agile для работы с принципами Agile и управления проектами разработки программного обеспечения по итерациям/спринтам.

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

XP — это методология Agile, популярная в командах разработчиков программного обеспечения с 1990-х годов. XP фокусируется не только на управлении проектами (как в Scrum), но и на создании кода. Если Scrum фокусируется на управлении работой, определяет конкретные роли в проекте и делит проект на итерации, то XP также фокусируется на разработке и тестировании программного обеспечения (а не на управлении аутсорсингом разработки программного обеспечения).

Вот наиболее важные определения в XP:

Ежеквартальный цикл: раз в квартал команда XP организует встречи для планирования и анализа.

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

И квартальные, и недельные циклы сейчас редко используются в Agile-проектах. Большинство Agile-команд сейчас используют Scrum для управления проектами: выпуск — невыполненная работа над продуктом — планирование спринта — невыполненная работа в спринте.

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

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