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

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]

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

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

Дополнительный материал:

• http://www.scrumguides.org/
• https://habrahabr.ru/company/makeright/blog/297250/
• Addison-Wesley Succeeding with Agile, Software Development Using Scrum (2010).pdf

We are looking forward to meeting you on our website blog.soshace.com