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

[@dymmasja]

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

[@ssova]

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

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

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

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

[@wAngel]

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

Так вообще бывает? Посмотреть на другую компанию и решить работать точно так же?

[@ssova]

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

[@donnaAnna]

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

[@Tiendil]

Описание типичного карго-культа.

[@webkumo]

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

В общем проблема-то не в пунктах, а в их реализации…

[@Tiendil]

Испорченный телефон никто не отменял.

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

[@summerwind]

За счет чего продукт станет менее полезным, если с заказчиком будет общаться только аналитик, структурировать хаотичную информацию, приводить ее в понятный вид и обсуждать это все с разработчиками в спокойной обстановке?

[@Tiendil]

А аналитик — не разработчик? :-)

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

[@summerwind]

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

[@ssova]

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

[@ssova]

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

[@ssova]

Впрочем для Agile тоже не принципиально важно взаимодействие программистов со стэкхолдерами, оно может происходить опосредовано, через Product Owner'а.

Прошу прощения за разговор самого с собой. Уважаемые модераторы, обьедините, пожалуйста, три моих комментария в один.

[@tgz]

Все равно ХХивП всех победит! :)

[@gandjustas]

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

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

Проблема решается очень просто — нужно чтобы аналитики отвечали перед разработчиками за качество своей работы.

[@velvetcat]

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

[@gandjustas]

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

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

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

[@brewerof]

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

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

[@u_story]

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

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

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

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

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

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

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

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

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