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

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

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

1. Краткая, но надежная система обратной связи

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

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

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

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

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

  • Над чем вы работали в предыдущий день
  • Над чем вы собираетесь работать до конца дня
  • Что, во всяком случае, мешает тебе

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

2. Сотрудничество - это король

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

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

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

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

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

3. Возможные улучшения

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

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

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

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

В конечном счете, красота Agile заключается в его открытости. Организации не обязательно должны придерживаться процессов, продиктованных Scrum или какой-либо другой отдельной методологией. Такие инструменты, как Daily Standups, Planning Poker, Agile Retros, Kanban, - это всего лишь средства для достижения цели, а не сама цель. Чтобы быть по-настоящему гибким, важно сначала понять, почему определенные вещи выполняются именно так. Важно понимать, какие преимущества достигаются за счет внедрения определенных процессов и имеют ли они смысл в вашем конкретном контексте. В конце концов, именно дух Agile способствует успеху команды больше, чем что-либо другое.