Интерпретация основных ценностей Agile и почему теория, лежащая в основе метода, так же важна.

Когда-то давно, в былые времена, я работал разработчиком программного обеспечения. На самом деле, я был разработчиком много лет своей жизни, прежде чем перешел в мир Scrum Mastery/Project Management. Помню, в тот период, когда я совершал переход, несколько коллег сказали мне:

"Зачем вам проходить курс по Scrum, ведь это просто?"

"Все знают, что такое Agile, сертификат не нужен".

«Скрам-мастера на самом деле ничего не делают, кроме как… проводят встречи».

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

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

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

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

Гибкий

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

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

Хотя Манифест Agile состоит из 12 принципов, мы сосредоточимся на четырех основных ценностях Agile. Они следующие:

  • Люди и взаимодействие важнее процессов и инструментов
  • Рабочее программное обеспечение важнее полной документации
  • Сотрудничество с клиентами при обсуждении контрактов
  • Реагирование на изменение вместо следования плану

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

Люди и взаимодействие важнее процессов и инструментов

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

Рабочее программное обеспечение важнее полной документации

  • Когда дело доходит до выбора между рабочим продуктом или наличием подробной документации, чаще всего клиент выбирает первое (при условии, что они не могут выбрать и то, и другое).
  • В Waterfall нужно было сопоставить несколько страниц подробной документации и диаграмм еще до того, как программное обеспечение было запущено. Это резко замедлило жизненный цикл разработки. Работа с Agile позволяет создавать документацию по мере необходимости и по мере ее создания.
  • Хотя ключевой задачей является качественное работающее программное обеспечение, это не означает, что ошибки никогда не возникнут. Важно учиться на типах возникающих ошибок и следить за тем, чтобы одни и те же ошибки не повторялись.
  • Документация — неплохая вещь, и она чрезвычайно полезна для самых разных людей. При необходимости документация должна поставляться вместе с самим программным обеспечением или после него.

Сотрудничество с клиентами при обсуждении контрактов

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

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

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

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

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

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

Несмотря на это, вам сейчас важно подумать; что решают эти ценности, и как вы их интерпретируете так, чтобы это хорошо работало для вашей компании?