Зарождение методологии Agile началось во второй половине 20 столетия. Однако все согласны в том, что укоренение Agile началось с Манифеста гибкой разработки программного обеспечения, также известного как манифест Agile.
Впервые манифест Agile был издан в феврале 2001 года для создания нового способа управления разработкой программного обеспечения.
Стало понятно, что разделение проекта на короткие итерации (повторение действий) позволит ускорить разработку и тестирование. В конце каждой итерации (спринта) следует получать отзывы клиента (ретроспективы) и вносить изменения. Изначально манифест Agile создавался, как решение для управления разработкой программного обеспечения. Но с тех пор методология Agile расширилась и теперь включает различные сферы деятельности.
Scrum впервые применили в 1993 году в Easel Corporation. Компании требовалось разработать программный продукт и полностью изменить действующее предложение в рекордный срок — 6 месяцев. Эксперимент в Easel Corporation оказался успешным. В наши дни Scrum применяется в таких известных организациях, как IBM, Systematic, Trifork.
Предлагаем сначала определить, что же такое Agile и Scrum. Начнем с Agile.
Подход Agile был разработан как гибкий и эффективный способ вывода продукции на рынок. Английское слово agile означает способность быстро и легко двигаться. Agile позволяет командам проектов легче и быстрее адаптироваться к изменениям.
Согласно этой методологии, для организации проектов используются четыре ценности и 12 принципов.
Четыре ценности:
· Люди и взаимодействие важнее процессов и инструментов.
· Работающий продукт важнее исчерпывающей документации.
· Сотрудничество с заказчиком важнее согласования условий контракта.
· Готовность к изменениям важнее следования первоначальному плану.
Двенадцать принципов:
· Наивысшим приоритетом для нас является удовлетворение потребностей заказчика благодаря регулярной и ранней поставке ценного программного обеспечения.
· Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
· Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
· На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
· Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
· Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
· Работающий продукт — основной показатель прогресса.
· Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно.
· Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
· Простота — искусство минимизации лишней работы — крайне необходима.
· Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
· Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Еще одним важным моментом Agile-методологии является разделение всего объема проекта на несколько более мелких составных частей. Такой подход упрощает процесс разработки, а отдельные группы команды могут фокусироваться на своей конкретной задаче.
Scrum является методикой, которая помогает командам вести совместную работу. Команда сотрудников компании должна извлекать уроки из полученного опыта, осваивать принципы самоорганизации, работая над решением проблемы, и анализировать свои успехи и провалы, чтобы постоянно совершенствоваться. Scrum содействует этому
Также Scrum определяют, как минимально необходимый набор мероприятий, артефактов, ролей, на которых строится процесс Scrum-разработки, позволяющий за фиксированные небольшие промежутки времени, называемые спринтами, предоставлять конечному пользователю продукт с новыми бизнес-возможностями, для которых определён наибольший приоритет.
Надо сказать, Scrum и Agile часто путают, потому что Scrum строится вокруг идеи о постоянном совершенствовании, которое является главным принципом Agile. В основе методики Scrum лежит постоянное обучение и адаптация к изменчивым факторам. То есть, команда не знает всего в начале проекта, но будет развиваться, извлекая уроки из опыта.
Отметим важный момент: без тестирования и оглядки на первичные цели проекта – Scrum будет лишь тратить деньги, а Agile может привести к расфокусировке.
Как и Agile, Scrum обычно используется в сфере разработки программного обеспечения, но может быть полезной и в любых других проектах, в том числе и в маркетинговом сопровождении.
Определимся с терминологией.
Спринт — промежуток времени, достаточный для выполнения запланированной совокупности операций Scrum, целью которой является создание инкремента (операция во многих языках программирования, увеличивающая значение переменной) бизнес-продукта.
То, что мы создаем, при решении задачи, называется артефактом. Их 3:
1. Product backlog (бэклог продукта). Это главный список задач для выполнения командой. Его содержимое может меняться.
2. Sprint backlog (журнал пожеланий спринта). Это список рабочих задач, отобранных командой для реализации в текущем цикле. Задачи визуализируются путем создания доски спринта. На ней отображаются все элементы, которые нужно сделать, работа над которыми ведётся в данный момент и которые уже завершены в рамках текущего Спринта. Однако, внедрять Scrum ради красивых листочков на канбан-доске бессмысленно. Сопровождение методологии не должно понижать эффективность реализации проекта и мешать достижению первичных целей.
3. Sprint goal (цель спринта), инкремент. Это готовый к использованию конечный продукт по итогам спринта.
Какие должны быть роли в команде для успешного применения Scrum?
1. Владелец продукта. Это тот человек, который разрабатывает стратегию по развитию, расставляет приоритеты между рабочими задачами, составляет бэклог продукта и управляет им.
2. Scrum-мастер. Он следит за применением принципов Scrum в своих командах. То есть, это специалист, который знает о Scrum все. Он занимается обучением команды тонкостям Scrum и отвечает за оптимизацию применения этой практики.
3. Команда разработчиков Scrum. Это люди, которые выполняют основную работу. Scrum-команды составляют план на каждый спринт, прогнозируют объем работы, который способны выполнить за итерацию.
Наши советы по внедрению и использованию Agile и Scrum:
· Необходимо отделять реализацию новых задач от поддержки. Одни и те же специалисты не могут заниматься внештатными ситуациями и реализовывать новые задачи в спринте одновременно.
· Руководствоваться принципом: в маленьких командах гибкость важнее доктрин. Большинство Scrum-евангелистов верят, что набор задач в итерации статичен. И в этом есть свои плюсы. Однако, по большей части эти плюсы актуальны для больших команд.
· Комбинировать и совмещать - хорошо и правильно. Задачи внутри Scrum-итераций тоже могут быть разбиты на каскад подзадач. Таким образом, чем более грамотно сделана декомпозиция - тем эффективнее идет реализация проекта.
· В проекте не должно быть незапротоколированных изменений, незадокументированной ретроспективы, любой информации, оставшейся «на словах». На дистанции это сводит к нулю эффективность любой методологии.
Чем же грозит слепое следование этим методикам?
Начнем с Agile:
· Для некоторых программных продуктов разработчики не могут в полной мере количественно оценить требуемые усилия. Команды, не имеющие опыта гибкой разработки, боятся этих неизвестных. Этот страх приводит к разочарованию, плохим практикам и часто к плохим решениям.
· Постоянная обратная связь может приводить к тому, что все время будет переноситься и дедлайн проекта, тем самым создавая угрозу бесконечно продолжающейся работы. Если заказчик видит только результаты, но не имеет представления об усилиях, потребовавшихся для их достижения, он будет все время требовать улучшений.
· Необходимость в частых встречах может понизить концентрацию команды. Встречи, конечно, способствуют повышению эффективности работы, но все же постоянное отвлечение членов команды может сказаться на процессе отрицательно, ведь внимание людей систематически уходит в сторону от решаемых задач.
· Слепое следование методике при отсутствии необходимых знаний и инструментов заведомо приводит к отрицательному результату.
Что можно сказать о Scrum?
· Scrum не подразумевает наличие фиксированного бюджета и технического задания. Это может привести существенным трудностям при заключении договора с заказчиком.
· Методология допускает множество исключений. Поэтому, по мнению экспертов, выбор и использование Scrum при работе, например, с государственными заказами (где есть заранее фиксированный бюджет, план работы), может привести плохому результату.
Agile и Scrum являются очень интересными методиками управления проектами. Вместе с тем, они достаточно сложны в своем применении. Рекомендуем с умом подходить к внедрению Agile и Scrum, предварительно изучая материал и постепенно применяя его в ваших проектах.
