Достаточно часто я слышу от заказчиков вопрос, работаю ли я с методологией Agile. Более того, на одном из крупных проектов еще на старте директор компании-заказчика мне сказал: «Рамиль, я хочу, чтобы вы с нами работали в Agile, с использованием Scrum».
Того клиента я убедил, что во всем этом нет никакой необходимости. Но все же вопросы об этих инструментах появляются снова и снова. Про Scrum мы поговорим в другой раз. А сейчас я хотел бы разобрать вместе с вами, что такое на самом деле Agile.
Что такое Agile
Первое, что нужно понимать, на самом деле методология Agile не имеет никакого отношения к понятию методологии. Хотя бы потому, что методология – от слова «метод». Т.е. в рамках методологии имеется какой-то набор действий, которые при их выполнении приведут к определенному результату. В нашем случае результатом должна стать разработанная программа.
Я уже писал ранее о том, что такое информационная система, разбирались мы и с тем, как выполняется планирование проекта. Об этом вы можете почитать в соответствующих публикациях:
Компьютерная информационная система.
Подробное описание компьютерных информационных систем (иначе – IT систем).
Но вернемся к теме статьи. Итак, мы хотим разработать информационную систему. В ответ нам говорят: «Используйте Agile, работайте в соответствии с 4 принципами, и вы получите необходимый результат». Давайте разберем эти принципы подробно.
Люди и взаимодействие важнее процессов и инструментов
На самом деле, нельзя противопоставлять людей, взаимодействие процессам и инструментам. Это бессмысленно. Хотя бы потому, что процессы – это люди, которые взаимодействуют. Получается, что мы противопоставляем часть и целое.
Возможно, создатели этой фразы имели в виду каких-то других людей или не самих людей, а их желания. Но пояснений нет, а само противопоставление – явная бессмыслица.
Во всей фразе имеет некоторый смысл только противопоставление с инструментами.
Здесь очевидно, имеется в виду, что не так важно, при помощи каких инструментов (языков программирования, программных систем и т.д.) выполняется работа, как тот факт, кто это делает и как. С одной стороны, это кажется правильным. С другой, получается все равно бессмыслица, так как люди все равно выполняют работу с помощью определенных инструментов. Нет смысла отделять людей от удобных для них инструментов.
Например, если вы наймете программиста, который работает на PHP, он будет решать поставленную задачу при помощи инструментов PHP. Конечно, вы можете ему сказать, что он вам очень важен. Но в качестве инструмента предложите ему, например, Ruby, результат вы получите очень нескоро. Если получите его в принципе. Потому что специалисту по PHP придется долго изучать новый для себя язык Ruby. Сколько времени это займет и насколько качественный код он сможет создавать на новом для себя языке, вопрос открытый.
Работающий продукт важнее исчерпывающей документации
Здесь нужно понять, что такое работающий продукт. В какой степени этот продукт можно назвать работающим? И является ли полученный результат вообще продуктом, который был необходим? Вопросов много. А все ответы на них обычно содержатся в документации.
Т.е. если мы говорим о работающем продукте как о результате действий в соответствии с четко поставленными целями и задачами, только на основании документации можно понять, соответствует ли продукт всем требованиям и все ли решения реализованы.
При разработке IT-систем без какого-либо документального описания, будь то нотация бизнес-процесса, текстовое описание в виде техзадания или любого другого четкого и однозначного документального описания, о работающем продукте говорить не имеет смысла.
Например, мы решили создать систему приема заказов. В результате система заказы принимает, но в другую IT-систему их не отсылает. Или заказы система принимает, данные своевременно передает для обработки, но скидки покупателей не читает. Может ли быть работающим продуктом такая система или нет? Ведь в принципе, система работает. Основную функцию выполняет. А без исчерпывающей документации доказать, что на самом деле нужен совсем другой результат, невозможно.
Сотрудничество с заказчиком важнее согласования условий контракта
Хоть этот пункт оказался третьим, на самом деле, он самый лукавый из всех. Считается, что методологию Agile создавали разработчики. Но на самом деле, ни один разработчик не будет работать без четко оговоренных условий контракта.
Более того, само сотрудничество с заказчиком – это и есть четкое и своевременное выполнение условий контракта.
Документ, на основе которого вы планируете сотрудничество, можно назвать иначе. Это может быть не контракт, а договор, техзадание и т.д. Но, если нет четко и однозначно прописанных и согласованных условий, сотрудничество попросту невозможно.
В принципе, если это и правда писали разработчики, их мотивы понятны. Чем меньше четкой и однозначной документации, тем больше простора для трактовки той или иной задачи. Соответственно, программист, у которого не получается создать программу именно такой, как хотелось бы, может воспользоваться недостаточно точным описанием, чтобы себя защитить.
Но на самом деле, такой подход чаще приводит к конфликтам, чем к успешному завершению проекта.
Готовность к изменениям важнее следования первоначальному плану
А этот пункт однозначно самый плохой. Все просто. Вы никогда не построите ракету, если из раза в раз будете собирать ее заново, просто потому, что появилась еще одна идея изменений. Здесь же предлагается при желании со стороны заказчика соглашаться на те или иные изменения, даже если они усложняют проект или ведут к значительным изменениям в его работе.
Чтобы сотрудничество завершилось успешно и в оговоренные сроки, наоборот, необходимо четко следовать поставленному плану. А если плана у вас нет вообще, то возникает вопрос, а что вы вообще разрабатываете?
Agile-манифест: итоги и выводы
Как видите, при помощи манифеста Agile, вы никогда не «построите ракету». Важно понимать, что задолго до появления Agile, Водопадов и многих других подобных «методологий», во всем мире писали программные системы, строили те самые ракеты, сложное оборудование, даже в космос летали. И для этого использовали традиционный подход – постановка целей, подробное техническое описание (техзадание), планирование, движение к заранее известному результату.
Но тогда возникает вопрос, а зачем вообще нужна Agile? И откуда у нее такая популярность? На самом деле, все просто. Это еще один метод, разработанный маркетологами, для создания дополнительной цены.
Не путайте дополнительную цену с добавленной стоимостью! В нашем случае это просто «наценка» за то, что человек позиционирует себя не просто программистом, а как программист, который знает Agile. Звучит солидно, название на слуху. В результате клиенты согласны платить больше.
А по сути, это еще один «информационный шум», который не стоит особого внимания. Красивый манифест не несет в себе ничего революционного. Более того, на самом деле, там есть дополнение, которое говорит, что «мы не отрицаем важность того, что справа» в каждом из принципов. В результате в случае удачного выбора вы получите разработчика, который будет работать качественно, основываясь на четко поставленных целях и задачах, в соответствии с заранее разработанным планом. И ничего более.
Что касается определенной гибкости в вопросах сотрудничества, ей также обладает любой специалист, независимо от того, рассказывает он вам о манифесте Agile или нет. Определенные изменения, доработки, дополнительные функции – все это встречается практически в любом проекте.
С одной стороны, оказывается, что на практике какие-то нюансы реализовать легче и разумнее несколько иначе, чем планировалось. С другой стороны, заказчик также вносит определенные пожелания. Небольшие изменения возможны в процессе работы. Какие-то достаточно трудоемкие доработки оставляют на будущее после реализации основного проекта.
В любом случае, есть план и ему необходимо следовать. Если мы этого не делаем, то нарушаем обязательства как перед собой, так и перед своими заказчиками.
Если вам интересна тема взаимодействия с заказчиками, рекомендую почитать мою статью
Борьба противоположностей: заказчик и исполнитель
Краткий разбор публикации в Atlassian об Agile
На портале Atlassian появилась статья «Манифест agile все еще имеет вес?» Эту статью написал разработчик, создатель системы, которая якобы использует Agile. Потому при изучении этой статьи нужно понимать, что у автора наблюдается явный конфликт интересов.
Соответственно, если вы ее изучите, ничего из описанного выше, вы не найдете. В статье вообще нет ни слова критики Agile. Сама “методология” там принимается безусловно и «по умолчанию». Зато автор много внимания уделяет истории появления Agile, существованию «черного» и «белого» Agile и другим нюансам. Как будто эти все рассказы подтверждают само существование методики (а мы с вами уже поняли, что это не так).
Манифест – да, имеется. Он был создан для определенных целей. Об этом в указанной статье, кстати, вполне понятно написано. Специалисты стремились избавиться от избыточного документооборота. Но эта проблема касалась исключительно США в определенный период времени. Дальнейшее развитие культа псевдо-методики, тем более, в нашей стране не приносит никакой пользы.
Четко оговаривайте цели и задачи проекта, занимайтесь планированием, работайте в соответствии с согласованными документами, проявляйте гибкость только там и тогда, когда это не мешает основному плану работ. И ваши проекты будут завершаться успешно к взаимному удовлетворению.