[БЕЗ_ЗВУКА] Добро пожаловать на второй модуль нашего курса! В нем мы начнем знакомиться с концептуальными основами гибких методологий разработки и управления проектами. Основное заблуждение по поводу гибких методологий, которое часто можно услышать в профессиональных кругах, это обвинение в том, что в AGILE нет четкого плана реализации проекта. Однако, это далеко не так. Просто акценты и приоритеты расставлены несколько иначе. Вместо заблаговременного тотального планирования и попыток зафиксировать весь объём работ по проекту до начала реальных работ гибкие методологии фокусируются на ожидании изменений и желании добиться максимально возможного качества продукта, a это в свою очередь невозможно без постоянного пересмотра уже достигнутых результатов, анализа уже совершенных ошибок или внешних изменений. Самое главное отличие проекта, реализуемого по гибкой методологии, от традиционного проекта это срок вывода на рынок уже работающего продукта. Пускай это может быть не финальная версия, но это то, что уже реально можно пощупать руками. При этом в последнее время вокруг Agile появилось много разного рода слухов, иногда оправданных, иногда нет. Некоторые заявляют о том, что AGILE это чуть ли не панацея от всех бед проектного управления и переводят работу всей компании на Agile методологии. Некоторые ругают его за якобы не конкретность и всячески сторонятся его. Я же хотел бы донести до вас, что как не существует идеальных решений для любой проблемы, так и методологии гибкой разработки не могут быть бездумно внедрены во все проекты. Необходимо в первую очередь уметь выявлять, подходит ли ваш проект для того, чтобы работать с ним по гибким методологиям, а если да, то уверяю вас, ваш проект действительно получит колоссальное преимущество, если вы будете правильно применять AGILE-методологию. Методологии AGILE созданы как противоположность традиционной линейной методологии водопад, подразумевая итеративную и пошаговую разработку, что минимизирует риски. Суть в том, что работа с применением гибкой методологии состоит из серии коротких циклов, итераций, длительностью от двух до трех, иногда больше недель. Каждая итерация включает в себя этапы планирования, анализа, анализа требований, проектирование, разработку, тестирование и документирование. По завершению каждой итерации команда предъявляет заказчику осязаемые результаты работы. Например, первичную версию продукта или часть функционала, которую можно посмотреть, оценить, протестировать, а потом доработать или скорректировать. В итоге заказчик контролирует разработку и может на нее сразу влиять. После каждого этапа на основе проделанной работы команда подводить итоги и собирает новые требования, на основании чего вносит корректировки в план разработки продукта. В каких проектах имеет смысл применять Agile. Вот самые распространенные случаи. Если нужен быстрый запуск продукта при условии его дальнейшей доработки. Если отсутствуют долгосрочные планы. Гибкая методология подразумевает краткосрочное планирование. Если у заказчика нет видения конечного продукта, четкого, ожидаемого результата, а понимание приходит во время разработки. Если нет строгой привязки к бюджету и срокам, которые в инновационных проектах как правило оценить невозможно. Когда клиент готов регулярно тратить свое время на общение с командой. Однако, не стоит ограничиваться данным списком. Оценивать проект на гибкость надо по целому набору критериев, рассматривать которые мы будем на одном из следующих уроков. Сразу хочу сказать, что эталонной методологией на протяжении курса у нас будет SCRUM, так как это одни из наиболее популярных AGILE-методологий в мире. Также по ней достаточно легко можно пройти сертификацию и в России, что может представлять для вас практический интерес, так как работодатели сейчас действительно ценят наличие такого сертификата. В чем же именно заключается суть структуры методологии SCRUM мы изучим на последующих уроках. Изначально SCRUM зародился и применялся только в IT-сфере, но сегодня его практики можно встретить во многих проектах, где присутствует высокая степень неопределенности, где идеальный план сталкивается с реальностью и рассыпается в прах, где часто меняются приоритеты и возникают непредсказуемые сложности. SCRUM сегодня используют в маркетинговых, образовательных проектах, в рекрутинге, медиа, юристы и бухгалтеры, при ремонте квартир и даже в госструктурах. К примеру, когда ремонт квартир идет не строго по дизайн-проекту или вовсе кардинально меняется из-за отсутствия возможности сломать стенку. SCRUM вполне может подойти. А вот для изготовления мебели строго по образцу — нет. Только если в процессе не возникают непредсказуемые сложности: от задержки и поставки не того материала до потери схемы заказа. Есть мнение, что SCRUM больше подходит для долгих, непрерывно развивающихся проектов. Также считается, что он особенно эфективен на начальных стадиях, когда нет четкого понимания, что делать в первую очередь и как именно. А по мере развития проекта могут использоваться лишь отдельные практики. AGILE это допускает и предполагает. Разработка высокотехнологичных продуктов по гибкой методологии больше похожа на написание книги рецептов, нежели на приготовление блюда по какому-то конкретному рецепту. Согласитесь, весь не существует какого-то идеального рецепта, как пошагово сделать так, чтобы ваш новый высокотехнологичный продукт обязательно стал успешным. Однако, когда мы пишем книгу рецептов, то мы следуем определенному набору действий. Собираем информацию, организуем ее и тестируем. После того, как мы опробовали какие-то рецепты, мы можем внести в них изменения, адаптировать, улучшить, а какие-то из них и вовсе исключить из списка за ненадобностью. И если наша книгу удачна, то мы можем продолжать над ней работу, выпускать второе, третье издание, то есть продолжать жизненный цикл нашего продукта. Этим примером я хотел акцентировать ваше внимание на том, что при использовании гибких методологий для разработки ваших высокотехнологичных продуктов сами такие продукты стоит рассматривать как живые, развивающиеся организмы, а не какое-то статичное состояние, к которому вы придете в той или иной точке работы над проектом. Именно этому нас учит философия AGILE, и именно этот подход мы будем развивать на протяжении курса. И еще хотел бы добавить, что разработка большинства высокотехнологичных продуктов сегодня тесно связана с разработкой управляющего им программного обеспечения. Так как изначально гибкие методолгии зарождались именно среди разработки программного обеспечения, то многие описания их применения в данном курсе будут ссылаться на связанные с разработкой софта примеры. Имейте ввиду, что сегодня все больше и больше практик и инструментов из гибких методологий применяется и к не софтовым продуктам тоже, и после ознакомления с конкретной практикой вы можете самостоятельно принять решение, готовы ли применять их к вашему конкретному продукту.
