Определение Готово

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

Его цель — сделать полноту объективной и последовательной. Без него «готово» означает то, что отдельный разработчик понимал под этим, что варьируется в зависимости от временных ограничений и от того, кого об этом просят. Для одного человека «готово» включает тесты, документацию, проверки доступности и развертывание; для другого — это компиляция кода на его компьютере. Различия незаметны до тех пор, пока не проявятся последствия, обычно в виде дефектов, обнаруженных на поздних этапах, или работы, которую необходимо пересмотреть, прежде чем ее можно будет выпустить.

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

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

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

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

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

В тех случаях, когда работа действительно не соответствует стандарту, честным решением является четкое указание на исключение, а не переопределение статуса «выполнено». Отгрузка товара без конкретной проверки по указанной причине, с отслеживанием устранения недостатков, — это управляемое решение. Тот же самый товар, помеченный как «выполнено», но не учтенный недостаток, — это технический долг, который никто не согласовал и о котором никто не вспомнит.

Поскольку определение определяет, что означает качество на практике, оно требует согласия лиц, ответственных за последствия, а не только команды, занимающейся реализацией проекта. На практике оно устанавливается внутри организации. разработка продукта с учетом стандартов доступности и удобства использования, заимствованных из UX-аудит критерии и пороговые значения производительности из веб-производительность бюджеты, чтобы стандарт отражал все обязательства в целом, а не только функциональные.