Помню, лет 5-6 назад гибкие методологии разработки казались чем-то очень простым, удобным и человечным — глотком свежего воздуха на фоне монструозных бюрократических процессов разработки ПО, царивших в то время.
Времена меняются, теперь Agile — это мейнстрим. И что же, благодаря этому повсеместно программные продукты стали делаться качественнее и удобнее для конечных пользователей? Проекты стали делаться без срывов сроков и раздувания бюджета? Несомненно — в редких случаях стало лучше, но в основном же все осталось примерно на том же уровне, что и было.
Знаете почему?

Проблема в людях!

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

Представим классическую для вебдванольного аутсорсинга ситуацию: клиент, не понимающий, чего же он хочет, менеджер проекта и аналитик (возможно, менеджер и аналитик в одном лице), роли которых сведены к интерпретации требований клиента на понятный программистам язык и контролю выполнения ими работы, ну и, конечно же, кучка инженеров, ожидающих любых указаний «сверху», требующих, чтобы все было описано как можно подробнее, и уверенных, что их задача состоит в том, чтобы писать хороший код и угождать руководству.

Такой продукт ОБРЕЧЕН! В лучшем случае, его удастся сделать, уложившись в срок, может даже в бюджет, но он никогда не станет успешным, понимаете?

Корни профанации

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

1. Ежедневное стоячее scrum-совещание всей команды на 15 минут, где все должны ответить на 3 вопроса: «что сделал», «что будешь делать?», «что препятствует выполнению твоей работы?».
2. Разбиваем процесс на итерации (обычно одинаковой продолжительности).
3. Ведем требования к проекту в виде User Stories. Вешаем их на доску, оцениваем истории в поинтах вместо часов. Может, даже играем с членами команды в planning poker.
4. В конце итерации проводим ретроспективу, чтобы послушать, кто что думает о происходящем…
5. Некоторые еще добавляют чисто инженерные практики вроде парного программирования, разработки через тесты и парного code review.

Скажите честно, вы действительно думаете, что именно в этих пяти пунктах состоит Agile и именно это нужно, чтобы продукт, который вы делаете, стал успешным?

Давайте взглянем на Agile-манифест — документ, на основе которого как раз и появились гибкие методологии разработки:

• Люди и взаимодействие важнее процессов и инструментов
• Работающий продукт важнее исчерпывающей документации
• Сотрудничество с заказчиком важнее согласования условий контракта
• Готовность к изменениям важнее следования первоначальному плану

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

По-моему, очень зрелые и трезвые мысли. Обратите внимание, в манифесте вообще ничего не говорится о пяти описанных выше обрядах! Более того, в определенных ситуациях эти обряды могут быть даже противоположны тому, о чем говорится в Agile-манифесте.
Успешное выполнение проектов и создание успешных софтверных продуктов — это, в первую очередь, вопрос культуры и опыта, но никак не методологии! Гибкие методологии — это всего лишь наборы рекомендаций и техник, без соответствующей культуры они не помогут вашему проекту ровным счетом ничем!

Scrum-совещания быстро станут унылой бюрократией, если члены команды и без того регулярно делятся друг с другом информацией о своей работе и проекте, либо если члены команды просто не видят пользы в этих совещаниях. Разделение проектной работы на итерации и их четкое планирование вряд ли даст какой-то ощутимый выхлоп, если работа над проектом состоит, в основном, в исправлении багов и вялой поддержке пользователей. Planning Poker вряд ли принесет хоть какую-то пользу, если команда состоит из одного разработчика, одного тестировщика и одного дизайнера, каждый из которых слабо разбирается в работе коллег. Code Review и TDD для одноразовых проектов (рассчитанных, например, чтобы один раз показать где-то на презентации и все) скорее помогут вам успешно просрать бюджет, чем сделать продукт лучше для целевой аудитории.

Работать надо не «чтобы было Agile», а с умом! Управление проектами — это не про методологии, это про людей, про их цели и ожидания, про их коммуникацию, про их мотивацию!

Что же нужно для гибкого процесса разработки?

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

• Четкое понимание бизнеса, для которого делаются продукты: понимание целевой аудитории продуктов, которые ты делаешь. Эти знания должны быть, как минимум, у лидеров проектной команды и заказчика проекта, а в идеале — у всех участвующих в процессе людей.
• Профессионализм проектной команды. Если у нас есть несколько талантливых опытных разработчиков, дизайнер, QA и менеджер — этого еще не достаточно, чтобы считать команду профессиональной, нужно еще многое… Умение всех этих людей работать над общей целью, отлично осознавая, как делается работа коллег в смежных областях. Понимание того, как следует себя вести, если что-то пошло не так, как планировалось, и нужно резко менять курс, импровизировать. Иногда необходимо браться за откровенно неинтересную работу.
• Профессионализм заказчика продукта (в случае работы над собственным продуктом это может быть сама проектная команда). Заключается он в том самом понимании бизнеса, умении адаптироваться к изменениям рынка, прислушиваться к мнению команды, умению вовремя распознать в команде проекта инвалидов и послать их подальше.
• Достаточная смелость, чтобы вовремя признать свои ошибки и донести их до остальных участников проекта, а не стараться тянуть до последнего или вообще скрыть свои ошибки. Опять же касается это всех людей, вовлеченных в проект.
• Мотивация, конечно же! Если участники проекта по какой-то причине не хотят заниматься тем, чем занимаются — ничего хорошего из этого не выйдет, сила воли безграничной не бывает.

Если вам есть, что сюда добавить — отметьтесь в комментариях к статье.

На прощание

Нужно думать головой, а не пытаться следовать методологиям как религиям. Если людям не интересен проект, над которым они работают, а лидеры проекта не понимают, чего хотят — то проблема именно в людях, а не в «неправильной» методологии. Даже если будешь проводить стэндап-митинги, ретроспективы и играть в planning poker — проект всеравно сдохнет!
Работать с умом гораздо сложнее тупого следования набору формальных обрядов, но это единственный надежный способ делать качественные программные продукты в рамках разумных сроков и бюджетов.