10 способов повысить качество в Agile разработке Drupal
Адаптированный перевод этой статьи.
Многих новичков в гибкой методологии разработки программного обеспечения впечатляет, если не пугает, частота изменений все новых и новых требований к продукту и кодовой базе.
Специалисты в области цифровых технологий понимают, что agile-методы могут улучшить адаптируемость и время создания продукта. Но как можно поддерживать высокое качество, когда так много изменений происходит за такой короткий промежуток времени?
В этом блог-посту я опишу 10 способов, используемых профессионалами компании Acquia для преодоления этой трудности.
1. Сперва проясните цели и показатели бизнеса.
Да, agile-методы определенно требуют планирования. Прежде чем начнется проектирование и разработка, клиент и команда должны определить факторы развития бизнеса и цели проекта. Команда также должна прийти к единому мнению по поводу показателей, которые будут использоваться для оценки этих бизнес-целей. Все последующие действия по контролю качества должны напрямую коррелировать с этими целями и показателями. Без этой основы «качество» — просто бессмысленное слово.
2. Составьте проект контентной модели Drupal и архитектуры приложения прежде, чем начнется разработка.
Использование agile-методов не означает, что команде придется создавать код в первый же день. Гораздо легче проследить связь индивидуальных запросов на включение кода с целями и показателями бизнеса, когда команда может обратиться к промежуточному шагу. Мы обнаружили, что контентная модель Drupal и архитектура приложения обеспечивает наибольший процент качества на этой промежуточной ступени. По мере осуществления разработки эти решения можно исправить. Однако, когда имеешь представление о конечном результате, можно избежать путаницы и доработок.
3. Начинайте спринт с груминга пользовательских историй.
Вовремя спринта команде следует проводить собрания по планированию спринта для проверки того, что для каждой пользовательской истории, запланированной для спринта, соблюдается следующее:
- Владелец продукта согласен с техническими условиями.
- Команда разработчиков составила проект и оценила метод внедрения.
Технические условия устанавливают стандарт качества для пользовательской истории и будут служить в качестве критерия оценки тестирования пользовательской истории. Команда может составить проект, не дорабатывая детали технических условий, и оценить метод внедрения, устраняющий неисправности.
4. Примените стандарты кодирования в локальной среде разработки.
Команды используют инструмент BLT, который находится в открытом доступе, для применения стандартов кодирования в локальной среде разработчиков. Эта практика позволяет находить малейшие ошибки. Это также обеспечивает согласованность кода, что ведет к более быстрому анализу кода, более эффективной отладке и (если уместно) более легкому повторному использованию в Drupal-сообществе.
5. Проанализируйте код и шаги по автоматизированному и ручному тестированию перед интеграцией.
Каждая проектная команда включает в себя Drupal-эксперта, ответственного за архитектуру технического решения. Они делают это с помощью ручного разбора кода, автоматизированного и ручного тестирования кода для каждой пользовательской истории. Этот анализ происходит на изолированной ветке разработке кода прежде, чем что-либо будет интегрировано с главной кодовой базой. К тому же, чтобы убедиться, что работа соответствует установленным стандартам, эксперт учитывает цель кода, объемы, метод внедрения, дизайн, безопасность, производительность, метод тестового покрытия, управление конфигурациями и документацию.
6. Автоматизируйте интеграцию кода, тестирование и развертывание.
Почти каждый практикующий agile-специалист скажет, что автоматизация – это ключ к успеху, и я с этим согласен. При использовании гибких методов автоматизация – ключ к успешному контролю качества. Несмотря на то, что эти навыки и умения необходимы для современных веб-разработок, многие ИТ-отделы все еще серьезно отстают от передовой части общества.
7. Предоставьте демо-версию владельцу продукта.
Центральное место в гибком Scrum-методе занимает ритуал по анализу спринта (Sprint Review), которое включает в себя демонстрацию образца владельцу продукта. Эта демоверсия должна проводиться в той же среде внешнего размещения, где будет происходить тестирование продукта. Это гарантирует, что все вопросы, связанные с внешними условиями, будут решены до показа демо-версии и не изменятся до того, как владелец продукта начнет самостоятельное тестирование.
8. Необходимо, чтобы владельцы продукта протестировали пользовательские истории
Многие владельцы продукта будут чувствовать себя некомфортно, одобряя пользовательскую историю, базирующуюся только на короткой демонстрации, предоставленной на собрании по анализу спринта (SprintReview). Предоставление владельцам продукта нескольких дней после спринта, для возможности проанализировать и доработать предоставленный продукт, дает владельцу продукта достаточно времени, чтобы изучить и дать обратную связь на то, что было предоставлено. В то время как команда начинает параллельно разработку следующего спринта пользовательских историй.
9. Проведите независимый аудит безопасности и эффективности.
При приближении к выпуску продукта команды приглашают независимых экспертов по безопасности и эффективности, чтобы оценить соответствие приложения производственным требованиям. У Drupal есть много встроенных функций по безопасности, но, когда в проекте представляют пользовательский код, конфигурацию и контент, возникает необходимость в полной проверке приложения, чтобы гарантировать соответствие стандартам качества.
10. Следуйте установленному контрольному списку для предстартовой и стартовой подготовки к выпуску продукта.
Чтобы не пропустить какой-либо важный шаг во время напряженной фазы запуска продукта, команды делают черновой вариант заранее, а затем четко следует контрольному списку предстартовых и стартовых задач. Не важно, сколько сайтов наши команды запустили, все мы люди и можем ошибаться. Совместное создание и следование контрольному списку во время этой критической фазы уберегает от человеческой ошибки. Таким образом, день выпуска продукта всегда проходит успешно.