Интерпретация основных ценностей 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 или как он пытается решить проблемы прошлого, а видели только интерпретацию и внедрение в нескольких избранных компаниях.
Несмотря на это, вам сейчас важно подумать; что решают эти ценности, и как вы их интерпретируете так, чтобы это хорошо работало для вашей компании?