Кто я

Engineer in nature...

Прошел путь от сисадмина в регионе до IT архитектора в крупнейшем банке страны за 8 лет. Если интересны детали, узнать подробнее можно здесь.

О чем пойдет речь

Хочу провести обзорную экскурсию по мировым Best-Practice в Software Engineering, которые мне удалось получить в течении жизни.

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

Где я этому научился

Данные знания были получены в процессе обучения в университете Innopolis на специальности MSIT-SE. Применяются повсеместно.

Подробнее о программе обучения

Программа Software Engineering (MSIT-SE) в Innopolis является адаптированной программой Master of Informational Technologies университета Carnegie Mellon University (CMU)

Основные курсы:
17-602 Introduction to Personal Software Process
17-651 Models of Software Systems
17-652 Methods: Deciding What to Design
17-653 Managing Software Development
17-654 Analysis of Software Artifacts
17-655 Architectures for Software Systems

Промышленный проект:
17-677 MSIT Project - на вашу тематику

Факультативы:
- Pattern Oriented Designn
- Estimating Software Development Projects
- User Experience and User Interface Design Fundamentals
- Dynamic Software Testing
- Lean Software Development
- Cloud Computing
- Data Oriented Approach in Practice
- Advanced Java

А так же многие другие программы на выбор.

 Основное чему научился на программе - "It depends" и "There is no silver bullet".

Оглавление

Нажми чтобы открыть

Введение

Источники требований

• Выявление различных заинтересованных сторон в процессе

• Понимание, где и как собрать эти требования

Методы сбора требований

• Важность сбора требований при разработке программного обеспечения

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

• Примеры

Функциональные и нефункциональные требования

• Понимание функциональных и нефункциональных требований на примерах

• Важность обоих в успешной программной системе

Процесс создания спецификации продукта

• Как использовать собранные требования для создания подробной спецификации продукта

• Роль различных заинтересованных сторон в этом процессе

Распределение времени в процессе разработки

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

Этапы производственного процесса

Заключение

• Резюме процесса разработки программного обеспечения

• Акцент на важности ориентированного на пользователя подхода в методологии Agile

---

Введение

В рамках данной публикации мы рассмотрим тонкости процесса разработки программного обеспечения, от начальных стадий сбора требований до заключительных стадий развертывания продукта. Углубимся в методологию Agile и то, как она влияет на процесс разработки, делая его более гибким и итеративным. На примере разработки книжного интернет-магазина, мы изучим различные аспекты сбора и анализа требований, использование различных методов, таких как пользовательские истории (User Story), варианты использования (Use Case), моделирование целей (Goal Modeling) и персон (Personas), а также создание всеобъемлющей спецификации продукта.

---

Источники требований

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

1. Конечные пользователи (End Users): это лица, которые будут непосредственно использовать систему. Они могут дать важную информацию о том, как должна функционировать система и какие функции она должна включать для эффективного выполнения своих задач.

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

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

4. Владельцы продукта или бизнес-аналитики (Product Owners or Business Analysts). В контексте гибкой разработки владелец продукта играет центральную роль в сборе, интерпретации и приоритизации требований на основе их понимания потребностей пользователей и бизнес-целей.

5. Специализированные эксперты (Subject Matter Experts SME): это лица, обладающие специальными знаниями в определенной области, связанной с системой, например эксперты по правовым вопросам или данным. МСП могут предложить глубокое понимание конкретных аспектов системных требований.

6. Регулирующие органы (Regulatory Bodies): если программная система работает в регулируемой области (например, здравоохранение или финансы), к ней будут предъявляться требования, продиктованные соответствующими законами, правилами и стандартами. Эти требования обеспечивают соблюдение правил конфиденциальности данных, отраслевых рекомендаций и т. д.

7. Системные или программные архитекторы (System or Software Architects). Эти технические заинтересованные лица могут определять определенные нефункциональные требования на основе системных ограничений или лучших технических практик, таких как требования к производительности, требования безопасности и требования к ремонтопригодности.

8. Существующие системы или системная документация (Existing Systems or System Documentation): если новую систему необходимо интегрировать с существующей системой или заменить ее, сама существующая система вместе со всей сопутствующей документацией может быть источником требований.

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

---

Методы сбора требований

Сбор требований (Requirements Gathering), также известный как выявление (Requirements Elicitation) требований, является важным шагом в любом проекте, особенно в разработке программного обеспечения. Он включает в себя выявление и документирование потребностей и ожиданий заинтересованных сторон для определения четких, кратких и действенных требований.

Вот некоторые из передовых методов сбора требований:

1. Анализ заинтересованных сторон (Stakeholder Analysis): Суть в определении всех лиц или групп, которые заинтересованы в проекте или будут затронуты его результатами. Заинтересованные стороны могут варьироваться от конечных пользователей, членов команды проекта, спонсоров до регулирующих органов.

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

3. Фокус-группы (Focus Groups): Это обсуждения с группой заинтересованных сторон. Фокус-группы позволяют проводить интерактивные обсуждения и выявить различные точки зрения на требования.

4. Опросы/анкеты (Surveys/Questionnaires): Когда вам нужно собрать информацию от большой группы людей, опросы и анкеты - ваш выбор. Они должны быть хорошо продуманы. Важно чтобы вы задавали правильные вопросы для сбора необходимых данных.

5. Анализ документации (Document Analysis): Банально просмотрите существующую документацию, связанную с проектом, такую как предыдущие отчеты по проекту, диаграммы процессов (Process Diagrams), диаграммы последовательности (Sequence Diagrams), мануалы, правила регуляторов и прочее. Помните - чем больше информации вы получите, тем более точные решения могут быть приняты на ее основе. А так же это даст представление о текущих проблемах и возможностях для улучшения. Как говорится - дьявол кроется в деталях!

6. Наблюдение/стажировка (Observation/Job Shadowing): Понаблюдайте за конечными пользователями в их естественной среде, чтобы понять их потребности и проблемы. Этот метод часто позволяет сгенерировать необычные идеи, которые могут не проявиться в ходе интервью или опроса.

7. Семинары (Workshops): Семинары включают в себя организацию встреч ключевых заинтересованных сторон, для совместного определения и согласования требований. Квалифицированный фасилитатор (координатор) может вести эти сессии, чтобы они были продуктивными и не отклонялись от намеченного курса.

8. Прототипирование (Prototyping): Еще один важный метод - можно разработать прототип (предварительную версию продукта), чтобы помочь заинтересованным сторонам визуализировать конечный результат. Это позволяет обеспечить немедленную обратную связь и помогает разъяснить и уточнить требования.

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

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

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

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

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

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

Примеры

Давайте проиллюстрируем User Story, Use Case и Goal Modeling на простом примере, связанном с гипотетическим книжным интернет-магазином:

Пользовательские истории (User Story)

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

Вот пример:

Я, как «Клиент»,
Хочу иметь возможность "искать книги по названию, автору или номеру издания ISBN"
для того, чтобы «я мог быстро найти книгу, которую ищу».

Варианты использования (Use Cases)

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

Вот базовый вариант использования пользовательской истории выше:

Моделирование целей (Goal Modeling)

Моделирование целей используется для понимания и описания того, что должна делать система, т. е. ее целей. Цели могут быть высокого уровня (стратегические цели) или низкого уровня (операционные цели). Вот простая модель цели для книжного интернет-магазина:

• Цель высокого уровня: «Предоставить покупателям удобную онлайн-платформу для покупки книг».

  • Подцель 1: «Предоставить клиентам возможность быстро и эффективно искать книги» (это связано с нашей пользовательской историей и вариантом использования).

  • Подцель 2: «Обеспечить безопасные способы онлайн-платежей».

  • Подцель 3: «Предложить рекомендации, основанные на истории просмотров клиентов».

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

---

Функциональные и нефункциональные требования

Давайте углубимся в функциональные и нефункциональные требования, их важность и рассмотрим некоторые примеры.

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

Пример 1: Базовый пример ФТ на примере книжного интернет-магазина:

- Система должна позволять пользователям просматривать список доступных книг.

- Система должна позволять пользователям добавлять выбранные книги в корзину.

- Система должна позволять пользователям оформлять заказ и производить оплату.

Пример 2: Более близкий к реальности, на примере того же книжного интернет-магазина:

1. Функция поиска

Система должна позволять покупателям искать книги по следующим параметрам:

• По названию: когда пользователь вводит строку в строку поиска, система возвращает список книг с названиями, содержащими эту строку.

• По автору: если пользователь вводит имя автора в строке поиска, система возвращает список книг, написанных этим автором.

• По ISBN: если пользователь вводит ISBN в строке поиска, система должна вернуть конкретную книгу, связанную с этим ISBN.

2. Отображение информации о книге

При выборе книги из результатов поиска система выводит подробную информацию о книге, в том числе:

• Заголовок книги

• Авторы

• ISBN

• Описание книги

• Цена

• Статус Доступности

3. Функционал корзины

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

• Добавить книги в корзину

• Просмотр списка книг в корзине

• Отрегулируйте количество каждой книги в корзине

• Убрать книги из корзины

4. Оформление заказа и оплата

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

• Показать сводку всех книг в корзине пользователя, включая общую цену и количество

• Разрешить пользователям вводить информацию о доставке

• Предлагайте несколько безопасных способов оплаты, таких как кредитная карта, дебетовая карта или цифровой кошелек.

• Создание счета/квитанции после успешной оплаты

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

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

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

Пример 1: Базовый, для того же интернет-магазина:

- Система должна поддерживать 10 000 одновременных пользователей (производительность).

- Система должна быть доступна 24/7, время простоя не более 5 часов в год (Доступность)

- Система должна обеспечивать удобную навигацию и визуально привлекательный интерфейс (Юзабилити)

- Все транзакции клиентов должны быть надежно зашифрованы для защиты конфиденциальности пользователей (Безопасность)

Пример 2: Близкий к реальности

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

1. Производительность (Performance)

• Система должна поддерживать до 10 000 одновременных пользователей без ухудшения времени отклика.

• Система должна отображать результаты поиска в течение 2 секунд после отправки запроса.

2. Доступность (Availability)

• Книжный интернет-магазин должен быть доступен 24 часа в сутки, 7 дней в неделю, с ежегодным временем безотказной работы 99,9%.

3. Удобство использования (Usability)

• Новые пользователи должны иметь возможность совершить покупку в течение 10 минут после первого посещения.

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

4. Безопасность (Security)

• Все данные клиентов должны быть зашифрованы при передаче и хранении для защиты конфиденциальности пользователей.

• Система должна соответствовать всем применимым законам о защите данных и конфиденциальности, таким как Общий регламент по защите данных (GDPR).

5. Масштабируемость (Scalability)

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

6. Ремонтопригодность (Maintainability)

• Система должна быть построена по модульному принципу, чтобы можно было легко обновлять ее и исправлять ошибки.

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

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

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

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

---

Процесс создания спецификации продукта

Процесс создания спецификации продукта, особенно часть сбора требований, обычно возглавляет Бизнес-аналитик (BA) или Владелец продукта (PO) в случае Agile-проектов. Они несут ответственность за понимание потребностей бизнеса, общение с заинтересованными сторонами, содействие процессу сбора требований и документирование требований в четкой, краткой и действенной форме.

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

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

1. Анализ заинтересованных сторон (Stakeholder Analysis): начните с определения всех заинтересованных сторон, заинтересованных в проекте. Понимание их потребностей, опасений и ожиданий будет направлять процесс выявления требований.

2. Моделирование целей (Goal Modeling): затем проведите сеансы моделирования целей с заинтересованными сторонами, чтобы понять, чего они хотят достичь с помощью системы.

3. Варианты использования (Use Cases). На основе целей начните разрабатывать варианты использования, которые описывают, как различные участники будут взаимодействовать с системой для достижения своих целей.

4. Персонажи (Personas): на этом этапе создайте персоны, представляющие разные группы пользователей.

5. Интервью, фокус-группы, опросы (Interviews, Focus Groups, Surveys): теперь начните проводить интервью, фокус-группы и опросы, чтобы собрать дополнительную информацию о системных требованиях.

6. Наблюдение/стажировка (Observation/Job Shadowing): наблюдайте за конечными пользователями в их естественной среде, чтобы лучше понять их потребности и проблемы.

7. Прототипы (Prototypes): Разработайте предварительные версии продукта на основе собранных требований.

8. Документирование требований (Documenting the Requirements): после того, как все требования собраны и уточнены, начните документировать их в структурированном виде для создания спецификации продукта. Каждое требование должно быть четким, кратким и действенным.

9. Просмотр и проверка (Review and Validation). Наконец, просмотрите спецификацию продукта со всеми заинтересованными сторонами, чтобы убедиться, что она точно отражает их потребности и ожидания. Внесите необходимые изменения на основе их отзывов.

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

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

Роль заинтересованных сторон в этом процессе

Вот разбивка по ролям, которые обычно играют разные члены команды:

1. Бизнес-аналитик/Владелец продукта (Business Analyst/Product Owner): они являются основными движущими силами процесса сбора требований. Они организуют интервью, семинары и другие мероприятия по сбору информации, анализируют собранную информацию и составляют спецификацию продукта.

2. Менеджер проекта (Project Manager): Менеджер проекта часто тесно сотрудничает с BA/PO, обеспечивая надзор и гарантируя, что собранные требования соответствует объему, срокам и ресурсам проекта. Они также могут облегчить общение между BA/PO и другими заинтересованными сторонами.

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

4. Дизайнеры/разработчики (Designers/Developers): хотя их основная роль в проекте появляется позже, дизайнеры и разработчики должны участвовать в процессе сбора требований. Они могут внести ценный вклад в выполнимость различных требований, а их раннее участие может обеспечить более плавный переход к этапу проектирования и разработки.

5. Аналитики по обеспечению качества (Quality Assurance (QA) Analysts): Как и дизайнеры и разработчики, аналитики по обеспечению качества также должны быть привлечены к работе на раннем этапе. Понимание требований поможет им спланировать процесс тестирования, а также внести свой вклад в ясность и тестируемость требований.

6. UX-исследователи (UX Researchers): если в команду входят UX-исследователи, они могут проводить исследования пользователей, такие как создание персонажей, проведение наблюдений и тестирование прототипов пользователями.

---

Распределение времени в процессе разработки

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

Однако, в общем смысле, вот примерное распределение времени:

1. Сбор и анализ требований (15-20% общего времени): входят все действия, связанные с пониманием и документированием требований к продукту, такие как анализ заинтересованных сторон, интервью, семинары, пользовательские истории и создание сценариев использования, и составление спецификации продукта.

2. Дизайн (10-15% общего времени): входит как архитектурный дизайн системы (как будут взаимодействовать программные компоненты), так и дизайн пользовательского интерфейса.

3. Кодирование/Разработка (30–40 % общего времени): на этом этапе создается реальный продукт. Доля времени, затраченного на это, может сильно различаться в зависимости от сложности продукта, опыта и навыков команды разработчиков.

4. Тестирование (20–25 % общего времени). в него входят все виды тестирования, такие как модульное тестирование, интеграционное тестирование, системное тестирование и приемочное тестирование пользователями. Как и при разработке, время, затрачиваемое на тестирование, может варьироваться в зависимости от сложности продукта и требуемых стандартов качества.

5. Развертывание (5–10 % общего времени). входят все действия по подготовке продукта к запуску, такие как окончательное тестирование, обучение пользователей и настройка рабочей среды.

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

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

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

---

Этапы производственного процесса

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

1. Видение продукта и дорожная карта (Product Vision and Roadmap). Проект начинается с того, что владелец продукта разрабатывает четкое видение того, чего должен достичь продукт, целевой аудитории и того, как он вписывается в цели компании. Это видение формирует дорожную карту продукта, которая представляет собой высокоуровневое представление требований, необходимых для достижения этого видения.

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

3. Планирование спринта (Sprint Planning): команда планирует предстоящий спринт (итерация с ограничением по времени, которая обычно длится 2–4 недели). Они выбирают набор пользовательских историй с наивысшим приоритетом из невыполненной работы для работы в этом спринте.

4. Выполнение спринта (Sprint Execution): команда работает над пользовательскими историями, выбранными для спринта. Это включает в себя проектирование, кодирование, тестирование и интеграцию. У каждого члена часто есть специальная роль, но команда несет коллективную ответственность за выпуск рабочего продукта к концу спринта.

5. Ежедневные стендап-встречи (или Scrum-встречи) (Daily Stand-up (or Scrum) Meetings): это короткие встречи, на которых члены команды обсуждают, что они сделали в предыдущий день, над чем они будут работать в этот день, а также любые препятствия, с которыми они столкнутся. Это гарантирует, что все согласованы, и любые вопросы решаются оперативно.

6. Обзор спринта (Sprint Review): в конце спринта команда представляет завершенную работу заинтересованным сторонам, часто в виде демонстрации. Цель состоит в том, чтобы получить обратную связь и убедиться, что разработанные функции соответствуют потребностям бизнеса.

7. Ретроспектива спринта (Sprint Retrospective): после обзора спринта команда анализирует процесс спринта. Они обсуждают, что получилось хорошо, а что нет, и что можно улучшить в следующем спринте. Это непрерывное обучение и адаптация являются ключом к Agile.

8. Планирование следующего спринта (Next Sprint Planning): цикл повторяется для следующего набора пользовательских историй в бэклоге, при этом команда постоянно уточняет и перераспределяет приоритеты бэклога на основе отзывов заинтересованных сторон и изменений в бизнес-потребностях.

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

---

Заключение

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

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

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

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

От автора публикации

Благодарю за внимание