Разработка и управление требованиями

Текстовая расшифровка девятого урока курса Введение в профессию аналитика.

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

Давно существует такое разделение. Я не назову сейчас первоисточник. Но есть, например, такая модель зрелости управления CMMI, которая описывает группы процессов, которые должны быть реализованы в компании. В данном случае речь идет о компаниях — разработчиках программного обеспечения. Модель CMMI делит эти компании на несколько уровней зрелости. Т. е. начальный уровень находится внизу — первый, практически хаотичный. Чем больше процессов у вас реализовано и отработано, тем выше уровень, на котором вы находитесь. Активно довольно применяется эта модель. Есть специальные люди, которые проводят сертификацию компаний в соответствии с этой моделью, хотя в России их не очень много. Если компания сертифицировалась по CMMI до какого-то уровня, например четвертого, то она обычно этим гордится, потому что это может быть существенно при работе с западными заказчиками, которые на эту сертификацию смотрят.

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

Что, собственно, стоит за этими группами процессов? Какие процессы в них входят?

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

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

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

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

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

Эта была группа процессов разработки требований. Вторая группа — это управление требованиями. Что сюда входит?

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

Контроль версий требований. Если вы продукт выпускаете версиями, то для разных версий продукта вы используете разный набор требований — и разные версии самих требований, и каких-то документов с совокупностью требований.

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

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

Трассировка. Чем занимаются аналитики? Они связывают требования между собой. Из бизнес-требований следуют пользовательские, из пользовательских требований следуют какие-то требования к реализации. Требования могут связываться между собой, и эти связи, собственно, и являются трассировками.

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

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

Управление изменениями в узком смысле — это изменение самих требований. Если же мы рассматриваем изменение требований в широком смысле, это то, как изменения продукта отражаются на требованиях.

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

В широком смысле мы уже привязываем версии требований непосредственно к коду, например, в системе управления версиями. Мы создаём так называемые baselines. То есть мы выпустили очередной релиз продукта, и при этом мы должны понимать, какие требования реализованы именно в этом релизе, а какие не реализованы. Для этого и делаются эти срезы — baselines. Наверное, этот термин вы уже встречали.

Статусы. Я уже сказал, что в узком смысле мы отслеживаем статусы разработки самих требований и документов, а в широком смысле мы отслеживаем статусы планирования, выпуска версий продукта или релизов, статус реализации — реализовано требование или нет, и где реализовано. А ещё бывают ситуации, когда у нас существует несколько параллельно живущих версий продукта — в частности, продуктов, внедряемых у разных заказчиков, — и бывает, что одни и те же требования реализованы по-разному. В разных странах, например, вы внедряете банковскую систему, и в России требования одни, а в Казахстане — другие. И, соответственно, какая-то функция называется одинаково и делает примерно одно и то же, но реализована по-разному, и требования к ней разные.

Статусы тестирования этих требований, статусы их поставки, статусы их приёмки и т. д. — это всё отражает, собственно, состояние самого продукта, но это статусы, относящиеся к конкретным требованиям.

И трассировка. Я об этом тоже уже сказал. В узком смысле мы связываем требования друг с другом какими-то ассоциациями. В широком смысле мы трассируем требования на другие артефакты разработки.

Почему это важно? Потому что аналитики часто мыслят только в узком смысле. А реалии современные, в том числе в интернет-продуктах, состоят в том, что аналитики должны понимать управление требованиями в широком смысле.

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

Поэтому важно не запутаться, в каком смысле вы понимаете управление требованиями.

И вот снова эта картинка CMMI. То, о чём я сейчас говорил, объясняет тот парадокс, с которым все начинающие аналитики сталкиваются, когда смотрят на эту модель. Здесь видно, что процесс управления требованиями появляется на втором уровне, а процесс разработки требований появляется на третьем. И, казалось бы, как на втором уровне можно управлять тем, чего у нас еще нет?

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

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

Этот слайд подводит итог и заново повторяет то, что я уже сказал.

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

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

Поскольку сейчас все происходит очень быстро, требования меняются в процессе, и мы можем их менять хоть каждый день, нам нужны более эффективные форматы. И вот эти форматы здесь отражены. В первую очередь, User Stories. Это такой способ представления требований, который изначально адаптирован под управление. То есть мы разрабатываем требования в этом виде, и тут же применяем к ним элементы управления, включаем их в backlog. (Если вы не понимаете этих слов, не беда, мы поговорим о них в курсе. Но большинство, наверное, уже знает, что в agile распространён подход создания списка или бэклога того, что должно быть реализовано в очередной итерации.) Вы можете тут же отслеживать их статусы. Это делалось изначально физически, на доске с помощью карточек, а сейчас все больше для этого используются электронные доски. Фактически, эта доска показывает статус реализации вашего требования: в разработке, тестируется и т. д. Вызов на эти новые возможности интернета проявился в том, что появились такие новые форматы разработки требований.

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

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

Предыдущий урок: Сводные документы требований к программным продуктам

Следующий урок: Основные подходы к разработке программных продуктов