Здравствуйте, HFTMan, Вы писали:

IT>>Сколько у вас человек в команде и какого они уровня?
HFT>Agile не масштабируется на команду больше 20 человек, ну с натягом 25 человек(совсем край), но это уже при отлаженном до швейцарских часов процессе.
HFT>Оптимум не больше 15 человек.

Как пишут апологеты, оптимальный размер 6 +- 3, т.е. 3-9 человек. Больше 13-ти аджайл перестаёт работать совсем. По моим наблюдениям примерно так и есть. Думаю, это связано с тем, что в группе из пяти человек всегда найдётся минимум один балабол. И если в группе из 5-10 человек его (или пару таких) быстро заткнут и поставят на место, то при наличии таких 3-х и более у них образуется кворум и хрен ты их уже остановишь. Тем более, что в большом коллективе из 15 человек народ ведёт себя по-другому, более официозно, и воспринимает такую болтовню как что-то само-собой разумеющееся и складывается впечатление, что вот это и есть настоящий аджайл. В результате любой митинг превращается в бесконечный трёп нескольких балаболов.

У нас количество sprint participants периодически доходит до 27-ми. При этом чтобы высказаться по теме нужно вклиниться в бесконечный галдёж, куда тебя пускать никто не собирается. Можно только либо повысив голос и не очень культурно прервав докладчика, либо забить совсем и решить всё после митинга. Либо подождать. Но пока будешь ждать трындёж съедет на другую тему и ты будешь выглядеть в определённом смысле тормозом. В общем, веселуха. При этом большая часть народа сидит и откровенно зевает и занимается разглядываем экранов телефонов. Т.е. имеем типичное комсомольское собрание времён совка — 3-4 докладчика в президиуме и скучающую аудиторию, с нетерпением ожидающую концовку мероприятия.

HFT>Процесс разработки более масштабных проектов надо пилить именно на такие куски, чтобы части этого масштабного проекта разрабатывались командами именно такой численности.

Это всем известно. Не известен только правильный критерий распила. Как пилить будем? По функционалу? По этажам/странам где-кто сидит? По уровню/полу/рассе/сексуальной ориентации?

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

HFT>Проекты были разные, и коробочные(несколько штук), и инфраструктурные(т.е. потребителями являются несколько команд коробочных продуктов), численность именно всей команды была от 6 до 20+ человек(в компании с кол-вом команд разработки в несколько десятков проектов и общей численностью R&D 2000+ человек).

Несколько проектов за какой срок? Если это коротенькие типовые проекты максимум на год, максимум два, то вполне возможно, что аджайл даже можно сюда притулить. Особенно, если проекты типовые.

HFT>Самый большой по кол-ву участников проект был в таком составе: менеджер проекта, два архитектора в пике, потом один (потому что потребителей нашей условно облачной инфры было чуть ли не десяток других команд и много надо действительно подумать над архитектурой), тим-лид команды разработки(он же и ведущий программер был, хотя по факту мог быть еще один ведущий), несколько синьоров, несколько обычных девелоперов, парочка джунов, тим-лид команды автотестирования, несколько синьоров автотестеров/просто автотестеров(по факту они программеры же, но пишут автотесты, а не бизнес-код), один-два аналитика(часто обслуживали не только наш проект), один-два дизайнера(тоже обслуживали несколько проектов), это те, кто конкретно работали над проектом. Но при этом еще были из бизнес-дивизиона персоналии, выступающие как заказчики продукта(они на нашу текучку вообще не завязаны были), отделы эксплуатации и тех.поддержки, которые этот самый продукт в продакшене эксплуатировал и саппортил(куча народа, которая кучу же и других проектов обслуживала, а не только наши).

И как вы распределяли задачи между джуниорами и синьорами/архитекторами. Аджайл ведь предполагает, что в команде все равны и любой из команды может выбрать себе задачу по душе. Это, кстати, ещё одна аджайл бредятина. Типа разбиваем задачу на несколько частей. Первую часть берёт на себя какой-нибудь джуниор или криворучка. Вторую часть — ручки из жопки или "бывший кобольщик/жалко выгнать старичка". И так далее. И вот когда 95% задачи уже типа сделано, то начальник, понимая, что это — жопа, выдёргивает какого-нибудь синьёра и поручает ему всё нахрен переписать, только по-тихому, чтобы не обидеть джуниора/криворучку/ручку-из-жопки/старичка. Ведь у нас калабарейшин и тим билдинг. Люди могут обидеться, а так с людями нельзя. Раньше их никто к этой задаче не подпустил бы. Тот же самый синьёр сделал бы её в одно рыло в более короткий срок и один раз. Но в аджайл это никак низя.

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

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