Менеджмент цифрового продукта. От идеи до идеала

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

Определение завершенности может формироваться на уровне Scrum-команды в процессе ретроспективы спринта, а также на уровне трайба или всей организации – в этом случае Scrum-команда также обязана ему следовать.

Пример определения завершенности

Часто бывает, что на старте члены Scrum-команды по-разному понимают значение Done (Выполнено). Владелец продукта ожидает, что функциональностью можно пользоваться реальным пользователям. Для разработчиков Done может значить, что код написан и ждет тестирования. DoD позволяет выравнивать ожидания.

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

Как уже стало заметно, DoD – мощнейший инструмент для управления требованиями к:

➠ производительности;

➠ архитектуре;

➠ безопасности;

➠ развертыванию;

➠ качеству кода;

➠ сбору аналитических данных;

➠ сравнительным экспериментам;

➠ дизайну;

➠ документации;

➠ инфраструктуре;

➠ ролям;

➠ процессам;

➠ требованиям;

➠ обслуживанию;

➠ автоматизации тестирования;

➠ процессам тестирования.

Табл. 3.10. Пример определения завершенности (DoD)

Важно как можно раньше начинать развивать DoD для подготовки к фазе масштабирования.

Определение завершенности – важный инструмент управления качеством программного обеспечения. О том, как выглядит процесс управления качеством ПО в гибких подходах, поговорим в следующей главе.

3.3. Управление качеством программного обеспечения

Качество программного обеспечения – это соответствие функциональным и не функциональным требованиям.

Функциональные требования (functional requirements, FR) описывают, что будет делать система, то есть это возможности системы (функции) без описания того, как они реализованы. В сложившихся практиках FR описываются элементами продуктового бэклога.

Нефункциональные требования (non-functional requirements, NFR) описывают, как будет работать система. Как правило, это перечень атрибутов и критериев их соответствия, в большинстве случаев говорят про атрибуты качества.

В сложившихся практиках NFR указываются в DoD и в исключительных случаях в критериях приемки.

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

3.3.1. Запланированное улучшение качества системы

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

Владелец продукта предоставляет данные финансовой модели, по которым определяются атрибуты и критерии на горизонте 3–6 месяцев. Например:

➠ Количество активных пользователей в день – от 10 тыс. до 100 тыс. человек.

➠ Объем хранимых данных на пользователя – от 3 до 6 мб.

➠ Раздача видео потока на одного пользователя – до 100 мб/мес.

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

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

➠ «Как владелец продукта могу видеть данные о тестировании нагрузки, чтобы удостовериться, что система выдерживает единовременно 10 тыс. обращений».

➠ «Как разработчик могу настроить динамическое масштабирование приложения, чтобы выдерживать изменения нагрузки до 10 тыс. обращений».

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

3.3.2. Незапланированное улучшение качества системы

Обычно незапланированное улучшение качества системы происходит, когда случился резкий рост продукта, но бывают и менее приятные ситуации, такие как хакерские атаки. В этом случае определяются атрибуты и критерии, например, устойчивость к DDoS-атакам до 300 Гб/с.

Если цель текущего спринта не может быть достигнута, то производится остановка спринта, например, в связи с атакой на сервер не может быть выполнен критерий «Из 100 единовременных обращений 80 % запросов не превышают одной секунды».

При необходимости добавляются сессии прояснения бэклога.