Какова роль ведущего разработчика в гибкой команде?

42

В не-гибкой команде разработчиков ведущий разработчик обычно :

  • Устанавливает стандарт (кодирование и другое)
  • Исследует новые технологии для команды
  • Устанавливает техническое направление для команды
  • Имеет последнее слово по вопросам
  • Проектирует архитектуру системы

Однако гибкая команда работает по-другому:

  • Гибкая команда будет полагаться на возникающий дизайн, а не на первый план
  • Гибкая команда разрабатывает вместе, а не дизайн диктуется одним человеком
  • Agile команда выбирает собственное техническое направление, которое лучше всего подходит для реализации проекта

Где это оставляет ведущего разработчика в гибкой команде? Возможно ли иметь ведущего разработчика в гибкой команде? Требует ли гибкая команда разных обязанностей от лидера?

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

Ответы:

46

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

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

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

Ryathal
источник
Можете ли вы добавить некоторые пояснения к тому, что вы подразумеваете под «Раздача решений по указу - это ужасный способ для любой команды разработчиков работать»? Я согласен с остальной частью вашего поста, но согласен с упомянутым утверждением только в определенных отношениях, но не в других. Например, как будет решено использовать SOA поверх уровня базы данных? Разве это не было указом или кто-то не должен был сказать последнее слово? Я спрашиваю, потому что я руководитель команды и столкнулся с этой самой ситуацией. Я призвал не использовать SOA в зависимости от потребностей бизнеса. Просто не хватает времени, чтобы позволить всем разработчикам обсуждать / спорить по каждому вопросу.
Брайан
@ Брайан, принимающий архитектурные решения, был бы историей в спринте, вероятно, предназначенной для конкретного участника, но в остальном такой же, как любая другая история. Он должен быть подвергнут экспертной оценке, как и любая другая история. Аргумент времени - это чушь собачья, если вы пропустили X или решили попробовать Z, потому что все остальные в команде не знакомы с вами, в результате вы потратите больше времени на разработку, даже если целый день спорить о дизайне будет сравнительно незначительным , Простая встреча / обзор, чтобы сказать: «Я выбрал A, потому что X, Y, Z». скорее всего, потребуется час, и мы просто сделаем это совместными усилиями.
Ryathal
30

В гибкой команде каждый должен отложить свое эго в сторону.

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

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

Это в идеальном мире, где люди могут отложить свое эго в сторону. Удачи!

MetaFight
источник
Не согласен Я слишком часто видел опрометчивое решение, принятое разработчиком самостоятельно, с плохими последствиями только потому, что лидера не было, и разработчик не привык к такой ситуации. Стадо кошек, говорю вам.
andrew.fox
20

В дополнение к ответу Ритала :

Вы говорите о формирующемся дизайне и руководстве командой, как будто они вытекают из команды в полном согласии и гармонии. Группы людей, группы программистов особенно конфликтуют . Как руководитель команды, ваша работа в гибкой команде скорее судья или катализатор, чем водопад. Когда у команды возникают разногласия по поводу того, какой дизайн использовать, например, вы убедитесь, что люди имеют равные права голоса и придерживаются споров о достоинствах. И вы в конечном итоге становитесь арбитром, к которому предложит решение, с которым пойдет команда, когда путь не ясен.

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

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

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

Telastyn
источник
1
Это особенно важно на собраниях с «временными рамками», то есть встреча или конкретное обсуждение не будет длиться дольше X минут. В конце концов, кто-то принимает решение и продолжает процесс. Это может быть ведущий разработчик системной архитектуры и связанных с ней дискуссий.
Крис
1
Хорошо сказано. Ведущий разработчик также должен быть направлен на улучшение опыта и понимания команды, в которой он находится, с долгосрочным планом не просто быть «лидером», а скорее членом команды коллег.
Давид 'лысый имбирь'
То, что вы описали, это ScrumMaster.
Д.Бедренко
6

Ваше негибкое описание не делает недействительным ваше гибкое описание.

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

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

Гибкая команда разрабатывает вместе, а не дизайн диктуется одним человеком

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

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

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

BrandonV
источник
6

Вопрос напрашивается на несколько других вопросов. Как вы думаете, что дает вам право говорить команде коллег-программистов, что делать? Это твой опыт? Это смешной маленький титул, который вручил тебе твой босс? Это твое эго? Ваше пребывание в компании? Это твой "размах"? Твой стиль?" Ваши "лидерские качества?"

Agile команды не раздают друг другу значки или шляпы с надписью: «Поздравляю, ты наш супергений - ты единственный, кому разрешено выполнять сверхсекретную работу двойного гения». Скорее, в центре внимания РАБОТА НА РУКАХ. Если вы действительно опытнее, то этот опыт должен ПОКАЗАТЬ, насколько хорошо ваши проекты продвигают работу к завершению. Ваши самостоятельно выбранные задания (карточки) должны отражать области, в которых вы больше всего разбираетесь. С другой стороны, если у какого-то ребенка, который только что закончил колледж, есть идея получше, и это соответствует контексту лучше, чем то, что придумал какой-то 40-летний ветеран. с, с какой стати мы пошли бы с худшим дизайном? Наши рабочие места - это не терапевтические кабинеты, а то, куда мы приходим, чтобы создавать прекрасные вещи.

Возникает другой вопрос: кто решает, что значит «лучше»? Ответ: команда заинтересованных сторон. Это означает, что разработчики, специалисты по требованиям, тестировщики, деловые люди и т. Д. Являются создателями и пользователями рассматриваемой вещи. Если у вас есть отличная идея, вам лучше продемонстрировать, почему она лучше. Если вы не можете этого сделать, то у команды нет оснований полагать, что ваша идея лучше. Agile поощряет меритократию.

Итак, что происходит с «лидером команды разработчиков»? в проворном? Ничего - они просто лучше соответствуют этому названию - они НАСТОЯЩИМ способны быть в состоянии производить лучшее программное обеспечение, чем другие люди в команде. В противном случае, нет никаких оснований называть их «ведущими» - это просто маленький значок или забавная шапка, и это бессмысленно. Многие люди находят это угрожающим. Им кажется, что они «работают» на значок или забавную шляпу. Хорошие разработчики не работают на забавные шляпы. Они работают над созданием отличного программного обеспечения и планируют делать это до тех пор, пока не заработают - их цель - совершенствоваться в создании программного обеспечения каждый день. Если это не вы, возможно, вы захотите взглянуть на управление проектами. Вы, вероятно, будете счастливее.

Calphool
источник
+1 за «РАБОТУ НА РУКАХ». Я согласен сосредоточиться на лучшем решении для того, что вы должны доставить сейчас. Дело не в том, кто придумывает идею.
Квеббл
Если все, что руководитель группы develompent делает в команде SCRUM, по вашему мнению, «производит лучшее программное обеспечение, чем другие люди в команде», то все, чем они являются, - это разработчик без особых обязанностей. Это точка зрения, предложенная вашим ответом? Иначе это действительно не отвечает на вопрос о том, как лидерство разработчика вписывается в команду SCRUM.
Д.Бедренко
Да, это так. Они хороший инженер, поэтому они играют роль инженера (технически, «член команды»). Что еще они будут?
Calphool
3

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

Таким образом, ведущий разработчик остается ответственным за системную архитектуру и выбор технологий. Это очень важно: несмотря на то, что Agile поощряет появление дизайна и рефакторинг, это должно происходить на уровне объектов кода. Система в целом должна иметь больший уровень предварительного проектирования и жесткости, иначе проект рискует стать несогласованным беспорядком.

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

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

Боб Твей
источник
Это похоже на мой опыт, но я действительно считаю, что «значков» и «шляп» больше, чем необходимо. Почти нет разницы между тем, как хороший разработчик думает о дизайне, и тем, что архитектор думает о дизайне.
Calphool