В контексте темы бережливого производства в ИТ, сегодня мы расскажем про анализ требований к разработке ПО в условиях Agile-подходов к организации работы и соответствия жестким рамкам отечественных ГОСТов и зарубежных стандартов. Читайте в нашей статье, что говорит BABOK по этому поводу и когда нужно запускать процесс создания программной документации, чтобы потом не было мучительно больно.
Лишнее для Lean или в чем ценность поддерживающих процессов?
На первый взгляд с позиции бережливого производства (Lean) разработка требований не добавляет ценности конечному продукту, а является поддерживающим процессом для основной деятельности (собственно разработки ПО). Например, в этой статье мы рассматривали выявление требований в качестве иллюстративного примера для функционально-стоимостного анализа, а здесь – для объяснения метода Value Stream Mapping (картирование потоков создания ценностей). Напомним, одна из 4-х основных идей Agile Manifesto гласит, что работающий продукт важнее исчерпывающей документации [1]. Поэтому у команды проекта, работающей по Agile (Scrum, Kanban, XP и прочие гибкие методологии) может возникнуть соблазн исключить или максимально сократить этот этап. Однако, стоимость ошибки многократно возрастает по мере развития проекта [2]. Поэтому отказываться от анализа требований нельзя. Впрочем, на самом деле Agile и не призывает к столь радикальным решениям, предлагая методологию гибкого моделирования – Agile Modelling. Она предполагает непрерывное документирование параллельно с выполнением остальных задач гибкой разработки ПО (непосредственно кодирования, тестирования и развертывания). При этом требования определяются в форме исполняемых «пользовательских тестов» вместо статической документации [3].
Об этом же говорит профессиональный стандарт бизнес-аналитика, руководство BABOK, включив Agile в набор 5 ключевых перспектив. В главе, посвященной анализу в условиях гибкого подхода, BABOK подчеркивает, что аналитик продолжает выполнять свои прямые обязанности по взаимодействию со стейкхолдерами, чтобы выявить бизнес-потребности и определить, как создаваемый продукт совпадает с задачами организации, помогая достичь поставленные цели. При этом в зависимости от видения продукта генерируется бэклог (backlog) – приоритетный список рабочих задач, которые необходимо выполнить в первую очередь. В соответствии с Lean-концепцией, приоритизация пунктов бэклога основана на принципе максимальной ценности для потребителя [4]. Однако, несмотря на позиционирование в качестве профессионального руководства, BABOK – это свод знаний, а не жесткий шаблон готовых решений с пошаговым описанием способа выполнения работ. В отличие от ГОСТов и зарубежных стандартов, он не регламентирует процедур создания программной документации, в частности, технического задания (ТЗ). А на постсоветском пространстве часто именно ТЗ до сих пор считается основным результатом деятельности аналитика, что не совсем коррелирует с принципами Agile и реальностью современных проектов. Тем не менее, на самом деле работа по ГОСТам абсолютно не противоречит Agile, о чем и мы поговорим далее.
Аналитика больших данных для руководителей
Код курса
BDAM
Ближайшая дата курса
13 января, 2025
Продолжительность
24 ак.часов
Стоимость обучения
72 000 руб.
Стандарты разработки требований и Agile: комбо или противостояние?
Из отечественных стандартов требования к проектируемой системе в форме ТЗ регламентируют ГОСТ 34.602-89 «Техническое задание на создание автоматизированной системы» и ГОСТ 19.201-78 «Техническое задание, требования к содержанию и оформлению». Они оба содержат по 9 разделов с похожим назначением, но отличаются по специфике применения. ГОСТ 34.602-89 описывает ТЗ на автоматизированную систему, включая программное и аппаратное обеспечение, пользователей и автоматизируемые процессы. А ГОСТ 19.201-78 предназначен именно для ПО. Некоторые ИТ-специалисты эти ГОСТы устаревшими, однако большинство государственных учреждений, выступая в роли Заказчика, требуют соблюдение этих стандартов. Кроме того, хоть данные документы и не являются непосредственным исходником для программистов, на основе которых они создают программный код, данные стандарты позволяют достаточно подробно описать основные бизнес-потребности и ключевое назначение будущего продукта [5].
Зарубежный стандарт ISO/IEC/IEEE 29148:2018 «Systems and software engineering — Life cycle processes — Requirements engineering» предполагает более детальное описание требований, чем вышеупомянутые отечественные ГОСТы. Однако, если разрабатывать ТЗ на будущую систему в соответствии с этим документом, это потребует слишком много ресурсов и задержит создание продукт, что не соответствует принципам Agile. Поэтому, с учетом возможности изменений на любых стадиях проекта, целесообразна итерационная проработка требований по мере его развития.
Таким образом, в Agile-проекте не стоит подробно документировать все требования в самом начале. Сперва следует определить бизнес-потребности, затем выявить высокоуровневые требования и изложить их в виде пользовательских историй (user story). Именно ими наполняется бэклог проекта, после чего начинается приоритизация задач. Данный цикл повторяется на каждый итерации по мере развития проекта. При этом следует как можно раньше определить нефункциональные требования, чтобы спроектировать архитектуру системы для обеспечения производительности, удобства использования, доступности и другие цели по качеству. Напомним, пользовательская история — это краткое утверждение, которое выражает потребность пользователя и служит исходной точной для общения с целью выяснения деталей [6]. Подробнее про формулирование требований в конструкциях языка Gherkin мы рассказывали здесь.
Реализация каждой пользовательской истории отслеживается с помощью статуса входящих в нее задач по принципу канбан-доски, например, так [6]:
- в бэклоге – история пока не назначена на конкретную итерацию;
- определена – подробности истории обсуждены и поняты, приемочные тесты написаны;
- разработка – история в процессе реализации;
- завершена – история полностью реализована;
- принята – пройдены приемочные тесты;
- заблокирована – разработчик не может продолжить разработку, пока не будут разрешены другие вопросы.
С практической точки зрения более ценны требования в виде UML-диаграмм и задач в Jira (или аналогичном системе), чем набор статических текстовых документов в строгом соответствии с ГОСТами или зарубежными стандартами. Однако, последние являются обязательными при сдаче готового решения Заказчику. Поэтому разработка таких документов тоже является неотъемлемой частью процесса создания готового продукта. При этом, разработка программной документации по ГОСТам выполняется параллельно с кодированием, тестированием и развертыванием, углубляясь в детали с каждым итерационным циклом. В любом случае, прежде всего выявляются основные бизнес-потребности, определяются ключевые высокоуровневые требования и формализуются в виде пользовательских историй. Так формируется документ с содержанием и границами проекта (project scope) и бэклог продукта, на основании чего и планируется дальнейшая работа.
Поэтому строгая регламентация требований и другой программной документации по отечественным ГОСТам и зарубежным стандартам совсем не противоречит принципам Agile, а органично дополняет их. Таким образом, адаптивность гибких подходов сдерживается четкостью формальных рамок, объединяя преимущества обоих сторон.
Разработка и внедрение ML-решений
Код курса
MLOPS
Ближайшая дата курса
11 ноября, 2024
Продолжительность
24 ак.часов
Стоимость обучения
54 000 руб.
Подробно разработка и управление требованиями к ПО, а также другие практические вопросы системного и бизнес-анализа разбираются в рамках нашего нового образовательного направления «Школа прикладного бизнес-анализа«. А также особенности применения Agile-принципов к внедрению ML, примерам цифровизации бизнеса и практическим кейсам аналитики больших данных вы узнаете на наших образовательных курсах в лицензированном учебном центре обучения и повышения квалификации руководителей и ИТ-специалистов (менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data) в Москве:
Источники
- https://ru.wikipedia.org/wiki/Гибкая_методология_разработки
- http://okiseleva.blogspot.com/2018/03/blog-post_59.html
- https://en.wikipedia.org/w/index.php?title=Agile_Modeling
- https://analytics.infozone.pro/babok-3-chapter-11-agile-perspective/
- https://habr.com/ru/post/328822/
- https://analytics.infozone.pro/requirements-analysis/agile-software-development/
