«V Agile» с головой или почему методологии есть добро и зло? Часть 1

Всем привет! Меня зовут Берёзкин Александр и мы продолжаем разгонять рубрику про роль IT Project Manager. Сейчас будет вопрос к HR и рекрутёрам: А как часто вы обращаете внимание на навык кандидата на вакансию, где указано "Знаю/Владею/Использую Agile?". Я думаю, что очень часто, однако стоит поставить вопрос иначе. А вы сами знаете для чего он?

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

В данном посте я хочу поговорить про методологии, которые используются в работе и, возможно, приоткрыть глаза на вещи, которыми прикрываются недобросовестные проджекты. Для тех, кто работает на производстве/заводе будет понятно, что это как ведение DFMEA, FMEA.

Поговорим про их разновидности. Популярные методологии знает практически любой в IT сфере и даже за её пределами. Попробуйте не раскрыть себе все карты и угадать топ-3 методологии, которые используются в работе. Готовы? Я верю в вашу честность.

Если вы угадали 3 из 3, то мои поздравления!

На просторах интернета или при просмотре вакансии на hh, Хабре и других источниках вы наткнётесь на обязательные навыки в виде знаний n-ых методологий. Эти 3 типа будут встречаться чаще всего, если ваш уровень junior/junior+ или middle-/middle. Однако существуетгораздо больше методологий и способов их внедрения. Сегодня я постараюсь рассказать вам часть из них и описать плюсы, минусы и нужны ли они вообще?

Методологии в IT Project Managment-е:

Пожалуй можно остановиться на них, ибо если выписывать их все, то получится безумно скучное и нудное чтиво (хотя кому как!). Некоторые заметят и спросят:

Вопрос хороший, но ответ на него простой, ровно как и спойлер к всей теме поста - PMBoK не имеет ничего общего с методологией. Ровно как и Agile!

Описать PMBoK можно как фреймворк для проектного менеджера, но ни в коем случае не смешивать с методологией. Давайте обратимся напрямую в Википедию для определения:

Свод знаний по управлению проектами (англ. Project Management Body Of Knowledge, PMBOK) представляет собой сумму профессиональных знаний по управлению проектами.

Если говорить куда более простым языком, то PMBoK можно назвать неким эквивалентом ГОСТ для PM.

Но вернёмся к основной повестке - Agile это не про методологии.

В изречениях одного человека на просторах Ютуба, а именно основателя компании KT Team Андрея Путина я наткнулся на ролик, который описывает методологию Agile, а именно Fakegile (лексически сохранено исходя из ролика).

Если кому-то будет интересно, то вы можете посмотреть этот ролик. Я не жадничаю и не рекламирую, но хочу поделиться им.

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

Для тех, кто подзабыл и для тех, кто читает это впервые процитирую 4 ценности в манифесте:

Существуют 12 принципов, которые мы могли бы рассмотреть, но дабы не цитировать Википедию и побуждать интерес к дополнительному изучению, оставлю ссылку для ознакомления.

Рассматривая ценности "методологии" мы можем сказать, что это буквально фундаментальная база и окажемся правы. Только мы говорим об этом совсем иначе.

К примеру каждый из нас переносит ценности Agile на свою повседневную жизнь в работе и в быту:

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

Рассматривать необходимо комплексно, как цельную картину паззла, но избегая самоповтора в этом тексте я хочу вычленить главную суть:

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

У вас всегда будет некий график/схема последовательности или слабой связанности, которая поможет проработать слабые места продукта. Задайтесь вопросом: "Как обычное сохранение принципов и ценностей поможет мне построить модель ведения проекта?". Вы можете не отвечать, ведь на это у меня есть ответ.

Самое вкусное блюдо получается при смешивании двух взаимодополняющих ингредиентов. Химическая реакция будет протекать так, как вам надо при сопоставлении компонентов в нужных пропорциях. Вы берёте самое лучшее и создаёте симбиоз. Ровно тот же результат получится при скрещивании ценностей и принципов Agile с моделью и процессом подходящей методологии.

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

Однако и здесь может быть встречный аргумент:

Если ваш проект обречён на звание самого консервативного и прямолинейного, то забудьте про слово гибкость. Вы усложните работу в первую очередь не только себе, но и своей команде. Первые "плоды" вы пожнёте тогда, когда постараетесь изобретать дополнительное колесо к велосипеду и сбивать команду с верно намеченного курса. Это замедлит скорость разработки и может вытеснить основную суть и идею проекта.

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

Но давайте рассмотрим ещё один случай.

Пример: медицинская компания обратилась к вам с просьбой доработать функционал сайта, в котором будут автоматически считываться данные и преобразовываться в готовые цифры как показатели стабильности (или же нет) пациента. Работа серьёзная и очень ответственная, ведь даже один неверно поставленный диагноз и лечение могут не вылечить здоровье пациента, а оказывать нулевой эффект. В лучшем случае человеку не станет хуже, а в худшем может быть вплоть до летального исхода.

В этом случае цена ошибки слишком высока, чтобы например закрыть глаза на документацию или требования клиента. Никто не хочет лишаться лицензии и брать грех на душу.

Подводя небольшие итоги хочется тезисно задокументировать суть Agile:

Существует много статей и публикацией на тему того, почему нельзя считать Agile методологией и почему применять её ценности и принципы важно только в связке, но я хотел в первую очередь это раскрыть для людей, которые не понимают что такое Agile и с чем его едят. Большинство разработчиков, верстальщиков, тестировщиков будут чаще плеваться от него, чем получать ту самую пользу и философию, которую несёт в себе Agile.

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

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

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

На связи Берёзкин Александр. Был рад оказаться вам полезен!

See ya soon!