Ведение и согласование изменений (часть 2)
Как мы уже писали в первой части данной статьи: В работе над любым проектом неизбежно возникает необходимость вносить изменения в бизнес и системные постановки.
Сегодня мы обсудим возможные пути фиксации изменений в постановках (на уровне бизнес и системного анализа), которые позволят не упустить ничего из достигнутых договоренностей.
Но сначала вспомним основные свойства хорошей спецификации требований:
- Полнота. Совокупность элементов спецификации должна исчерпывающе описывать поведение системы. Не должно быть скрытых функций, не описанных в спецификации – это баги! Все, что есть в спецификации, должно быть реализовано в системе: спецификация – тот же код, только написанный другим языком.
- Завершенность. Требование полностью определено в одном месте, и вся необходимая информация присутствует (крайне важно избегать повторного описания требования в разных местах). Например, описание проверки ФЛК может быть описано и в сценарии, и в описании интерфейса. Такое дублирование с высокой долей вероятности приедет к нарушению целостности спецификации и появлению противоречий. Поэтому описывайте каждое требование только один раз и используйте ссылки.
- Атомарность. Спецификация не может быть разбита на более мелкие требования без потери завершенности. Каждый элемент не может быть декомпозирован на более мелкие требования. При этом необходимо придерживаться здравого смысла, не вынося в отдельное описание каждое поле.
- Непротиворечивость. Требование не противоречит другим требованиям. Понятие непротиворечивости тесно связано с понятием завершённости. Одно требование – одно описание!
- Идентифицируемость. Элемент спецификации должен быть однозначно идентифицируемым. Наименования элементов и страниц описания должны быть уникальным и единым в рамках спецификаций всех систем. Для этого можно использовать префикс системы, код в иерархии описания, название функции. При разработке большого количества систем крайне важно поддерживать единый реестр терминов и определений, в том числе использовать для одинакового функционала одинаковые названия функций. Даже если ранее какая-то из функций (например, загрузка файла) не была выделена в микросервис, одинаковое наименование функции в целом ряде систем приведет к необходимости вынесения одинакового функционала в виде отдельного сервиса.
- Трассируемость. Связь между требованиями, или возможность проследить одно требование относительно других. При описании сценария можно и нужно сослаться на другие элементы спецификации (например, на пользователя, который может выполнить этот сценарий, общие требования к личному кабинету, в котором доступна та или иная функция). Для удобства работы используйте ссылки.
Если все описанные выше требования реализованы, то изменения, которые должны быть внесены в постановки должны быть внесены в одном месте и вы (аналитик) точно знаете где их вносить.
Для того чтобы внесенные вами изменения были легко идентифицированы разработчиками и тестировщиками соблюдайте несколько простых правил:
1. Ведите лист изменений
На каждой странице Confluence рекомендуем вести таблице "Лист изменений" с указанием причины внесения изменений (ссылка на договор на доработку системы, задачу jira или иной первоисточник). При такой записи вам будет намного проще восстановить ключевые моменты изменения системы вместо того, чтобы разбираться в истории сохранения страниц без понимания, почему были внесены те или иные изменения.
В столбце Версия рекомендуем вставлять ссылку на версию страницы из Истории изменения страницы. Так вам будет проще переходить к нужной версии страницы и проводить сравнение изменений в случае необходимости.
В данной таблице необходимо регистрировать только завершенные версии постановки. Аналитик может вести доработки страницы в течение нескольких дней или возвращаясь к ее доработкам несколько раз в течение одного дня - при этом в Истории изменений сохранится несколько различных версий, но только одна из них будет финальной и готовой к передаче в разработку - именно ее и нужно указать в Листе изменений.
2. Выделяйте изменения при доработках элементов спецификации любым удобным вашей команде способом
Например, на рисунке ниже видны два этапа внесения изменений в требования ФЛК, каждое из которых было вызвано внесением изменений в нормативные документы, регламентирующие функционирование системы.
В данном примере серый зачеркнутый текст означает, что требование было реализовано ранее и выпущено в прод, но больше не актуально.
Красным цветом добавлены изменения первой итерации.
Синим цветом добавлены изменения второй итерации.
Так же вы можете обратить внимание на синий зачеркнутый текст - в данном случае изменение произошло в момент, когда разработчик уже работал по данному изменению, но требование изменилось и его необходимо было успеть реализовать до следующего релиза.
Вы можете использовать любой другой удобный вашей команде формат не обязательно цветовую идентификацию.
3. В комментариях к этой же странице обязательно указывайте причину внесения изменений.
Например:
В задаче Jira, которую вы (аналитик) будете создавать после завершения работы над постановкой лучше приложить ссылку на этот комментарий, чтобы разработчик сразу видел список изменений, которые ему необходимо внести в код.
4. Не забывайте возвращать текст постановки к "нормальному" виду
После того как изменения реализованы, протестированы и выведены в прод необходимо снять цветовое выделение на странице Confluence. При большом количестве итераций ваша страница превратится в нечитаемую радугу 🌈 Не бойтесь потерять историю изменений, она сохранится в виде комментариев и так же будет доступна для разбора благодаря Листу регистрации. Найти отличия между двумя известными вам версиями страницы можно с помощью функции Сравнения страниц в Confluence.