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

Встречи, встречи, встречи

Кажется, что ядро ​​современного гибкого подхода вращается вокруг синхронных встреч. Что я имею в виду? Подумайте о своем среднем дне в гибкой среде. Ваша первая встреча - это фуршет. Если вы работаете из дома, вы, скорее всего, присоединитесь через Zoom, Slack, Teams и т. Д. Если вы в офисе, вы, скорее всего, используете переговорную. В зависимости от количества людей, участвующих в стендапе, это может занять от 15 до 30 минут. Эту встречу обычно проводит Скрам-мастер, о которой мы поговорим чуть позже, и предполагается, что она предназначена для разработчиков. Каждый разработчик расскажет, что они делали вчера, что делают сегодня, есть ли у них какие-либо блокираторы и какие они могут быть (если они есть).

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

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

Гибкое лидерство

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

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

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

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

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

Устранение проблем

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

Решение встреч

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

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

Решение лидерства

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

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

Последние мысли

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