Каждое ТЗ (фича) всегда описывает не только то, что необходимо сделать в рамках данного ТЗ, но и то, что было сделано ранее.
Основной плюс такого подхода: вы всегда имеет полное описание функциональности на текущий момент (релиз). Из чего следует, что:
- вам не нужно помнить все тонкости реализации данной фичи;
- вам проще описать все нужные изменения;
- у вас есть, по сути, готовая заготовка для документации.
Предлагаемое выделение изменений в ТЗ (для Confluence):
Описание используемых цветов в постановке по изменению функциональности при сравнению с предыдущей версией:
Предыдущая версия: <ссылка или пишем, что это первая версия>
|
Пункты описания "что изменилось" описываются "крупными мазками" и их можно, для наглядности, выделять теми же цветами.
Указанные цвета являются стандартными цветам Confluence и выбраны как наиболее заметные. В вашем средстве написания ТЗ вы можете выбрать другие цвета.
Заметьте, что нет цвета для изменения функциональности. Причины:
- любое изменение - это удаление существующей функциональности и добавление новой;
- для уменьшения пестроты постановок.
Перед тем как начать описывать постановку на изменение функциональности:
- вы берёте предыдущую версию ТЗ;
- копируете её в новый документ;
- удаляете текст про "удалённую функциональность";
- текст про "добавленную функциональность" делаете чёрным;
- вставляете ссылку на ту версию документа, с которой сделали копию.
Заметьте, что "пояснение к функциональности" оставляем как есть и переносим из версии в версию. Потому что пояснение не является требованием и пишется к требованию.
Минус данного подхода к описанию фич в том, что если вы одновременно пишите несколько доработок одной и той же фичи, то в какой-то момент вам нужно будет выполнить объединение этих описаний.
Комментариев нет:
Отправить комментарий