Blog / Programming / Доклад. Agile (вводная часть). Scrum

Доклад. Agile (вводная часть). Scrum

By Pavel Bragin 11,876 August 4, 2016

Category:

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

Agile software development

Scrum

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

История

В феврале 2001 в штате Юта США был выпущен «Манифест гибкой методологии разработки программного обеспечения». Он являлся альтернативой управляемым документацией, «тяжеловесным» практикам разработки программного обеспечения, таким как «Waterfall model», являвшимся золотым стандартом разработки в то время.
Манифест был одобрен и подписан представителями методологий: экстремального программирования, Crystal Clear, DSDM,Feature driven development,Scrum, Adaptive software development, Pragmatic Programming.
Гибкая методология разработки использовалась многими компаниями и до принятия манифеста, однако вхождение Agile-разработки в массы произошло именно после этого события.

Манифест

Люди и взаимодействие важнее процессов и инструментов;
Работающий продукт важнее исчерпывающей документации;
Сотрудничество с заказчиком важнее согласования условий контракта;
Готовность к изменениям важнее следования первоначальному плану;

То есть, не отрицая важности того, что справа,
мы всё-таки больше ценим то, что слева

12 принципов которые разъясняют Agile Manifesto:

Главный приоритет — это удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
частая поставка рабочего программного обеспечения (каждый месяц или неделю, или ещё чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
cоздавайте проект вокруг заинтересованных/мотивированные личностей, Обеспечьте им необходимую среду и необходимую поддержку, и доверяйте им чтобы работа была выполнена.
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
работающее программное обеспечение — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
постоянное внимание улучшению технического мастерства и удобному дизайну;
простота — искусство не делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
Через равные промежутки времени, команда размышляет о том, как стать более эффективными, потом настраивается и регулирует свое поведение соответствующим образом.

Scrum

История

Джефф Сазерленд и Кен Швабер в 1995 году представили Scrum (как системное знание) на конференции OOPSLA в Остине, штат Техас и опубликовали статью “SCRUM Software Development Process”.
Кен и Джефф взяли название “Scrum” из статьи 1986 года «The New Product Development Game» Хиротака Такэути и Икудзиро Нонака.

[row][col_half]Термин «Scrum» взят из регби, проводя некие аналогии между разработкой и командной игрой.
В феврале 2001 года, Джефф и Кен были среди тех 17 лидеров по разработке программного обеспечения, создали Манифест гибкой разработки программного обеспечения.

[/col_half][col_half][/col_half][/row]

Определение

Scrum ( англ. scrum «схватка») — методология управления проектами, применяющаяся при необходимости гибкой разработки. Методология делает акцент на качественном контроле процесса разработки.
Это Фреймворк, используемый для комплексного управления процессом разработки продукта с начала 90-х годов. Скрам не является процессом или техникой разработки продуктов;
Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

Scrum Команда

[row][col_half]

Скрам Команда состоит из:

Владельца Продукта;
Команды Разработки;
Скрам Мастера

[/col_half][col_half][/col_half][/row]

Владелец Продукта

[row][col_half]

Функции:

Четкое определение элементов Беклога Продукта

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

[/col_half][col_half][/col_half][/row]

Беклог Продукта

[row][col_half]

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

[/col_half][col_half][/col_half][/row]Требования никогда не перестают меняться, поэтому Беклог Продукта является живым артефактом.

Команда Разработки

[row][col_half]

Команда Разработки состоит из профессионалов, выполняющих работу по разработке потенциально «Готового» к выпуску Инкремента продукта.
Инкремент создают только члены Команды Разработки.
Команда состоит из не более 8 и не менее 3 человек.

[/col_half][col_half][/col_half][/row]

Команды обладают следующими характеристиками:

Они самоорганизованные. Никто (даже Скрам Мастер) не может указывать Команде, каким образом создавать готовые версии продукта.
Команды Разработки – кросс-функциональны, обладают всеми навыками, необходимыми для разработки Инкремента продукта.
Скрам не признает никаких других должностей в Команде Разработки, кроме как Разработчик, невзирая на вид работы, выполняемой человеком; у этого правила нет исключений.
У Команды Разработки нет подкоманд, которые бы выполняли отдельные функции, как, к примеру, команда тестирования или бизнес-анализа.
Отдельные члены Команды Разработки могут владеть специализированными знаниями в различных областях, однако ответственность лежит на всей Команде Разработки в целом.

[row][col_half]

Скрам Мастер

Скрам Мастер отвечает за то, чтобы Скрам был понят всеми участниками и работал.
Скрам Мастер является слугой и лидером для Скрам Команды. Скрам Мастер также помогает людям, не входящим в состав Скрам Команды понять, какие взаимодействия со Скрам Командой̆ являются полезными, а какие – нет.

Обязанности Скрам Мастера по отношению к Владельцу Продукта:

Находит методы эффективного управления Беклогом Продукта.
Помогает Скрам Команде создавать лаконичные и понятные элементы Беклога Продукта.
Понимает долгосрочное планирование в эмпирической среде.
Убеждается в том, что Владелец Продукта знает, как упорядочить Беклог Продукта, чтобы максимизировать Ценность.
Понимает и практикует гибкие методы разработки и управления.[/col_half][col_half]

Обязанности Скрам Мастера по отношению к команде разработки

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

[/col_half][/row]

Sprint

[row][col_half]

Сердцем Скрама является Спринт длительностью в один месяц или менее , в течение которого создается потенциально готовый̆ к выпуску и использованию продукт (рабочая версия).Следующий̆ Спринт начинается сразу же по окончании предыдущего.Спринты состоят из:

Планирования Спринта;
Ежедневных Скрамов;
Разработки;
Обзора Спринта;
Ретроспективы Спринта.

[/col_half][col_half][/col_half][/row]

Планирование Спринта

[row][col_half]

План действий создается при совместной работе всей Скрам Команды. Планирование Спринта отвечает на следующие вопросы:

Что может быть сделано в Инкременте продукта следующего Спринта?

Как будет выполняться работа, необходимая для создания Инкремента Продукта?

[/col_half][col_half][/col_half][/row]

Ежедневные Скрамы

[row][col_half]

Ежедневные Скрамы – это 15-минутные мероприятия для Команды Разработки с целью синхронизации действий и создания плана работы на ближайшие 24 часа.

Что я сделал с момента прошлой встречи для того, чтобы помочь Команде Разработки достигнуть Цели Спринта?
Что я сделаю сегодня для того, чтобы помочь Команде Разработки достичь Цели Спринта?
Вижу ли я препятствия для себя или Команды Разработки, которые могли бы затруднить достижение Цели Спринта?

[/col_half][col_half][/col_half][/row]

Обзор Спринта

[row][col_half]

Встреча по Обзору Спринта проводится в конце Спринта для проверки Инкремента.
Во время Обзора Спринта Скрам Команда и заинтересованные лица обсуждают выполненную во время Спринта работу.
В Обзор Спринта включены:

Команда Разработки обсуждает, что во время Спринта прошло гладко и с чем возникли трудности, а также то, как она с ними справилась;
Владелец Продукта объясняет, что является “Готовым”, а что нет;
Участники, в том числе Скрам Команда и заинтересованные ключевые лица, приглашенные Владельцем Продукта;
Команда Разработки проводит демонстрацию того, что было сделано, и отвечает на вопросы по Инкременту;
Владелец Продукта обсуждает состояние Беклога Продукта. Он делает предположения касательно возможной даты завершения, принимая во внимание скорость продвижения к дате;
Обзор возможного изменения рынка, потенциального применения продукта и наиболее ценных задач;
Обзор сроков, бюджета, потенциальных возможностей и состояния рынка к моменту ожидаемого релиза продукта

[/col_half][col_half][/col_half][/row]Результатом Обзора Спринта служит пересмотренный Беклог Продукта

Ретроспектива Спринта

[row][col_half]

Проводится в конце спринта.
Члены команды высказывают своё мнение о прошедшем спринте.
Отвечают на два основных вопроса:

Что было сделано хорошо в прошедшем спринте?
Что надо улучшить в следующем?
Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).

[/col_half][col_half][/col_half][/row]

Беклог Спринта

[row][col_half]

Беклог Спринта – это набор Элементов Беклога Продукта, выбранных для выполнения в текущем Спринте, а также план разработки Инкремента продукта и достижения Цели Спринта.
Беклог Спринта – это прогноз Команды Разработки относительно функциональности, которая станет частью следующего Инкремента. Беклог Спринта определяет объем работы, которую Команда Разработки должна выполнить, чтобы превратить Беклог Продукта в “Готовый” Инкремент.

[/col_half][col_half][/col_half][/row]

Определение Готовности

Когда элемент Беклога Продукта или же Инкремент называется «Готовым», все должны понимать, что означает «Готовность».
Имея общее понимание о готовности продукта можно объявить о его готовности и поставить продукт на рынок, не имея противоречий внутри Скрам команды. Владелец будет доволен результатами, а команда удовлетворена разработкой.