Небольшой экскурс: молодая и небольшая компания, успешно применяющая Agile-подходы и Scrum в частности, вела всю разработку ПО одним отделом, разбитым на несколько Scrum-команд. Каждая Scrum-команда разрабатывала свой продукт и всё было хорошо.
Угроза пришла откуда не ждали. Параллельно с разработкой ПО сформировался и развивался отдел аналитики. Первое время аналитики были заняты методологическими документами и на разработку ПО почти не имели никакого влияния. Методологические документы разрабатывались по заказу одной крупной софтверной компании. Разработка с ними велась настолько плотно, что наши аналитики и руководство нашей компании не могли не прознать про то, как у них всё устроено. А было всё устроено по классическому каскадо-водопаду. Софтверная компания была настолько крупной и авторитетной, что руководство нашей компании приняло всё на веру и решило обязательно внедрить их подход к разработке.
Поначалу, возможно, не понимая для чего, а впоследствии объяснив это необходимостью заказной разработки, руководством компании был принят опасный коктейль следующих решений:
- Вместо роли Product Owner нам нужен Главный аналитик;
- Командам разработчиков строго запрещено напрямую взаимодействовать с заказчиком. Только аналитики имеют на это право;
- Команда разработчиков должна получать все задачи от команды аналитиков. Результаты выполнения этих задач должны сдаваться им же;
- Раз разработчикам так нужен Agile, то пусть используют Agile у себя внутри, мы даже оставим итерации и аналитики будут передавать разработчикам не всё ТЗ целиком, а небольшие порции требований, скорректированные с учетом последней демонстрации тестовой версии программы заказчику;
- Проектированием бизнес-процессов, модели предметной области и пользовательского интерфейса занимаются аналитики. Они делают это итерациями. При передаче каждой порции требований разработчикам, также передается соответствующая им документация.
Всё это привело к тому, что два проекта, которые можно было сделать за квартал, делались почти год и так и не дошли до первого релиза на продакшен. Это произошло из-за того, что:
- От итерации к итерации приходилось менять архитектурные решения, что иногда приводило к очень большим рефакторингам и выбрасываниям в корзину больших кусков кода. Разработчики не видели всю картину в целом, они были оторваны от заказчика, не участвовали в процессе аналитики и не видели ТЗ целиком. Аналитики, не зная реализации, также не могли предвидеть изменения в архитектурных решениях;
- Часто простые вещи аналитики делали невероятно сложными, отчасти из-за малого опыта в разработке, а отчасти из-за нового девиза компании “Мы решаем сложные задачи!”;
- Главный аналитик стал мега звездой и требовал особого подхода к своей персоне;
- Разработчики и как не странно аналитики были демотивированы. Часто вспыхивали конфликты. Например, аналитики начали жаловаться на то, что разработчики задают много вопросов и это сильно отвлекает их от текущих задач. После того как главный аналитик пожаловался начальству, было принято решение, что программисты могут задавать вопросы только в процессе передачи задачи, после того как задача принята, вопросы задавать нельзя!
- Были большие проблемы с управляемостью проекта. Никто не хотел брать на себя полную ответственность за проект в целом (в том числе и менеджер проекта).
Итог
Наличие итеративности не спасло эти проекты, а только усугубило ситуацию. Как известно итерационная разработка позволяет своевременно менять направление развития продукта. Это достигается за счет выпуска релиза в конце каждой итерации, а также сбора и анализа обратной связи. Смена направления в итерационной разработке достаточно частое явление, поэтому нет смысла писать детальное ТЗ, оно будет устаревать быстрее чем писаться. Отсутствие ТЗ компенсируется единым информационным пространством команды, в котором небольшими порциями накапливаются знания, благодаря совместным усилиям всей команды. Таким образом, итеративность это необходимое, но не достаточное условие для Agile разработки, как минимум ещё должна быть единая команда разработчиков (системные аналитики, дизайнеры, архитекторы, программисты, тестировщики)!
Каскадо-водопад и Agile сами по себе прекрасные методологии разработки ПО. Каждая из них имеет свои плюсы и минусы, по набору которых можно совершить правильный выбор в пользу одной из них для каждого проекта. Если у вас фиксированный бюджет, сроки и требования, то используйте каскадо-водопад. Если у вас нет сроков (продукт развивается непрерывно на протяжении всего жизненного цикла) и нет необходимости в жесткой фиксации требований, то используйте Agile. Но не в коем случае не смешивайте эти два подхода!
Комментарии (21)
dborovikov
16.07.2015 11:23+3Так и есть, я долго искал понятное определение Agile для себя, до этого было только интуитивное понимание. Так вот Agile — это когда разработчики и заказчик решают пойти по стопам кота Леопольда и говорят «давайте жить дружно». Т.е. работать как одна комманда со взаимопониманием и доверием — «мы не требуем от вас четкого ТЗ на весь проект, а вы не требуете от нас четкой оценки бюджета всего проекта, вместо этого работаем поэтапно, и вместе решаем проблемы». Кстати, когда решают «давайте жить дружно» разработчики и админы, из этого получается DevOps.
wAngel
16.07.2015 11:51Пример того, как любое формальное следование чужим методологиям приводит к «культу карго».
Так вообще бывает? Посмотреть на другую компанию и решить работать точно так же?
ssova Автор
16.07.2015 12:49Другая компания скорее послужила доп. стимулом и образцовым примером. Наша компания не стала брать каскадо-водопад в чистом виде, а адаптировала его под себя
donnaAnna
16.07.2015 14:59+1Крупная компания, видимо, госкомпания, либо их дочка. Госкомпании вынуждены работать по каскадной модели. Плюс техзадание у них это вообще не техзадание, а бог знает что, хоть и соответствует гост 34 602. Почему? потому что цель техзадания — это получить предсказуемый результат в тендере, а не продукт, и не, тем более, достижение цели проекта. В госпроектах продукт owner это вообще мифический человек. И в результате — ни гост, ни prince2 (хотя в вышеприведенном примере ну просто напрашивается), ни agile, а банальный кавардак, ccmi уровня ноль, где хоть какой-нибудь результат достигается героическими усилиями отдельных лиц. Но истинная беда для разрабов, что там, где недостаток управляемости, там пытаются компенсировать нажимом руководства…
webkumo
16.07.2015 15:55+2Кхм… Ну вот изоляция разработчиков от заказчиков (в моём случае — не глухая, но всё же есть) — это такое благо… Вот никакого желания общаться с представителями заказчика напрямую не возникает (как с не очень квалифицированным персоналом — пользователями системы, так и с, по-идее, вполне квалифицированными специалистами-разработчиками заказчика, работающими над связанной подсистемой).
В общем проблема-то не в пунктах, а в их реализации…
Tiendil
16.07.2015 16:15Испорченный телефон никто не отменял.
Если хочется получать деньги и не напрягаться, то с заказчиками можно и не общаться.
Если хочется приносить пользу людям, делать реально полезный продукт, то общаться надо.
summerwind
16.07.2015 16:31+1За счет чего продукт станет менее полезным, если с заказчиком будет общаться только аналитик, структурировать хаотичную информацию, приводить ее в понятный вид и обсуждать это все с разработчиками в спокойной обстановке?
Tiendil
16.07.2015 16:58А аналитик — не разработчик? :-)
Ну и для части коммуникаций аналитик или менеджер не нужны, сообщать о неработающих кнопках или технических проблемах вполне можно сразу ответственным за это людям. Конечно, если коммуникации нормально налажены.summerwind
16.07.2015 17:10Под разработчиками я имею в виду именно пишущих код людей. А обязанность аналитика как раз заключается в сборе, анализе и структуризации требований от заказчика.
Насчет кнопок и технических проблем — лично для меня оочень неудобно, когда заказчик напрямую звонит/пишет из-за каждой неработающей кнопки напрямую программистам по 50 раз в день. Гораздо эффективней (по моему мнению), когда менеджер собирает такие задачи и ставит в бак трекере.
ssova Автор
16.07.2015 17:33В Agile, Product Owner выполняет бизнес анализ и является ответственным лицом за коммуникацию со стэкхолдерами. Таким образом, он значительно снижает нагрузку на команду связанную со взаимодействием. Но, у команды остается возможность самой взаимодействовать со стэкхолдерами для проведения системного анализа, проектирования пользовательского интерфейса и архитектуры системы.
ssova Автор
16.07.2015 18:22Полная изоляция программистов от стэкхолдеров (именно программистов, а не разработчиков) возможна только в классическом каскадо-водопаде. И да, для программистов в этом есть определенный плюс.
ssova Автор
16.07.2015 21:44Впрочем для Agile тоже не принципиально важно взаимодействие программистов со стэкхолдерами, оно может происходить опосредовано, через Product Owner'а.
Прошу прощения за разговор самого с собой. Уважаемые модераторы, обьедините, пожалуйста, три моих комментария в один.
Punk_UnDeaD
17.07.2015 00:22+1Например, аналитики начали жаловаться на то, что разработчики задают много вопросов и это сильно отвлекает их от текущих задач. После того как главный аналитик пожаловался начальству, было принято решение, что программисты могут задавать вопросы только в процессе передачи задачи, после того как задача принята, вопросы задавать нельзя!
Ух. Надо было вообще запретить вопросы задавать,
gandjustas
17.07.2015 02:06+1я так понимаю проблема исключительно в аналитиках, которые должны были уменьшать неопределённости и помогать программистам, а получилось ровно наоборот. Аналитиками почувствовали себя важными, у них началась звездная болезнь и они начали работать не над решением проблем, а над повышением собственной значимости.
Это никак не зависит от модели ЖЦ проекта, я видел ровно такую картину при строго водопадной разработке.
Проблема решается очень просто — нужно чтобы аналитики отвечали перед разработчиками за качество своей работы.
velvetcat
17.07.2015 12:02Никто не должен ни перед кем отвечать. Agile — это когда все работают вместе (каждый на своем участке), за факап одного отвечают все, и таким образом все заинтересованы в помощи друг другу.
gandjustas
17.07.2015 17:12Вы неправильно понимаете слово «отвечать». Суть в том, что каждый участник проекта создает артефакты, которые потом валидируются другими участниками. Например программисты создают приложение, которое потом проверяют тестеры и с ним работает заказчик.
А вот с аналитиками беда: простой текст — довольно плохой носитель сложно структурированной информации, а всяческие нотации обычно не понимаются всеми. Поэтому рабочие документы, которые рождает Аналитик практически никто не может провалидировать, кроме программиста. А программист, который не общается с заказчиком, тоже не может сделать этого в полной мере. Да еще и при модели, когда программисты не общаются с заказчиками программисты оказываются ниже «в пищевой цепочке» и стоящие выше аналитики не должны их спрашивать.
Вот и получается, что аналитик может сделать что угодно и не получит по факту никакого фидбека на свою работу, это и создает ситуации, описанные в посте.
brewerof
17.07.2015 17:42+1Раз разработчикам так нужен Agile, то пусть используют Agile у себя внутри, мы даже оставим итерации и аналитики будут передавать разработчикам не всё ТЗ целиком, а небольшие порции требований, скорректированные с учетом последней демонстрации тестовой версии программы заказчику;
Разработчикам уносить ноги надо из таких «молодых и небольших компаний». Тут по одному абзацу понятен уровень развития менеджмента.
dymmasja
В нашей компании взаимодействие с бизнесом тоже осуществляется только через аналитикам, и сначала разработчики сдают им истории (внутреннее демо), а потом аналитики демонстрируют продукт бизнесу. Это п.3 и 4 «опасного коктейля». Наш проект обречён?
ssova Автор
Я не упомянул в статье один важный момент, наши аналитики проводили не только бизнес-анализ, но также забрали на себя проектирование пользовательского интерфейса и предметной области.
Если ваш аналитик выполняет только бизнес-анализ, то он возможно выполняет роль Product Owner и тогда всё хорошо — это чистый Agile.
Если ваши аналитики проводят системный анализ, то если разработчики с аналитиками образуют единую команду и единое информационное пространство (все концепции в голове аналитика, также есть и в голове у разработчиков, а аналитик в свою очередь многое знает о реализации), опять же всё хорошо — это чистый Agile, аналитик внутри команды.
Если же у вас есть барьер между аналитиками и разработчиками и аналитики выполняют системный анализ, то можно попытаться устранить этот барьер, а можно и перейти полностью на классический каскадо-водопад, с детальным ТЗ, спецификациями и проч., оставив барьер на месте.