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

Мы находимся примерно на полпути через наш переход от водопада к ловкому с использованием схватки; мы перешли от больших команд в бункерах технологий / дисциплин к меньшим кросс-функциональным командам.

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

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

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

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

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

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

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

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

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

Они просто не находят радости в работе, как раньше.

Верный.

Это большой признак того, что вы делаете это неправильно.

Agile не должен навязывать плохой новый порядок людям.

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

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

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

Почему они не могут продолжать это делать?

Зачем их менять?

Пожалуйста, прочитайте Agile Manifesto несколько раз.

Agile Манифест говорит

Индивидуумы и взаимодействия над процессами и инструментами

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

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

Рабочая программа над исчерпывающей документацией.

Они делают это? Тогда оставь их в покое.

Сотрудничество с клиентом по договору.

Вы уже делаете это? Тогда не меняйся.

Реагировать на изменения в соответствии с планом.

Где эти люди уже способны реагировать на изменения? Если так, то они уже были Agile. Им не нужно было меняться.

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

В прошлом выпуске я был в «гибкой» команде, в которой было ИМХО слишком много разработчиков с разным уровнем квалификации, и мы пытались вовлечь всех в один и тот же проект. Это была катастрофа. Мы больше говорили / спорили, чем работали, и в конце концов команда создала среднюю работу (прочитайте Peopleware или Mythical Man Month о получении среднего). Забудьте о шаблонах проектирования, забудьте о слабой связи или разбиении кода на небольшие классы и методы. Забудьте о попытках сделать что-нибудь интересное, потому что а) это не может быть объяснено и понято всеми членами команды (по крайней мере, не своевременно) и б), поскольку мы были проворны, независимо от того, что я начал эту итерацию, кто-то другой, абсолютно не понимающий будет продолжаться в следующей итерации. Лично,

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

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

Но теперь перед вами стоит выбор. A) Возьмите всех своих хороших старших разработчиков, которые производят высококачественный код, и поместите их в свою собственную команду, а все остальное - в отдельную команду. Или Б) попытаться сбалансировать команды и поставить хорошие с не очень хорошими. В (А) проблема заключается в том, что одна из ваших команд будет сильно отставать и не будет приобретать хорошие навыки / привычки у хороших парней. В (B) ваши хорошие парни (в чистой проворной среде) почувствуют разочарование и начнут работать над своим резюме. Шахта современна.

Так что тебе делать?

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

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

Это не совсем ответ, но он подводит итог моего опыта / наблюдений. Я хочу посмотреть, что другие скажут по этому поводу.

Что такое Agile?

Это:

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

• лучший подход для достижения цели с учетом ваших сильных сторон, требований и ограничений?

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

Если вы думаете больше о втором, то поздравляю - вы получаете Agile. Любая гибкая методология может быть только подсказкой того, как добиться успеха. Если какой-либо аспект выбранного вами гибкого метода не подходит вам, тогда вы обязаны прекратить его использование, изменить его или иным образом быть гибким.об этом. Важно то, что вы достигнете чего-то, что вас не сдерживают искусственные ограничения - не только те, которые мы все знаем и любим из наших давних дней водопада, когда премьер-министр будет хлопотать вас за полные документированные диаграммы, которые никто никогда не будет читайте только потому, что «это то, что говорит процесс», а также из-за ограничений, которые вы используете. Если ежедневная схватка кажется ограничением, то не моргайте! Иметь их вслепую, потому что правила говорят так, не более проворно, чем старые способы.

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

Алистер Кокберн описал это в своих методах. Если у вас есть «практикующие 3 уровня», то вполне допустимый метод agile выглядит следующим образом:

«Поместите 4-6 человек в комнату с рабочими станциями и досками и доступом для пользователей. Попросите их предоставлять работающее, протестированное программное обеспечение пользователям один или два месяца, а в остальном оставляйте их в покое ».

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

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

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

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

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

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

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

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

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

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

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

То, что я хотел бы увидеть здесь, это расширить ответственность этих разработчиков и помочь им изменить их фокус на общую картину. Может быть, это означает новое название, например, Software Architect, Team Lead или Senior Software Engineer. Затем покажите им, что это возможность оказать большее влияние не только на один проект за раз, но и на несколько проектов. Чувство причастности все еще может присутствовать, но их внимание должно быть сосредоточено не на реализации одного великого проекта, а на том, чтобы помочь установить планку для ВСЕХпроекты. Помогите им выразить свое сильное желание создать что-то великое, но сместить акцент на развитие практики разработки программного обеспечения вашей компании и других разработчиков. Вместо того, чтобы сдерживать мысли о том, что их коллеги взламывают свой код на куски, это может стать для них шансом подняться на следующий уровень, наставить своих товарищей по команде и поднять их на свой уровень.

Я попытаюсь проиллюстрировать некоторые аспекты, которые не были рассмотрены в других ответах и ​​которые, IMO, важны.

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

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

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

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

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

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

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

Кроме того, «предоставление рабочих функций в более короткие промежутки времени» приводит к прерыванию рабочего процесса. Это может быть нормально, если функциональность «добавить кнопку отмены на странице входа в систему», которая может быть завершена к концу спринта, но когда вы работаете над сложной задачей, вы не хотите таких прерываний: это как пытаясь проехать 100 км как можно быстрее и останавливаясь каждые 5 минут, чтобы проверить, как далеко вы продвинулись. Это только замедлит тебя.

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

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

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

Просто мои 2 цента.

Some developers are primarily motivated by the joy of taking a piece of difficult 
work, thinking through a design, thinking through potential issues, then solving
the problem piece by piece, with only minimal interaction with others, over an 
extended period of time

Похоже, они "Одинокие рейнджеры". В каноническом Scrum эти люди просто не вписываются в команду (они упускают бит «взаимодействия»).

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

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

В нашей команде есть специальная группа только для повышения производительности. Мы не видим их очень сильно, просто в начале спринта, чтобы поговорить об изменениях, которые должны быть сделаны, и в конце в ретроспективе. У них есть свой «лидер схваток», который подчиняется команде Scrum of Scrum. Я могу сказать вам, они наслаждаются.

Если Джо (ваш разработчик Hero) немного гибок, то я не вижу проблемы:

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

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

1. Предоставление функциональности через регулярные промежутки времени: если вы дадите Джо несколько месяцев на то, чтобы решить проблему, а до самого конца ничего не показывать, то Джо действительно не будет ловким: он берет в заложники владельца продукта и не дает ему возможности повторно специфицировать эта часть продукта. С этой практикой также существует риск того, что он опаздывает, и никто этого не замечает. (Но по твоему описанию это не так уж и вероятно). Помощь: Было бы слишком много просить у Джо сидеть вместе с ПО, разбивать историю пользователей и согласовывать промежуточные результаты, желательно (но не обязательно) с ценностью пользователя?

2. Соблюдение приоритетов, установленных владельцем продукта: если части кода принадлежат экспертам, то вы рискуете создать ситуацию, когда эволюция продукта определяется наличием каждого эксперта, а не коммерческими приоритетами: остальная часть команды может работать над менее важными функциями, в то время как первые три функции останавливаются, потому что «только Джо может сделать это». Плохо. В этот момент команда должна (временно) изменить свою привычку и разделить работу Джо на большее количество членов команды.

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

Правила для гибкой команды должны быть настроены так, чтобы соответствовать команде - это может быть действительно индивидуальная настройка; Например, я работал в команде, где правило было:

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

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

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