Agile головного мозга

16 Авг
2011

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

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

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

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

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

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

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

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

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

Fotolia 32789945 XS

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

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

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

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

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

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

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

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

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

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

На прощание

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


  • Andrii Iasynetskyi

    С удовольствием прочитал. В твоем тексте все мои мысли по этому поводу :) Более того, я убежден, что всякого рода навязанные методологии убивает креатив и превращают работу инженера в повседневную рутину, в которой никогда не родится ничего нового. Но ключевое слово здесь – навязанные. Т.е., если команда сама для себя принала такой подход и он ей действительно помогает, тогда мое убеждение анулируется.

  • К сожалению совет «работайте с умом» ещё более бесполезен чем «слепо следуйте методологиям».

    Последний хотя бы даёт какое-то понимание конкретных действий.

    Мало того, это как раз из тех текстов, которых начитываются исполнители и начинают тебя тыкать в них носом, когда процесс начинает им надоедать. Типа «мы увязли в этом! Надо подходить более творчески и включать голову». Где-то тут обычно начало конца и таких людей надо увольнять тут же.

    • Konstantin Vlasenko

      Мурат вы не правы:) Ну и фраза <<> действительно идет в разрез с коммуникацией и мотивацией людей. Статья мне понравилась.

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

      • Dukobpa3

        Не вижу разницы между работником и исполнителем. Возможно вы имели в виду «Сотрудник» ;)

        Полностью согласен с Муратом. И бывают таки Сотрудники, с большой буквы. Члены команды. А бывают тупо исполнители. Из таких типа: «ёжик — птица гордая, пока не пнешь — не полетит». И вот такие вот ёжики действительно любят такой хлам читать и потом огрызаться цитатами, когда их пинаешь чтоб выше и быстрее летали.

        Правильных тиммейтов и пинать не надо, они тебя сами пинать будут. А статья вцелом правильная, только не для всех...

        • Чтобы ежики не огрызались нужно им сразу вместе с полномочиями предлагать соответствующую ответственность, протрезвляет!

    • Где ты увидел совет «работать с умом»? Это не совет, а обязательное требование вообще-то :)

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

      Ну а ты вполне можешь быть честным со своими «исполнителями», четко объяснить свои цели и показать им что свое мнение они должны обосновывать, при чем основываясь на фактах, а не на «я так думаю», предложить взять ответственность за их действия, желательно и финансовую. Это людей обычно очень попускает. То есть порулить и делать то что хочется многие хотят, а отвечать за свои поступки — единицы. Если ты это до своих «исполнителей» не доносишь — это твоя проблема.

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

  • Как мне кажется «истина где то рядом». Первая моя реакция: «вот оно, все верно, мои мысли». Но вспоминая некоторые моменты прошлого, понимаешь, что без активного внедрения всего этого ничего менятся не будет. Более того, чтобы понять нужны «обряды» или нет — их надо попробовать. Другое дело, что все «непошедшее» должно выключаться и не навязываться. Самое сложное понять причину того, почему «не пошло»: действительно мешает или просто "вы не умеете это готовить. "

    • Дык, инструмент тем и отличается от обряда что его выбор осмысленный, он нужен чтобы решить конкретные проблемы и не будет использован если не подходит. То есть, если скрам митинг — это эффективное средство коммуникации внутри команды и люди в комманде с этим согласны — нет никаких проблем, проблемы начинаются когда скрам митинг нужен потому что так написано в книге Кена Швабера, а члены команды считают это просто тратой времени и бюрократией.

  • Все сказано правильно, но все-таки я отчасти поддержу Murat Prokopov. «Работать с умом» хорошо, когда ум у всех один. Однако, что вы будете делать, если все понимают под этим разное? Для кого-то «работать с умом» это дописывать на production сайт никому не говоря и даже без комита в общий репозиторий «быстрые костыли» по требованию клиента. А, что? Коммуникация важнее формальностей, меня попросили, я быстро зашел и пофиксил. Отлично сработал, покомуницировал с клиентом и героически (целых два дня убил!) исправил проблему, фидбэк мгновенный. А то, что другой разработчик через день затрет изменения, так как будет брать «релизый код», а то, что эта бага была мелочью, а в это время сайт просто лежал у половины клиентов, так как там есть проблемы серезнее, а то что архитектор поставил этот код на рефакторинг и модуль пойдет под снос, а то, что сапорт осуществляют совсем другие люди, которые тоже «работают с умом», только со своим, а то что... Да мало ли что еще. Методология не религия, но это хороший способ приобрести такой ум, с которым уже можно работать. А когда инструмент больше не нужен его кладут в дальний ящик стола. Вы же не катаетесь на детском трехколесном велосипеде всю жизнь. Коленки в руль упираются. Так, что могу сказать — следите за коленками и прекратите винить во всем велосипед, он не виноват.

    • Все что вы описали является примерами откровенно херового менеджмента (вернее его отсутствия), а не проблемы «работать с умом».

      Команда отличается от просто группы людей тем что у ее участников общие цели и вектор направления, при чем далеко не всегда это означает что всем в команде это нравится. Это задача руководителя — организовать целостную команду и организовать ее рабочий процесс. Более того, его же задача — доносить до участников команды цели и объяснять их, чтобы у команды было целостное представление о работе. С теми, кто в итоге становится полноценным членом команды, признающим ее цели и ограничения работают дальше, от остальных обычно избавляются (просто не всегда людям открыто говорят что проблема в том что они не сработались с командой).

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

  • volandzz

    Пять описанных выше обрядов это Scrum, одна из реализаций Agile. И сравнение Agile-манифеста cо скрамом в виде "Обратите внимание, в манифесте вообще ничего не говорится о пяти описанных выше обрядах! " вызывает только улыбку =)

    • Удивительно, я всегда был уверен что Scrum — это методология, а не просто набор практик, не привязанный к каким-то целям ;)

  • Pingback: scrum – agile = problems « Sergei’s blog on bugs, penguins and stuff()

Наверх