[БЕЗ_ЗВУКА] В предыдущих видео данного модуля мы рассмотрели основные популярные методологии гибкой разработки и основной документ — agile-манифест, его авторов и ключевые пункты его содержания. В данном уроке мы сделаем акцент на ценностях agile-манифеста. Agile-ценности — это фундамент общей философии, лежащей в основе гибкого подхода. Именно из ценностей порождаются гибкие принципы, гибкие роли, гибкие артефакты, гибкие практики. Однако сами по себе перечисленные в гибком манифесте формулировки ценностей достаточно абстракты, и если не попытаться разобраться в них, то истинный смысл так и может остаться непонятным. Давайте попробуем это сделать. Итак, повторюсь, что ценности — это базовые идеи, лежащие в основе гибких подходов, то есть философия, видение. Они не являются принципами и не достаточно конкретно сформулированы, чтобы можно было сходу использовать их на практике. Но если вы хотите понимать, почему в agile тот или инструмент, практика или церемония устроены именно так, как они устроены, то важно помнить и хорошо понимать ценности agile-манифеста. Давайте попробуем уложить ценности в следующие пять категорий: новая, ограниченная роль менеджера; отсутствие далеко идущего детального плана проекта; итеративная разработка; согласованные, сжатые границы итераций; фокусировка на качестве, достигаемое через тестирование. Рассмотрим пункты этого списка подробно. Новая, ограниченная роль менеджера. Традиционно у проекта всегда есть как минимум один ответственный менеджер, который играет несколько ролей. Такой менеджер назначает ежедневные задачи как разработчикам, так и другим членам команды. Иногда может выступать в роли тренера или ментора. Также не стоит забывать, что именно он считается ответственным за правильное формулирование требований клиента, их формулировку и донесение до исполнителей, что уж говорить про проверку и приемку результатов. И зачастую именно этот менеджер считается ответственным за успех всего проекта в целом. В гибких подходах роль менеджера существенно изменена. Например, скрам-мастер, своего рода менеджер в agile-команде, чей функционал мы разберем на последующих уроках, никогда не назначает задачи конкретным исполнителям. Вместо такого менеджера члены самоорганизующейся agile-команды сами выбирают себе задачи к исполнению из заранее сформулированного общего списка — так называемого бэклога проекта. Это может звучать непривычно, особенно для тех, кто никогда не сталкивался с гибкими методологиями на практике. Но именно через такие ограничения реализуются ценности agile-манифеста, как, например, в данном случае, люди и взаимодействие важнее процессов и инструментов. Отсутствие далеко идущего детального плана проекта: традиционный проект обычно проходит несколько этапов перед тем, как перейти в фазу реальной разработки, и эти подготовительные этапы зачастую достаточно длительные по времени и могут занимать от нескольких недель до нескольких месяцев. При этом уровень согласования деталей высок, что означает, что приходится продумывать массу нюансов и зависимостей задолго до того, как могут появиться новые идеи или решения об изменений какого-либо компонента проекта. Ценностью-антогонистом со стороны agile в данном случае выступает формулировка: работающий продукт важнее исчерпывающей документации, что для agile-команд является реальной установкой их деятельности. Они стараются как можно быстрее начать писать работающий код в случае разработки программного обеспечения или выпускать прототипы, чтобы уже в конце первой итерации иметь возможность показать, пускай и ограниченный в функционале, но работающий продукт. Адаптация требований при этом происходит параллельно после анализа полученного результата и широкого обсуждения с участниками команды. Исходя из этого появляются третий и следующий из него четвертый тезисы: итеративная разработка и согласованные сжатые границы итераций, которые соответствуют ценности agile-манифеста «сотрудничество с заказчиком важнее согласования условий контракта». То есть от итерации к итерации мы совместно с заказчиком приходим к реальному пониманию, что принесет максимальную ценность при разработке продуктов. И именно готовность к изменениям и отступлениям от первоначального контракта и спецификаций принесет нам максимальную отдачу. Тезис «согласованные сжатые границы итераций» в данном контексте подразумевает, что после начала итерации никто, даже основной заказчик, не имеет права вносить изменений в уже сформулированные требования, а также гарантирует отсутствие пустой, бесполезной разработки таких компонентов, которые не принесут пользы, при этом нет никаких проблем переосмыслить всё уже к началу следующей итерации и кардинальным образом поменять весь проект. Ценность «готовность к изменениям важнее следования первоначальному плану» важно условно привязать к формулировке «фокусировка на качестве, достигаемое через тестирование», так как именно доставляя качественный во всех смыслах продукт, мы получаем гарантию, что достигаем максимум возможного от нашего проекта. Если же отказаться от готовности к изменениям и жестко придерживаться изначально утвержденного плана, высока вероятность, что мы не реализуем весь потенциал проекта. Для правильной организации таких подходов в agile существуют специальные инструменты и церемонии, которые мы разберем на других уроках. Подведем итог данного урока: agile-ценности служат фундаментальной основой для всех остальных производных, принципов, инструментов, практик и церемоний. Поэтому правильное их понимание крайне важно. Абстрактные формулировки ценностей из agile-манифеста можно перевести в пять упрощенных и понятных тезисов, которые мы рассмотрели на данном уроке.
