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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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