Как управлять командами в рамках одного проекта?

Question

[Роман Якимчук]

Всем привет

Стало интересно, как управлять большим количеством команд, скажем, порядка 20 команд компании, вовлеченных в один проект. Например, есть проект, и 20 команд по 4-5 разработчиков, плюс архитектор над ними.

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

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

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

Итого вопрос, как построить процесс так, чтобы изменения сделанные множеством команд одного проекта соответствали требованиям архитектора и проходили корректную проверку (архитектурные ошибки, или грубые ошибки кодирования не попадали в общую кодовую базу)?

Если знаете литературу, посоветуйте, пожалуйста

Comments

[twoone]

У меня такое представление о разработке было в первые года обучения. На самом деле все намного проеще, но откроется это лишь с опытом или обучением, коего сейчас навалом. Читайте все что связанно с agile, чем больше, тем лучше. И помните, доверие и делегирование - залог здорового руководителя.

UPD: Другой ответ вы если и получите, то он будет безумен, поскольку незная какой проект, на каком стеке он разрабатывает, какие критерии к нему предъявляются, какой уровень компании (её финансовые возможности) - ответ дать нельзя. Кроме того, нужно знать ваш уровень чтобы понять о чем конкретно вы спрашиваете.

[Роман Якимчук]

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

Лишь ищу более приемлемые варианты, чем пускание всего на самотек и создания коллективной экспектизы.

[twoone]

Роман Якимчук, жесткое соблюдение конвенций + линтенры, которые просто не позволят написать неправильный, с точки зрения употребления конструкций, код. В ревью должны участвовать все, поскольку это ещё и процес обучения. Его можно и попарно выполнять. Доверие, должно быть доверие. Если нагружать лидов мелочами, они убегут от вас. Вторая линия защиты - тестирование.

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

[twoone]

Роман Якимчук, других вариантов нет. Искать одного ответственного за ревью бесмысленно. Представьте форум, на котором раз в день приходит чувак с рулончиком кода и просит посмотреть что в нем не так. Уже дорож пробирает.. А у вас таких 100. Кто подобное вытерпит? Только все сразу. Если нет денег на крутых разработчиков, то только так.

[Роман Якимчук]

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

В любом случае услышал ровно то, о чем думал. Наверное, это действительно правильный вариант, других не найти. Спасибо.

[twoone]

Роман Якимчук, если архитектор подготавливает спецификацию с uml + bpmn2 + описание, и при этом происходят описанные вами казусы, то либо у вас в командах джуны , что не допустимо по agile, тем более если они на удаленке. Либо они просто не понимаю диаграм и поэтому додумывают сами. Первый случай не исправить. Во втором необходимо процесс обучения налаживать. Еще может быть что архитектор через чур накручивает.. Но это реально нужно знать хотя бы стек. Есть стеки в которые разработчики пришли от архитектурной усталости и поэтому архитектор из классики может их просто бесить. Здесь необходимо по ситуации решать, вести диалог. Может команда переубедит архитектора, а может наоборот. Если в командах люди не могут договорится, то это не команда, а не небольшая толпа. Виноват в этом лид.

[Валентин]

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

[Sanes]

А сейчас как?

[Роман Якимчук]

Валентин, как вы добиваетесь контроля, можете подсказать, если не секрет?

[twoone]

Валентин,

Для каждого требования я должен предусмотреть возможность контроля их выполнения и мониторинга

что значит "возможность контроля"? Вы лично и постоянно, то есть весь код смотрите?

[Валентин]

twoone, нет конечно, зачем архитектору смотреть код)? Организация кода - это про трудовую дисциплину. За этим должен следить руководитель (или другие опытные программисты). Как на заводе - кто следит за тем, чтобы Инструмент лежал на месте и не был растерян? Как проверить - большой брак (возврат на доработку, отзывы от тестировщиков, длительный срок реализации задач) в работе подразделения.

Answer 1

[Robur]

Поэтому выходит что ответственность по ревью (или полностью, или всё кроме архитектуры) нужно делегировать лидам команд.

делегируйте, лиды затем и нужны.

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

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

архитектор сам по себе один в поле не воин, и если команды не высокого уровня, в продукт будут пролазить технические проблемы

Если бы архитектор был один в поле воин, вам не нужны были бы эти 80-100 человек.
Архитектор в первую очередь принимает решения по архитектуре, принимает на себя ответственность за эти решения и доносит это все до остальных. Ответственность за реализацию лежит уже не на нем а на командах.

Текст звучит так что у вас есть кто-то слишком за все ответственный, кто контролирует код который пишут 80-100 человек. Это заведомо гиблое дело. Либо у кого-то очень большое эго, если он сам на себя это взял, либо очень слабый характер, если на него навешали. На таких масштабах вам нужны иерархия и делегирование.

Это что касается уровня написанного кода.
А качество самого продукта(и это совершенно другая штука) должен проверять отдел QA. Либо те кто выполняет эти функции, но на таких масштабах у вас должен быть такой отдел из нескольких человек, явно или не явно.

Answer 2

[Владимир Коротенко]

Роман Якимчук Роман А почему бы не выбросить на помойку Agile ?
По сути заказчику внушают мысль что он сможет спланировать Тяп-Ляп, сэкономить на ТЗ и бизнес аналитиках и по ходу добавлять фичи или удалять. На самом деле выходит, то что вы сказали, кто в лес а кто по дрова.

Comments

[Роман Якимчук]

Agile сам по себе это всего-лишь принципы проверенные практикой, не более того.

1. Individuals and interactions over processes and tools
2. Working software over comprehensive documentation
3. Customer collaboration over contract negotiation
4. Responding to change over following a plan

Поэтому работа по Agile это прежде всего следование здравому смыслу, стремление к эффективности, а не следование бюрократии и палкам в колеса. Вы можете работать по Agile без Скрама и Канбана, представьте себе J

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

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

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

[Владимир Коротенко]

Роман Якимчук, В водопаде пойти к кому то и порешать это тоже самое действенное.
Дело в общем то в отношении с людьми, лично я к практикам планирования перехожу только после первого опыта работы с людьми.

[StepEv]

"заказчику внушают мысль что он сможет спланировать Тяп-Ляп, сэкономить на ТЗ и бизнес аналитиках и по ходу добавлять фичи или удалять"

Это не Agile, а бардак.

[Владимир Коротенко]

StepEv, почему тогда практически всегда начинают именно с этого? И заканчивают ну это команда не та?

[StepEv]

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

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

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

Ну а иначе так и получается, "нам скрам не зашёл, мы теперь по канбану работаем, без спринтов". Эта популярная фраза вызывает facepalm как у тех, кто знает Scrum иак и у опытных Канбанологов.

[StepEv]

И вот ещё, нет такой методологии управления проектами "водопад". И фреймворка такого нет.

[Владимир Коротенко]

StepEv, Waterfall (“водопад”/“каскадная”) Называйте как хотите. Но рассмешили

[StepEv]

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

[Владимир Коротенко]

StepEv, но по этой абстракции действует большинство проектных методик в госорганах. Причём не только у нас. Самое забавное сейчас компьютеры достигли такой мощности что могут давать рекомендации на 2-4 года. Видимо поэтому так и топят за сменяемость власти, горизонт планирования доступен

Answer 3

[StepEv]

Посмотрите как эти проблемы предлагают решать современные масштабируемые фреймворки - Nexus, LESS, SAFe. Для лучшего понимания любого из них стоит сначала разобраться с тем как работает Scrum в рамках одной команды, в чём особенности и выгода самоуправляемых команд, как их строить, как при этом обеспечивать качество. Путь долгий, серебрянной пули нет.

Comments

[Роман Якимчук]

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

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

Я могу ошибаться, но у меня такое видение.

[Роман Якимчук]

Спасибо за ссылки, не знал об этих вещах.

[StepEv]

Nexus содержит Nexus Integration Team, но я не понимаю, почему она "подразумевает наличие технических проблем в продукте, которые будет к проблемам с интеграцией между командами, либо неверно сформированным приоритетам".

Эта команда - развитие концепции Scrum of Scrum, они не занимаются сами интеграциями, интегрировать свою работу должны сами Scrum команды. NIT обеспечивает идентификацию зависимостей, координацию, best practices и т.п. Прочитайте внимательно, в Nexus Guide роль NIT описана достаточно чётко.

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