Все про Agile

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

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

Процесс Scrum отличаются от других гибких процессов конкретными концепциями и методами, разделенных на три категории категории: Роли, Артефакты и Временные рамки. Эти и другие термины, используемые в Scrum, определены ниже. Scrum чаще всего используется для управления сложными разработками программного обеспечения и продуктов с использованием итеративных и инкрементных практик. Scrum значительно увеличивает производительность и сокращает время получения выгод по сравнению с классическими «водопадными» процессами. Процессы Scrum позволяют организациям плавно приспосабливаться к быстро меняющимся требованиям и производить продукт, соответствующий меняющимся бизнес-целям. Гибкий процесс Scrum приносит пользу организации, помогая ей:

Преимущества для клиента
Клиенты считают, что создатель является более отзывчивым к запросам на разработку. Ценные функции разрабатываются и доставляются быстрее с короткими циклами, чем с более длинными циклами, предпочитаемыми классическими «водопадными» процессами.

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

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

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

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

ScrumMaster
ScrumMaster (иногда пишется «Scrum Master», хотя официальный термин не имеет места после «Scrum») является хранителем процесса. ScrumMaster отвечает за бесперебойную работу процесса, за устранение препятствий, влияющих на производительность, а также за организацию и проведение важных встреч. Обязанности ScrumMasters включают:

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

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

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

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

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

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

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

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