✓ качество исполнения: удобство использования, надежность, производительность,
✓ качество развития: ремонтопригодность, портативность,
✓ ограничения проектирования, развертывания, соответствие стандартам.
В зависимости от этого меняется и влияние на элементы Scrum.
Если нефункциональное требование оказывает сильное влияние на продукт, его можно использовать для контекстуализации Scrum (см. главу 14).
Примеры: ограничения – такие, как соответствие стандартам в данной области (например, DO178B для аэронавтики), или выбор программного пакета, или тип лицензии.
Бэклог содержит все, что требует работа команды: как функциональные, так и нефункциональные требования.
Размещение всех задач в бэклоге позволяет иметь единый и упорядоченный источник всего, что необходимо сделать. Трудность нефункциональных требований состоит в том, чтобы их можно было:
✓ реализовать за один спринт, следуя определению завершенности,
✓ протестировать.
Порой это требует разделения требования на небольшие части, что не всегда легко, но иногда получается: техника вынуждает сконцентрироваться скорее на тестировании, чем на описании.
Пример
Вместо программное обеспечение должно быть эргономичным (что прописано в спецификациях) теперь мы говорим как участник команды, я могу получить доступ к своим задачам максимум в два клика. Для общего требования – такого как эргономика – обычно возникает несколько нефункциональных историй.
Чтобы подчеркнуть требования к производительности, мы постараемся включить элемент проверки: когда я вхожу в систему как пользователь, время отклика составляет менее двух секунд в 99 % случаев, даже если подключено уже 50 пользователей, указав при этом конфигурацию сервера, на котором будут выполняться тесты.
Владелец продукта должен быть вовлечен в процесс определения нефункциональных историй: он отвечает за наполнение бэклога и приоритизацию элементов.
Некоторые ограничения могут быть соотнесены с историей, в которой они фигурируют в качестве условий принятия.
Пример: Для истории о поиске слова в тексте тест может включать проверку желаемого времени отклика с использованием большого объема контента.
Требования к качеству разработки выражаются в определении завершенности, равно как и требования к локализации или удобству использования, которые представляют ограничения для нескольких пользовательских историй.
Пример. Peetic – это продукт, используемый во всем мире, он должен быть представлен как на французском, так и на английском языках. Это требование локализации. Будет оно включено в бэклог продукта? Нет! Как пользователь, я хочу, чтобы продукт на моем языке был историей, но она может быть реализована только в конце, когда продукт уже полностью готов на французском. Или же версия на английском будет создаваться по мере возможности. Всякий раз, когда добавляется текст для новой пользовательской истории, он должен быть доступен на французском и английском языках.
На каждую пользовательскую историю, содержащую текст, налагается ограничение локализации. Все участники команды – и разработчики, и тестировщики – должны знать о требовании текст на французском и на английском. Способ напоминания о нем всей команде включен в критерии завершенности.
Эти нефункциональные требования обязывают к проведению специального тестирования, возможно, в определенных средах. Возможно, придется хорошенько поработать.
Привлечение нефункциональных требований к вниманию всей команды помогает избежать неожиданностей перед вводом в эксплуатацию.
Критерии завершенности влияют на первоначальный бэклог. Вот почему его разработка должна проходить во время прелюдии.
15.6 Антипаттерны
Ситуация. Команда перешла к Scrum, но во время прелюдии просто переименовывает огромную, детализированную спецификацию в бэклог и чрезмерно подробно рассматривает каждую историю.
Последствия. Преждевременная детализация того, что может быть вовсе не включено в дальнейшую работу. Команда забыла о концепции business value.
Как сделать лучше? Сперва сосредоточиться на наиболее приоритетных функциональностях.
Ситуация. Команда создала первоначальный бэклог, но заинтересованные стороны сохранили обычную практику управления требованиями для мониторинга проекта. Элементы бэклога никак не прослеживаются.
Последствия. Нет согласованности между командой и бизнес-целями.
Как сделать лучше? Попробовать техники impact mapping и story mapping.
Чтобы идти дальше
Книги
‣ Гойко Аджич, «Impact Mapping. Как повысить эффективность программных продуктов и проектов по их разработке», Альпина Паблишер, 2017
‣ Джефф Паттон, «Пользовательские истории. Искусство гибкой разработки ПО», Питер, 2017
16Планирование на среднесрочную перспективу
Можно обойтись и вовсе без планирования, когда разговор заходит о том, что будет после спринта. Если важна неопределенность, оно даже и не нужно. Поэтому мы не будем говорить о долгосрочном планировании.
Однако в большинстве случаев, с которыми я имел дело, команды нуждались в плане предстоящей работы. Планирование помогало им принять те или иные решения.
В Peetic постоянно встают вопросы о будущем.
– Сможем ли мы использовать управление подписками для выставки собак в марте?
– Через сколько времени мы сможем анонсировать запуск приложения на планшет?
– Какой бюджет необходим для разработки версии 2 приложения?
– Когда нам понадобится компонент онлайн-платежей, который разрабатывается извне?
В этой главе мы увидим, что среднесрочное планирование может помочь при ответе на все эти вопросы.
16.1 Зачем планировать то, что будет после спринта?
Для полного взаимопонимания давайте сперва разберемся в значении некоторых понятий.
В этом пятом издании я подчеркиваю необходимость разграничения разноплановых действий. Цель в том, чтобы отделять следующие события друг от друга:
✓ планирование на среднесрочную перспективу (сезон),
✓ поставка конечным пользователям (ввод в эксплуатацию),
✓ техническая реализация (развертывание).
Вот мои обновленные определения:
Сезон – это период времени, состоящий из последовательности спринтов.
В предыдущих изданиях я называл этот период релизом. Соответственно, план релиза стал планом сезона.
Выбор продолжительности сезона является частью функциональных решений команды (например, продолжительность спринта). В настоящее время принято, чтобы эта продолжительность была фиксированной (одинаковой для всех сезонов), что задает процессу стабильный, устойчивый темп.
Рисунок 16.1 – Все сезоны имеют одинаковую продолжительность.
Возьмем спортивную метафору: сезон похож на тест Купера, который некогда практиковался в армии. Он предполагает преодоление максимально возможной дистанции за двенадцать минут. И наоборот, классическое планирование, основанное на фиксированной дате окончания работ, похоже на гонку на определенном расстоянии, например, 10 км.
Развертывание – это процесс установки версии в среде для изучения чего-либо (ценность обучения).
Решение о развертывании принимается командой. Так как участники стремятся получить необходимые знания как можно скорее, они обычно всеми силами приближают возможность развертывания.
Ввод в эксплуатацию – это предоставление пользователям версии продукта (бизнес-ценность).
Ввод в эксплуатацию относится к продукту, поэтому окончательное решение остается за Владельцем продукта (для принятия он консультируется с командой и заинтересованными сторонами). Чем больше Agility, тем чаще команда предоставляет новые версии пользователям.
Ввод в эксплуатацию содержит развертывание в среде производства и активацию доступа для пользователей [46].
Пример разграничения трех понятий внутри команды Peetic.
– Сезон длится 3 месяца и состоит из 6 спринтов по 2 недели каждый. В конце сезона команда проводит ретроспективу, открытое собрание и подготовку плана следующего сезона. И так четыре раза за год.
– Ввод в эксплуатацию происходит раз в месяц по завершении работы над функциональностью.
– Развертывание происходит раз в месяц по завершении работы над историей.
Планирование ввода в эксплуатацию позволяет должным образом информировать заинтересованные стороны, которые находятся в ожидании продукта. Они могут внести свой вклад в успешный ввод в эксплуатацию, подготовив документацию, учебные пособия, обучение пользователей и т. д.
Им будет интересно заранее узнать, что запланировано на конец сезона.
Их волнуют не только сроки, но и то, что будет происходить в следующих спринтах – это важно для синхронизации работы по подготовке к вводу в эксплуатацию.
Планирование на среднесрочную перспективу – это возможность синхронизации с заинтересованными сторонами.