Все про Agile

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

ЧТО ТАКОЕ AGILE?

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

ЧТО ТАКОЕ SCRUM?

Scrum - это разновидность AGILE. Это легкая и наиболее широко используемая структура процессов для гибкой разработки.
1. «Структура процесса» - это конкретный набор практик, которым необходимо следовать, чтобы процесс соответствовал структуре. (Например, структура процесса Scrum требует использования циклов разработки, называемых Sprints, а структура XP требует парного программирования и т.д.)
2. «Упрощённость» означает, что непроизводительные затраты процесса сведены к минимуму, чтобы максимально увеличить продуктивное время, доступное для выполнения результативной работы.

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

КАКОВЫ ПРЕИМУЩЕСТВА AGILE?

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

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

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

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

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

КАКОВЫ РОЛИ SCRUM?

В Scrum определены три роли: ScrumMaster, Product Owner и Team (состоящая из членов команды). Люди, которые выполняют эти функции, ежедневно тесно сотрудничают друг с другом в целях обеспечения бесперебойного потока информации и быстрого решения проблем.
ScrumMaster
ScrumMaster (иногда пишется «Scrum Master», хотя официальный термин не имеет места после «Scrum») является хранителем процесса. ScrumMaster отвечает за бесперебойную работу процесса, за устранение препятствий, влияющих на производительность, а также за организацию и проведение важных встреч. Обязанности ScrumMasters включают:
1
Научить владельца продукта, максимизировать окупаемость инвестиций и достичь своих целей через Scrum.
2
Улучшить жизнь команды разработчиков, создавая удобства для творчества и содействуя расширению прав и возможностей.
3
Повысить производительность команды разработчиков любым возможным способом.
4
Усовершенствовать инженерные методики программирования и инструменты, чтобы каждые дополнительные функциональные возможности программного обеспечения можно было поставлять.
5
Держать информацию о ходе работы группы в актуальном состоянии и доступной для всех сторон.
В практическом плане ScrumMaster должен достаточно хорошо понимать Scrum, чтобы обучать и вести наставничество, а также обучать и помогать другим заинтересованным сторонам, участвующим в процессе. ScrumMaster должен поддерживать постоянную осведомленность о статусе проекта (его прогресс на сегодняшний день) относительно ожидаемого прогресса, исследовать и способствовать устранению любых препятствий, сдерживающих прогресс, и в целом быть достаточно гибким, чтобы выявлять и решать любые проблемы, которые возникают любым путем. ScrumMaster должен защищать команду от беспокойства со стороны других людей, выступая в качестве интерфейса между ними. ScrumMaster не назначает задачи членам команды, поскольку назначение задач является обязанностью команды. Общий подход ScrumMaster к команде состоит в том, чтобы поощрять и облегчать их способность принимать решения и решать проблемы, чтобы они могли работать с большей эффективностью и меньшей нуждой в наблюдении. Цель состоит в том, чтобы иметь команду, которая не только уполномочена принимать важные решения, но и делает это хорошо и регулярно.
Владелец продукта
Владелец продукта отвечает за соблюдение требований. Владелец продукта предоставляет «единый источник информации» для команды относительно требований и их запланированного порядка выполнения. На практике владелец продукта является связующим звеном между бизнесом, клиентами и их потребностями, связанными с продуктом, с одной стороны, и командой - с другой. Владелец продукта защищает команду от запросов функций и исправлений ошибок, которые поступают из многих источников, и является единственным контактным лицом по всем вопросам о требованиях к продукту. Владелец продукта работает в тесном сотрудничестве с командой для определения пользовательских и технических требований, документирования необходимых требований по мере необходимости и определения порядка их реализации. Владелец продукта ведет журнал невыполненных работ по продукту (который является хранилищем всей этой информации), поддерживает его в актуальном состоянии и на уровне детализации и качества, необходимом для команды. Владелец продукта также устанавливает график выпуска завершенной работы для клиентов и решает вопрос о том, обладают ли осуществленными функциями и качеством, необходимые продукты для выпуска.

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

КАК РАБОТАТЬ С РАСПРЕДЕЛЕННЫМИ КОМАНДАМИ В AGILE?

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

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

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

ЧТО ИСПОЛЬЗОВАТЬ - SCRUM, KANBAN ИЛИ ДРУГОЙ ВАРИАНТ AGILE?

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

Общее положение важно для ответа. Какие коммерческие потребности бросают вызов вашему бизнесу? Какого размера ваша организация? Как организована ваша компания? Ваши основные команды по продуктам разбросаны по разным географическим точкам? Поэтому реальные коммерческие проблемы, с которыми сталкивается ваш бизнес, и то, как вы реагируете на своих клиентов, зависят от факторов.
Задавая вопрос, что использовать: «Scrum, Kanban или другой разновидности Agile» - это первый шаг и отличное начало. Переход к гибкому подходу разработки - это первый шаг к устойчивости. Как описано выше, гибкость является требованием для будущего успеха, это не новость. Те организации, которые не применяют какую-либо форму гибкой разработки, не будут реагировать на потребности клиентов и рынка и окажутся в значительно менее выгодном положении.

Больше полезных статей в рассылке

Подписка в один клик, никакого спама
Наши контакты
E-mail: info@mymonday.by
sales@mymonday.by
Тел.:
+375 29 5767723