Превращает ли Scrum активных разработчиков в пассивных разработчиков?

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

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

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

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

Тем не менее, из-за методологии scrum, теперь многие решения просто приходят от владельца продукта. Он отдает приоритет PBI , он анализирует, как должно работать программное обеспечение, даже иногда, как следует реализовывать интерфейс и функциональность. Я знаю, что это является частью методологии Scrum, и я также знаю, что это может привести к улучшению продаж продукта в будущем. Однако теперь я чувствую, что мне всегда говорят что-то делать, вместо того, чтобы что-то делать . Этот синдром теперь сделал меня более пассивным к работе.

1. Я склонен искать меньше, чтобы найти лучшее решение, подход или технику
2. Я не просыпаюсь утром в ожидании приятной работы. Скорее, я чувствую себя вынужденным работать, чтобы жить
3. У меня больше голода работать над своими хобби-проектами после работы
4. Я больше не буду подталкивать команду, чтобы перейти на более высокий технологический уровень
5. Теперь я провожу больше времени на ужине или чаепитии и меньше энтузиазма, чтобы вернуться к работе
6. Теперь я хочу больше, чтобы работа закончилась раньше, чтобы я мог вернуться домой

Большая проблема в том, что я вижу и диагностирую такое поведение и у моих коллег. Это результат схватки? Действительно ли scrum заставляет команду разработчиков чувствовать, что они не участвуют в формировании всего программного обеспечения, таким образом делая пассив для проекта? Как я могу преодолеть это чувство?

Однако теперь я чувствую, что мне всегда говорят что-то делать, вместо того, чтобы что-то делать.

Это серьезный показатель того, что что-то сошло с рельсов. Гибкий проект не должен чувствовать себя так. Риторика «люди над процессом» должна включать «мы не заставляем наших людей делать то, что отстой». Вот несколько идей:

Вы делаете "Scrum но"? То есть частично схватка, частично какая-то другая вещь. (т.е.: «Мы занимаемся скрамом, но все наши истории должны исходить от нашего PMO, а не от владельца продукта».) В наши дни множество сумасшедших дерьмов называется Scrum.

Вы лично не вовлечены в процесс, в котором вы должны быть? Я знал, что многие люди расстраиваются из-за содержания историй, и оказывается, что они участвуют только после того, как история попала в спринт. Поговорите с владельцем продукта на ранней стадии разработки истории и получите свой отзыв. (Как ПО, они имеют последнее слово, но это не значит, что они должны сделать это в одиночку.)

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

Ваша проблема не в Scrum (и, как Джаррод Роберсон упомянул в комментариях, это не Scrum, что вы описываете) - это микроуправление Владельца продукта и отсутствие уверенности в себе (и вашей команде) .

«Тем не менее, из-за методологии scrum, теперь многие решения просто принимаются владельцем продукта. Он отдает приоритет PBI, он анализирует, как должно работать программное обеспечение, даже иногда, как должны реализовываться пользовательский интерфейс и функциональность. Я знаю, что это является частью методологии scrum».

Вы ошибаетесь Просто из краткого обзора страницы Википедии для Scrum можно увидеть, что: «Команда, межфункциональная группа, которая занимается фактическим анализом, проектированием, внедрением, тестированием и т. Д.» Видеть? Владелец продукта говорит вам, что делать, но команда должна решить, как это сделать.

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

КСТАТИ микроуровне делает свою очередь активных разработчиков в пассивные разработчик.

То, что вы описываете, НЕ СКРАМ

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

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

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

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

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

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

Мне грустно слышать истории о том, что такие хорошие вещи извращаются, как это.

Я предполагаю, что до Scrum все просто делали то, что хотели: yippee ki-yay mf'er . Ваши пользователи являются вашими благотворителями, и они ведут историю и оплачивают счета. Владелец продукта гарантирует, что история закончена. Так или иначе, ваша группа пришла к выводу, что владелец продукта должен рассказывать вам, как программировать.

Вы хотите написать код или сделать аккуратные маленькие приложения, которые вы считаете классными? «Сначала я хочу использовать функцию А, а не В, чтобы сохранить свободу выбора». Найдите другого благодетеля, а не новую методологию развития.

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

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

Agile - это не следование предписанному пути, а то, что оно делает вас более продуктивным и мотивированным. Люди, а не процессы, говорят манифест (перефразированный), и это теряется в используемой вами системе.

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

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

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

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

Получаете ли вы пользовательские истории в форме "Как - роль ... я хочу - цель / желание - чтобы это --benefit--"? Похоже, что ваш владелец продукта хочет сделать работу по дизайну, и он / она не может быть лучшим человеком, чтобы сделать это. Использование шаблона пользовательской истории может помочь гарантировать, что Владелец продукта придерживается интересов бизнеса, а разработка программного обеспечения осуществляется разработчиками программного обеспечения.

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

Из проворного манифеста:

Нашим главным приоритетом является удовлетворение потребностей клиентов путем своевременной и непрерывной поставки ценного программного обеспечения.

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

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

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

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

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

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

И у нас иногда есть микроуправление, но это другая проблема.

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

Q: Методология предписывает х, но х не работает хорошо. Что нам делать?

A: Уточните вашу реализацию x. Может быть, прекратить делать это вообще. Методология не главный из вас!

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

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

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

Роль лидеров в самоорганизующейся команде - это сообщение в блоге о том, что, по-видимому, отсутствует в вашем сообщении. Где команда решает, какую работу выполнять в спринте? Где команда имеет право собственности на процесс и работу? У вас есть кто-то, кто достаточно хорошо знает Scrum, что вы делаете Scrum, а не какую-то извращенную версию?

У меня был такой же опыт со Scrum, и мне нравится называть это «тиранией истории».

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

Единственный выход, который я нашел до сих пор, состоял в том, чтобы либо отказаться от Scrum - часто это невозможно и / или нецелесообразно, потому что в конце концов у него есть свои преимущества, - или представить что-то вроде 20% времени Google, чтобы дать разработчикам творческий выход помимо «вы». Вы можете сами выбирать, как реализовать страницу входа в систему », потому что на самом деле вы не ограничены существующим кодом и архитектурой системы, если ваша реализация не предусматривает свободу выбора между циклом« a for »и« while » свобода.

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

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

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

Да, и по моему опыту это не имеет никакого отношения к Scrum / agile. Произошло разборки, итеративный, водопад, что угодно. Кажется, вопрос доверия не зависит от процесса

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

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