История одного факапа или почему итеративность — это необходимое, но не достаточное условие для Agile

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

Небольшой экскурс: молодая и небольшая компания, успешно применяющая Agile-подходы и Scrum в частности, вела всю разработку ПО одним отделом, разбитым на несколько Scrum-команд. Каждая Scrum-команда разрабатывала свой продукт и всё было хорошо.

Угроза пришла откуда не ждали. Параллельно с разработкой ПО сформировался и развивался отдел аналитики. Первое время аналитики были заняты методологическими документами и на разработку ПО почти не имели никакого влияния. Методологические документы разрабатывались по заказу одной крупной софтверной компании. Разработка с ними велась настолько плотно, что наши аналитики и руководство нашей компании не могли не прознать про то, как у них всё устроено. А было всё устроено по классическому каскадо-водопаду. Софтверная компания была настолько крупной и авторитетной, что руководство нашей компании приняло всё на веру и решило обязательно внедрить их подход к разработке.

Поначалу, возможно, не понимая для чего, а впоследствии объяснив это необходимостью заказной разработки, руководством компании был принят опасный коктейль следующих решений:
  • Вместо роли Product Owner нам нужен Главный аналитик;
  • Командам разработчиков строго запрещено напрямую взаимодействовать с заказчиком. Только аналитики имеют на это право;
  • Команда разработчиков должна получать все задачи от команды аналитиков. Результаты выполнения этих задач должны сдаваться им же;
  • Раз разработчикам так нужен Agile, то пусть используют Agile у себя внутри, мы даже оставим итерации и аналитики будут передавать разработчикам не всё ТЗ целиком, а небольшие порции требований, скорректированные с учетом последней демонстрации тестовой версии программы заказчику;
  • Проектированием бизнес-процессов, модели предметной области и пользовательского интерфейса занимаются аналитики. Они делают это итерациями. При передаче каждой порции требований разработчикам, также передается соответствующая им документация.

Всё это привело к тому, что два проекта, которые можно было сделать за квартал, делались почти год и так и не дошли до первого релиза на продакшен. Это произошло из-за того, что:
  • От итерации к итерации приходилось менять архитектурные решения, что иногда приводило к очень большим рефакторингам и выбрасываниям в корзину больших кусков кода. Разработчики не видели всю картину в целом, они были оторваны от заказчика, не участвовали в процессе аналитики и не видели ТЗ целиком. Аналитики, не зная реализации, также не могли предвидеть изменения в архитектурных решениях;
  • Часто простые вещи аналитики делали невероятно сложными, отчасти из-за малого опыта в разработке, а отчасти из-за нового девиза компании “Мы решаем сложные задачи!”;
  • Главный аналитик стал мега звездой и требовал особого подхода к своей персоне;
  • Разработчики и как не странно аналитики были демотивированы. Часто вспыхивали конфликты. Например, аналитики начали жаловаться на то, что разработчики задают много вопросов и это сильно отвлекает их от текущих задач. После того как главный аналитик пожаловался начальству, было принято решение, что программисты могут задавать вопросы только в процессе передачи задачи, после того как задача принята, вопросы задавать нельзя!
  • Были большие проблемы с управляемостью проекта. Никто не хотел брать на себя полную ответственность за проект в целом (в том числе и менеджер проекта).

Итог


Наличие итеративности не спасло эти проекты, а только усугубило ситуацию. Как известно итерационная разработка позволяет своевременно менять направление развития продукта. Это достигается за счет выпуска релиза в конце каждой итерации, а также сбора и анализа обратной связи. Смена направления в итерационной разработке достаточно частое явление, поэтому нет смысла писать детальное ТЗ, оно будет устаревать быстрее чем писаться. Отсутствие ТЗ компенсируется единым информационным пространством команды, в котором небольшими порциями накапливаются знания, благодаря совместным усилиям всей команды. Таким образом, итеративность это необходимое, но не достаточное условие для Agile разработки, как минимум ещё должна быть единая команда разработчиков (системные аналитики, дизайнеры, архитекторы, программисты, тестировщики)!

Каскадо-водопад и Agile сами по себе прекрасные методологии разработки ПО. Каждая из них имеет свои плюсы и минусы, по набору которых можно совершить правильный выбор в пользу одной из них для каждого проекта. Если у вас фиксированный бюджет, сроки и требования, то используйте каскадо-водопад. Если у вас нет сроков (продукт развивается непрерывно на протяжении всего жизненного цикла) и нет необходимости в жесткой фиксации требований, то используйте Agile. Но не в коем случае не смешивайте эти два подхода!
Share post

Comments 22

    +1
    В нашей компании взаимодействие с бизнесом тоже осуществляется только через аналитикам, и сначала разработчики сдают им истории (внутреннее демо), а потом аналитики демонстрируют продукт бизнесу. Это п.3 и 4 «опасного коктейля». Наш проект обречён?
      +1
      Я не упомянул в статье один важный момент, наши аналитики проводили не только бизнес-анализ, но также забрали на себя проектирование пользовательского интерфейса и предметной области.

      Если ваш аналитик выполняет только бизнес-анализ, то он возможно выполняет роль Product Owner и тогда всё хорошо — это чистый Agile.

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

      Если же у вас есть барьер между аналитиками и разработчиками и аналитики выполняют системный анализ, то можно попытаться устранить этот барьер, а можно и перейти полностью на классический каскадо-водопад, с детальным ТЗ, спецификациями и проч., оставив барьер на месте.
      +3
      Так и есть, я долго искал понятное определение Agile для себя, до этого было только интуитивное понимание. Так вот Agile — это когда разработчики и заказчик решают пойти по стопам кота Леопольда и говорят «давайте жить дружно». Т.е. работать как одна комманда со взаимопониманием и доверием — «мы не требуем от вас четкого ТЗ на весь проект, а вы не требуете от нас четкой оценки бюджета всего проекта, вместо этого работаем поэтапно, и вместе решаем проблемы». Кстати, когда решают «давайте жить дружно» разработчики и админы, из этого получается DevOps.
        0
        Пример того, как любое формальное следование чужим методологиям приводит к «культу карго».

        Так вообще бывает? Посмотреть на другую компанию и решить работать точно так же?
          0
          Другая компания скорее послужила доп. стимулом и образцовым примером. Наша компания не стала брать каскадо-водопад в чистом виде, а адаптировала его под себя
          +1
          Крупная компания, видимо, госкомпания, либо их дочка. Госкомпании вынуждены работать по каскадной модели. Плюс техзадание у них это вообще не техзадание, а бог знает что, хоть и соответствует гост 34 602. Почему? потому что цель техзадания — это получить предсказуемый результат в тендере, а не продукт, и не, тем более, достижение цели проекта. В госпроектах продукт owner это вообще мифический человек. И в результате — ни гост, ни prince2 (хотя в вышеприведенном примере ну просто напрашивается), ни agile, а банальный кавардак, ccmi уровня ноль, где хоть какой-нибудь результат достигается героическими усилиями отдельных лиц. Но истинная беда для разрабов, что там, где недостаток управляемости, там пытаются компенсировать нажимом руководства…
            +3
            Описание типичного карго-культа.
              +2
              Кхм… Ну вот изоляция разработчиков от заказчиков (в моём случае — не глухая, но всё же есть) — это такое благо… Вот никакого желания общаться с представителями заказчика напрямую не возникает (как с не очень квалифицированным персоналом — пользователями системы, так и с, по-идее, вполне квалифицированными специалистами-разработчиками заказчика, работающими над связанной подсистемой).

              В общем проблема-то не в пунктах, а в их реализации…
                0
                Испорченный телефон никто не отменял.

                Если хочется получать деньги и не напрягаться, то с заказчиками можно и не общаться.
                Если хочется приносить пользу людям, делать реально полезный продукт, то общаться надо.
                  +1
                  За счет чего продукт станет менее полезным, если с заказчиком будет общаться только аналитик, структурировать хаотичную информацию, приводить ее в понятный вид и обсуждать это все с разработчиками в спокойной обстановке?
                    0
                    А аналитик — не разработчик? :-)

                    Ну и для части коммуникаций аналитик или менеджер не нужны, сообщать о неработающих кнопках или технических проблемах вполне можно сразу ответственным за это людям. Конечно, если коммуникации нормально налажены.
                      0
                      Под разработчиками я имею в виду именно пишущих код людей. А обязанность аналитика как раз заключается в сборе, анализе и структуризации требований от заказчика.
                      Насчет кнопок и технических проблем — лично для меня оочень неудобно, когда заказчик напрямую звонит/пишет из-за каждой неработающей кнопки напрямую программистам по 50 раз в день. Гораздо эффективней (по моему мнению), когда менеджер собирает такие задачи и ставит в бак трекере.
                  0
                  В Agile, Product Owner выполняет бизнес анализ и является ответственным лицом за коммуникацию со стэкхолдерами. Таким образом, он значительно снижает нагрузку на команду связанную со взаимодействием. Но, у команды остается возможность самой взаимодействовать со стэкхолдерами для проведения системного анализа, проектирования пользовательского интерфейса и архитектуры системы.
                    0
                    Полная изоляция программистов от стэкхолдеров (именно программистов, а не разработчиков) возможна только в классическом каскадо-водопаде. И да, для программистов в этом есть определенный плюс.
                      0
                      Впрочем для Agile тоже не принципиально важно взаимодействие программистов со стэкхолдерами, оно может происходить опосредовано, через Product Owner'а.

                      Прошу прощения за разговор самого с собой. Уважаемые модераторы, обьедините, пожалуйста, три моих комментария в один.
                  0
                  Все равно ХХивП всех победит! :)
                    +1
                    Например, аналитики начали жаловаться на то, что разработчики задают много вопросов и это сильно отвлекает их от текущих задач. После того как главный аналитик пожаловался начальству, было принято решение, что программисты могут задавать вопросы только в процессе передачи задачи, после того как задача принята, вопросы задавать нельзя!

                    Ух. Надо было вообще запретить вопросы задавать,
                      +1
                      я так понимаю проблема исключительно в аналитиках, которые должны были уменьшать неопределённости и помогать программистам, а получилось ровно наоборот. Аналитиками почувствовали себя важными, у них началась звездная болезнь и они начали работать не над решением проблем, а над повышением собственной значимости.

                      Это никак не зависит от модели ЖЦ проекта, я видел ровно такую картину при строго водопадной разработке.

                      Проблема решается очень просто — нужно чтобы аналитики отвечали перед разработчиками за качество своей работы.
                        0
                        Никто не должен ни перед кем отвечать. Agile — это когда все работают вместе (каждый на своем участке), за факап одного отвечают все, и таким образом все заинтересованы в помощи друг другу.
                          0
                          Вы неправильно понимаете слово «отвечать». Суть в том, что каждый участник проекта создает артефакты, которые потом валидируются другими участниками. Например программисты создают приложение, которое потом проверяют тестеры и с ним работает заказчик.

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

                          Вот и получается, что аналитик может сделать что угодно и не получит по факту никакого фидбека на свою работу, это и создает ситуации, описанные в посте.
                        +1
                        Раз разработчикам так нужен Agile, то пусть используют Agile у себя внутри, мы даже оставим итерации и аналитики будут передавать разработчикам не всё ТЗ целиком, а небольшие порции требований, скорректированные с учетом последней демонстрации тестовой версии программы заказчику;


                        Разработчикам уносить ноги надо из таких «молодых и небольших компаний». Тут по одному абзацу понятен уровень развития менеджмента.
                          0
                          Мы в компании с самого начала используем вариант с аналитиками, пока полет нормальный.
                          Попробую высказать ИМХО, по вашим проблемам:
                          >>> От итерации к итерации приходилось менять архитектурные решения, что иногда приводило к очень большим рефакторингам и выбрасываниям в корзину больших кусков кода.

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

                          >>>Часто простые вещи аналитики делали невероятно сложными, отчасти из-за малого опыта в разработке, а отчасти из-за нового девиза компании “Мы решаем сложные задачи!”;

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

                          >>>Главный аналитик стал мега звездой и требовал особого подхода к своей персоне;

                          Имейте 2х сильных аналитиков в конторе, чтобы можно было одного заменить другим в случае необходимости.

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

                          Это полный трэш. Если аналитик не может разжевать задачу и ответить на все вопросы разработчика, гнать его надо! Если вопросов много или повышай качество передачи информации разработчику или сиди с ними пока не сможем все рассказать.

                          >>>Были большие проблемы с управляемостью проекта. Никто не хотел брать на себя полную ответственность за проект в целом (в том числе и менеджер проекта).
                          Что значит не хотел? У ПМа работа такая брать ответственность на себя. Не хочет работать — до свидания!

                          Only users with full accounts can post comments. Log in, please.