Какие группы должны участвовать в Гибком? [закрытый]

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

И нет. членов в команде ограничено 7-10. Так что эта группа должна быть соответственно сегментирована.

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

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

Мне кажется безумным, что дизайнеры, команда UX, фронтенд-разработчики и системные администраторы участвуют в голосовании, чтобы оценить, сколько времени займет выполнение бэкэнд-задачи. Я почти не знаю! Итак, мой вопрос: не слишком ли я резок? Может ли это работать в среде Agile?

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

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

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

короткий ответ - да.

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

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

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

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

Agile-команды должны быть «кросс-функциональными» , то есть иметь много специалистов, работающих вместе с некоторым перекрытием.

Для веб-разработки и даже для ИТ-инфраструктуры может иметь смысл иметь администратора базы данных , дизайнеров, бизнес-аналитиков, программистов (независимо от того, какие навыки вам нужны) и специалистов по ИТ-инфраструктуре в одной команде.

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

Не забывайте привлекать людей:

• которым необходимо подписать документы,
• людей, которые администрируют общие объекты, такие как DNS, LDAP,
• администраторы сети,
• люди, которые покупают и обслуживают оборудование,
• охранники ...

Я участвовал в проектах, в которых программное обеспечение было готово вовремя, а DNS или оборудование - нет - что является # ошибкой для заказчика. С какими вещами, находящимися вне вашего контроля, вам понадобится помощь? Руководители групп, тренеры и мастера схватки должны смотреть на одну или две итерации вперед, чтобы привлечь нужных людей.

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

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

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

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

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

Agile - это сотрудничество и здравый смысл. Тем не менее, я думаю, что все будет сводиться к реальной команде. Могут ли они эффективно сотрудничать? Если нет, возможно, вам придется это исправить. Что вам говорят ваши ретроспективы? Agile - это путь, а не пункт назначения

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