- PVSM.RU - https://www.pvsm.ru -
По мотивам моей статьи, изданной ранее…
Получить бы медаль, а уж с обратной ее стороной найдем, что делать.
(Георгий Александров)
В подавляющем большинстве работ, посвященных управлению требованиями, которые мне довелось читать [1], [2], [3] и другие, авторы хороводят вокруг заказчика, акцентируя основное внимание читателей, на том, как максимально эффективно организовать работу именно с ним. Ну и конечно, львиная доля труда обычно посвящена вопросам преобразования собранной информации в некие проектные решения, моделирующие разрабатываемую систему, а также оформление их со спецэффектами, бантиками и рюшами. Разумеется это все важно и я ни в коем случае не хочу умолить значение этих аспектов формирования требований, но есть еще и обратная сторона. Ведь дальше требования должны попадать непосредственно в “цех” по производству программного обеспечения. И именно там они, до самого рождения целевого продукта, останутся основным сводом законов и правил, по которым он будет зарождаться и являться миру. Этот факт уже сам по себе определяет важность того, насколько точно требования должны соответствовать интересам специалистов, призванных воплотить их в конечном продукте.
А посему давайте взглянем на качество требований глазами команды исполнителей: разработчиков, специалистов управления качеством, менеджеров проекта. Ведь именно эти люди и являются основными потребителями работы аналитика. И от того насколько точно созданные спецификации подходят конкретной команде для переработки их в готовый программный продукт, зависит качество и конечная себестоимость этого продукта.
Именно работа аналитика в ИТ проектах призвана показать заказчику — продукт его мечты.
Ибо программисты с этой задачей чаще всего не справляются.
Немного о себе. В начале своей карьеры я работал программистом, потом руководителем группы разработки, но через 18 лет — просто кодировать мне стало не интересно и я решил изменить вид своей деятельности, окунувшись в сферу системного анализа и управления проектами. На этом поприще я и тужусь уже десятый год.
Поскольку мне довелось работать во всех трех перечисленных ипостасях в разных софтверных компаниях, я не раз наблюдал перекосы приоритетов в этом триумвирате. Я работал в команде, где должности системного аналитика не было вообще и его роль “растекалась” между программистами – “свободными художниками”. Я работал в команде, где системный аналитик был ее руководителем и истязал разработчиков гаданием на разнообразных диаграммах и «погружением» в несущественные, с их точки зрения, детали предметной области. Была в моей практике команда, руководитель которой слабо себе представлял контент работы и аналитиков и разработчиков, он умел хорошо продавать продукт, поэтому не лез в подробности этой кухни и каждый “варился в своей тарелке”.
К чему я клоню? В команде, разрабатывающей ПО есть здоровый конфликт интересов, как минимум, между группой аналитиков, группой разработчиков и менеджерами проекта. И как любой конфликт, он может быть использован аки возможность постоянного улучшения качества самого процесса создания ПО.
Небольшие команды разработчиков усложняют жизнь отдельным группам социума, большие амбициозные команды портят жизнь всему прогрессивному человечеству
Основная идея этой статьи заключается в том, чтобы обратить внимание аналитиков или тех кто на них активно влияет, на следующий аспект: «Ключевым фактором эффективной разработки ПО, является соответствие плодов деятельности аналитика — потребностям команды, которая будет воплощать их в целевом продукте».
Цель статьи — помочь аналитикам (особенно молодым), совместно с командой, разрабатывающей ПО, найти свой идеальный вариант спецификаций требований, включая: состав, уровень детализации, форму, порядок представления информации и т.п.
Эффект должен быть достигнут за счет того, что члены команды не будут больше тратить время на разгадывание сути, используемых в требованиях артефактов и на преобразование их из формата, тешащего самолюбие аналитика, в формат максимально пригодный для собственного употребления. Им больше не потребуется выискивать нужную информацию «размазанную» по требованиям. Наоборот, материалы, которые будут предоставлены каждому участнику, шпаг за шагом будут заботливо вести их в процессе выполнения своей работы по проекту от релиза к релизу.
Рассматриваемая в статье тема особенно актуальна для команд, которые хотят поставить процесс разработки ПО на поток и построить технологическую линию по производству программных продуктов. В идеале у такой команды должен быть некий «конвейер» — виртуальный инструмент, переносящий результаты работ с этапа на этап, от участника к участнику, от моделей домена проблем к моделям домена решений в рамках этой технологической линии. При таком подходе вся деятельность команды регламентирована и работы четко тарифицированы с точки зрения ресурсоемкости. Этот слаженные механизм регулярно, в соответствии с планами и сметами, выдает программные продукты, как «горячие пирожки». Звучит как фантастика, но очень хочется верить, что такие команды могут существуют в природе.
Обсуждение «конвейера» и технологической линии разработки ПО, само по себе достойно отдельной статьи.
Заманчиво? Тогда идем дальше…
Возвращаясь к теме, поднятой в данной публикации, выделим основной круг заинтересованных лиц, упомянув об их потребностях:
При такой расстановке акцентов, в процессе формирования требований необходимо очень четко ориентироваться на технологии, используемые командой разработчиков. Поскольку в одной статье тяжело охватить максимальный спектр предметных областей и применяемых технологий, я буду рассматривать в качестве примера — кластер учетных систем, использующих реляционные базы данных и технологические платформы, позволяющие применять готовые компоненты. Под компонентами, в данном случае, следует понимать шаблоны решений, агрегирующие функциональные возможности популярных сервисов (например: компонент работы со списками, компонент представления формы для редактирования данных, поисковая подсистема, подсистема разграничения прав доступа и т.д.). Для того чтобы изложение материала сделать более наглядным, я включил в него фрагменты спецификаций требований учебного проекта: «Автоматизация процесса Управления требованиями».
За некачественные требования всегда расплачивается заказчик. Иногда сразу, иногда в рассрочку
Возможно, после следующих утверждений у меня появится много критиков, но возьму на себя смелость рассмотреть спецификации требований, как интерфейс между аналитиками и разработчиками. Да есть “натяжка” в этом утверждении, и поэтому обратимся для уточнения термина к энциклопедии. «Интерфейс — совокупность возможностей, способов и методов одновременного действия (в том числе посредством обмена информацией между ними) двух имеющих общее разграничение, то есть не связанных линейно, информационных систем, устройств или программ, определяемая их характеристиками, а также характеристиками соединения, сигналов обмена и т. п.». Уже чувствуете схожесть?
Примем допущение и будем считать аналитиков и разработчиков — информационными системами. Это позволит нам идентифицировать спецификации требований как – «совокупность унифицированных технических и программных средств и правил (описаний, соглашений, протоколов), обеспечивающих одновременное взаимодействие двух систем или обеспечение соответствия систем». А это означает, что, предлагаемая в данной статье структура представления спецификаций требований и будет выступать в качестве протокола обмена, обеспечивающего взаимодействие группы аналитиков и разработчиков. Это позволит нам изолировать слой анализа и проектного дизайна, от слоя реализации конечных спецификаций в целевом продукте. Чтобы, читая текст, Вы представляли себе примерно ту же картинку, что и я зафиксирую это на Рис.1.
Рисунок 1. – Укрупненная схема взаимодействия команды ИТ проекта
Для того чтобы отбросить все лишние артефакты, разработанные аналитиком (они на картинке обозначены как «Требования») и востребованные на этапе проектирования, но бесполезные, а иногда и вредные для представления их разработчикам, определимся с объектами, которые должны быть использованы в нашем интерфейсе (спецификациях). Для этого необходимо ответить на вопрос: чем же оперируют разработчики, создавая конечный продукт? Поскольку в качестве примера был выбрани вариант разработки ПО на базе платформы, то целевую систему можно представить в виде набора компонентов, постоянное слаженное взаимодействие которых и приводит к “эффекту работающей программы”, как показано на Рисунке 2.
Рисунок 2. Компонентная модель Целевой системы.
Таким образом в спецификациях для выбранного варианта обязательно должны быть подробно описаны экземпляры элементов, указанных на Рис. 2 и способы их реализации. То есть системный аналитик должен перевести плоды своей работы (или работы бизнес аналитика), на рельсы используемых разработчиками технологий, описав конкретные элементы, алгоритмы их поведения и т.д., в терминах и понятиях выбранной платформы. Степень глубины трансляции может варьировать, в зависимости от компетенции системного аналитика и потребности команды разработчиков.
Теперь, когда мы определились с составом элементов спецификаций, давайте выясним возможный порядок их представления в документе. Поскольку разные этапы исполнения зависят друг от друга или от результата их деятельности, установим последовательность, в которой их удобнее и рациональнее всего выполнять. На Рисунке 3 изображена модель возможного процесса – создания ПО на основании требований с использованием технологической платформы, описанной выше.
Рисунок 3. Модель варианта основного процесса создания ПО.
На рисунке представлен процесс, включающий в себя функции, выполняемые последовательно (отображены в виде фигур похожих на большую стрелку). В верхней части изображен ресурс выполняющий эти функции (разработчик), в нижней части элементы целевой системы, задействованные в процессе. Стрелками обозначены потоки информации, которые обеспечивают передачу данных от функции к функции. Все просто и наглядно.
Таким образом в наш вариант структуры документа обязательно должны войти следующие разделы:
Еще, при необходимости, можно включить разделы с описанием Workflow, условий контекстного поиска и т.п., из того что поддерживает используемая платформа.
Все остальные объекты дизайна, разработанные аналитиком, по возможности должны быть исключены из требований, передаваемых команде разработчиков, для того, чтобы не распылять их внимание и не увеличивать объем документа.
В следующей части я приведу примеры того, как могут выглядеть, подготовленные таким образом спецификации требований. А так же покажу на примерах, варианты их эффективного использования PM и QA специалистами.
Автор: ARadzishevskiy
Источник [1]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/upravlenie-proektami/262365
Ссылки в тексте:
[1] Источник: https://habrahabr.ru/post/335830/
Нажмите здесь для печати.