От теории к практике

Agile может быть слишком проворным!

Оказывается, теория и практика - это одно и то же ... теоретически.

Я создал блог!

Новые истории будут публиковаться в моем блоге: https://www.flavienbonvin.com/

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

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

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

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

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

Agile - модное слово

Естественно, наш профессор не сказала этого, не приведя аргументов и объяснив, почему она считает, что методология Agile реализована не полностью (или правильно). Она утверждала, что компании злоупотребляли этим словом, не понимая, что оно означает, или что используется только его часть.

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

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

Только когда я учился на бакалавриате, я понял, что программа - это живое существо; Я также научился ценить преимущества, которые приносит методология Agile. Если я объясню это сейчас, это значит, что я должен был провести специальные исследования в области ИТ, чтобы понять, что означает Agile. Для кого-то из другой отрасли (и других методов управления проектами) естественно чувствовать себя потерянным, когда мы пытаемся продать ему спринты.

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

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

Agile - это образ мышления

Неджма объяснил, что большинство компаний считают Agile методологией управления проектами, а на самом деле это образ мышления. Часто компании начинают внедрять Канбан или отставание продукта и вуаля: они гибкие! Это не может быть дальше от истины; внедрение инструментов - это только часть процесса, чтобы стать Agile. Бизнесу необходимо перейти от мышления, основанного на задержках, затратах и ​​масштабах, к мышлению, ориентированному на ценности.

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

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

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

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

Agile слишком гибок?

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

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

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

Я думаю, что во время учебы на степень бакалавра я испытал то, что закрыто от Agile-мышления. Мы были просто друзьями, создавая сайт или приложение в спринтах (некоторые из них можно найти на моем GitHub, если вам интересно). Спринты не всегда соблюдались (мы часто недооценивали нашу скорость; это можно объяснить тем, что мы не отслеживали время, потраченное на работу), но, в конце концов, опыт был стимулирующим и захватывающим. Я помню разговор, который у меня был с одним из моих друзей; Я надеялся найти компанию, которая могла бы обеспечить такую ​​же энергию и атмосферу, как та, которую я испытал во время своих проектов в Университете. Это было слишком весело и увлекательно!

Вот преимущества, которые я увидел, работая так же, как и во время бакалавриата; их можно продолжить двумя словами:

Связь и доверие.

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

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

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

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

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

Красота Agile заключается в его названии. Agile хорош, потому что он маневренный!

В чем моя точка зрения?

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

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

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

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

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

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