Вертикальное нарезание - некоторые практические идеи
В гибкой разработке определение размера и фрагментация истории важны для создания ценности для бизнеса при достижении таких целей разработки, как непрерывная интеграция, развертывание и тестирование. Если история слишком велика, команда рискует не завершить ее в текущем спринте. Если история слишком мала, ощутимые результаты не могут быть продемонстрированы.
В Capital One мы используем гибкую методологию при разработке наших программных приложений и операционных процессов. В течение последних двух лет я возглавлял команду из шести инженеров, использующих Agile для предоставления нескольких ориентированных на клиентов функций. В этой статье я расскажу о своем видении вертикальной нарезки и рассмотрю некоторые принципы и идеи, которым следовала моя команда.
На примере разработки веб-приложения мы рассмотрим некоторые идеи, поддерживающие вертикальное разрезание при разработке программного обеспечения.
Кто хочет есть только глазурь?
Лучше всего получать многослойный торт, если можно попробовать каждый слой в одном куске. Кто хочет есть только глазурь? Точно так же пользовательские истории содержат несколько уровней, и каждый из них способствует выполнению бизнес-требований. Например, предположим, что у вас есть полностью разработанное веб-приложение, обеспечивающее удобство работы с клиентами и обслуживающее миллионы пользователей. Что делать, если в этом приложении нет журналов аудита? Сможете ли вы определить эффективность своего приложения для такой широкой пользовательской базы?
С другой стороны, что, если ваше приложение является пилотным, обслуживает небольшую группу клиентов, но имеет все необходимые уровни (журналы аудита в нашем примере), чтобы обеспечить надежную обратную связь для точной настройки приложения или исправления нюансов перед большим взрыва выкат?
Если это звучит хорошо для вас, как вы правильно нарезаете свои истории, чтобы получить больше, чем просто кусок глазури?
Контекст проекта
Недавно моя команда представила функцию самообслуживания, которая позволила клиентам сбрасывать пароль своего онлайн-профиля. Это простое приложение, которое проверяет данные клиента, задает пользователю пару контрольных вопросов, сбрасывает его пароль и отправляет ему подтверждение по электронной почте. Мы рассмотрим, как принципы вертикальной нарезки применимы к этому контексту разработки.
Встаньте на страницу
Если вы создаете новые страницы для приложения, сделайте их доступными до проверки и бизнес-логики. Это помогает владельцу продукта увидеть, что происходит и как это согласуется с общим видением. В приведенном выше примере мы подняли страницы для сбора данных о клиентах в качестве первого шага без каких-либо подробных проверок. Это помогло нам во многих отношениях, наиболее заметными из них были:
- Согласование с видением владельца продукта. Поскольку владелец продукта мог видеть макет страницы на ранних этапах цикла, команде стало проще внедрять предложения и настройки по управлению продуктом.
- Начните с автоматизации тестирования. После того, как страницы приложения были запущены, наши инженеры по автоматизации тестирования могли писать сценарии для полей и объектов страницы. Это дало им отличный толчок в процессе разработки.
Поскольку страницы на этом этапе, скорее всего, не проходят валидацию, «поднятие страницы» может стать историей №1 для вашего процесса. Вы будете строить на этой странице последующие более мелкие, разбитые на блоки истории.
Проверка на стороне клиента и на стороне сервера
Для форм это нормально, что некоторые проверки выполняются на стороне клиента (например, обязательные поля), а некоторые другие - на стороне сервера. Вот стратегия, которую мы применили для обработки проверок в отдельных историях - разбейте их и используйте одну историю для завершения проверки на стороне клиента и другую историю для завершения проверки на стороне сервера.
В нашем случае для проверки на стороне сервера потребовались некоторые серверные службы, которые были недоступны, когда скелетное приложение впервые «встало». По этой причине выполнение проверок на стороне клиента перед проверками на стороне сервера помогло группе визуализировать размещение сообщений об ошибках на веб-странице. Это дало владельцу продукта раннюю обратную связь, чтобы можно было принимать решения относительно их расположения относительно других компонентов страницы, а также анализировать их эффективность с точки зрения конечного пользователя.
Для своих проектов вы можете выбрать проверку некоторых полей на стороне клиента и некоторых на стороне сервера. Вы также можете обрабатывать эти истории в разных спринтах или в одном спринте, учитывая сложность вашего приложения. Независимо от последовательности, когда эти истории будут завершены, ваше приложение будет готово с точки зрения валидации.
Кнопка "Назад" / обновление страницы и другие нетипичные действия пользователя
Это не обычная пользовательская навигация, а скорее негативная тестовая ситуация. Если форма снова отправляется через обновление страницы, как серверная часть обрабатывает ее? Если пользователь нажимает кнопку «Назад», будет ли правильно отображаться содержимое предыдущей страницы? Будет ли пользователь по-прежнему находиться в безопасном сеансе? Должно ли приложение вывести пользователя из системы?
Как видите, это некоторые нетипичные пользовательские способы навигации, которые потенциально могут нарушить поведение приложения. Отдельная история для обработки этих уникальных случаев помогает укрепить приложение. В приведенном выше примере на страницах в глубине навигации наше приложение выводило пользователя из системы, если была нажата кнопка «Назад»; в то время как на ранних этапах навигации пользователь мог вернуться и внести правки без необходимости повторного входа в систему. При включенной фокусировке мы выявили несколько поведенческих аномалий, которые в противном случае не были бы обнаружены, если бы мы разрезали нашу историю по-другому.
Для вашего приложения определение поведения приложения для таких вариантов использования и их индивидуальное тестирование может значительно повысить отказоустойчивость приложения.
Кроссбраузерность и совместимость устройств
Теперь у вас есть функциональное приложение, которое хорошо работает в основных популярных браузерах, но не работает в некоторых старых версиях или устройствах с уникальными форм-факторами. В Capital One мы стремимся охватить как можно более широкую клиентскую базу и создавать приложения, которые работают на всем спектре устройств и браузеров (в разумных пределах, конечно, IE8?)
Однако на начальных этапах разработки это не должно отягощать вас. С небольшими изменениями мы смогли устранить причуды некоторых устройств и браузеров (да, IE8 был одним из них) и охватили целевую глобальную аудиторию.
Важным фактором является способность сосредоточиться на отдельном сюжете и устранить «причуды» позже в процессе разработки. Для своего проекта вы можете даже отказаться от обслуживания некоторых комбинаций браузеров / устройств при первоначальном запуске. Решение остается за вами, но главное - создать рассказ, отражающий работу отдельно.
Стандарты доступности
В нашем примере мы создавали функции поверх унаследованного приложения, поэтому тестирование доступности было важной вехой для реализации проекта. Это помогло нам заранее ознакомиться с доступностью, чтобы оценить последствия и предстоящую работу. Стратегия, которой мы следовали, заключалась в том, чтобы запускать функциональные тесты и тесты доступности параллельно на ранних этапах проектного цикла, чтобы дать нам время отреагировать на любые обнаруженные недостатки.
Требования к ведению журнала
Как правило, для большинства приложений требуется ведение журнала. И не только журналы разработчика, но и журналы аудита, которые помогают генерировать операционные метрики. В нашем проекте мы настроили приложение для записи журналов аудита в операционную таблицу, где аналитическая группа будет собирать записи с помощью ночного пакетного сценария. Хотя группа аналитиков занялась проектом на более поздних этапах цикла, мы были готовы развернуть базовую версию приложения в среде контроля качества намного раньше, чем группа аналитиков смогла разработать соответствующие пакетные сценарии.
Мы столкнулись с двумя вариантами: либо отложить первоначальное развертывание до тех пор, пока не будут готовы сценарии пакетной обработки, либо продолжить с отключенным ведением журнала аудита. Поскольку раннее развертывание приложения имеет большую ценность для начала тестирования, мы выбрали второй вариант. В результате наши инженеры по тестированию смогли протестировать приложение, в то время как группа разработчиков работала с командой аналитиков, чтобы включить эту функцию.
Итак, каков ключевой вывод? Не ждите, пока эта функция задержит ваш первоначальный график развертывания. В этой истории рассказывается о произведении.
Промежуточное ПО / Службы интеграции
В некоторых случаях вашему приложению могут потребоваться данные из нескольких серверных частей. Если это так, то подход, который лучше всего сработал для нас, заключался в «фазировании» внутренних вызовов. В нашем примере проекта нам пришлось сделать несколько вызовов базы данных и пару вызовов внешних API. Одна из эффективных стратегий заключалась в написании кода для сценариев «счастливого пути». Моя команда сначала написала код для обработки успешных ответов от API, а затем добавила дополнительный код для обработки условий ошибки.
С точки зрения веб-приложения, это может стать действительно интересным, если API, который вы используете, разрабатывается одновременно (либо вашей командой, либо другой командой) с вашим собственным приложением. Здесь нужно настаивать на том, чтобы базовая версия сервиса была доступна на раннем этапе, чтобы вы могли интегрироваться с ней раньше, чем позже.
Заключение
На следующем рисунке показан рабочий процесс от начала цикла до момента, когда он готов к производству. В каждом поле перечислены критерии, которые должны быть выполнены до того, как команда сможет объявить «Готово». Он также представляет собой код, который «готов» перейти к следующему этапу.
В этой статье я рассмотрел некоторые идеи о том, как разделить истории, чтобы не только дать дополнительную ценность для бизнеса, но и достичь таких целей разработки, как непрерывная интеграция, развертывание и тестирование. Мы говорили о правильных размерах историй, чтобы команда могла закончить их на спринте, демонстрируя при этом ощутимые результаты. Хотя это далеко не всестороннее глубокое погружение в тему, надеюсь, это поможет вам реализовать вертикальное нарезание в потоке вашего собственного проекта.
Чтобы узнать больше об API, открытом исходном коде, мероприятиях сообщества и культуре разработчиков в Capital One, посетите DevExchange, наш универсальный портал для разработчиков. Https://developer.capitalone.com/