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