Ниже приведен отрывок из нашей книги « Скрам: новичок ниндзя» , написанной М. Дэвидом Грином. Копии продаются в магазинах по всему миру, или вы можете купить их в электронном виде здесь .
Если вы взялись за эту книгу, чтобы узнать о применении scrum в своей веб-группе или группе разработчиков мобильных приложений, возможно, вы уже знакомы с терминами scrum и agile. Возможно, вы получили эту книгу от своей компании, или, возможно, вам было поручено внедрить гибкий процесс в вашей собственной организации. Независимо от причины, всегда полезно начать с четкого общего определения соответствующих терминов.
Scrum — это один из нескольких методов управления организациями по разработке продуктов, относящихся к широкой категории гибкой разработки программного обеспечения. Гибкие подходы предназначены для поддержки итеративных, гибких и устойчивых методов управления организацией по разработке продуктов.
Среди различных гибких методов scrum особенно хорошо подходит для организаций, разрабатывающих такие продукты, как веб-сайты и мобильное программное обеспечение. Сосредоточение внимания на разработке связных, модульных, измеримых характеристик, которые могут быть оценены относительно, легко отслеживаться и, возможно, потребуется быстро адаптироваться к изменяющимся условиям рынка, делает схватку особенно подходящей для таких проектов.
Scrum рекомендует командам работать в течение ограниченного периода времени над четко определенным набором функций, понимая, что следующий набор функций, над которыми их могут попросить работать, может быть непредсказуемым из-за изменений на рынке, отзывов клиентов или любое количество факторов. Scrum позволяет командам развить улучшенную способность оценивать, сколько усилий потребуется для относительного создания новой функции, основываясь на работе, связанной с функциями, которые они разработали ранее. А схватка создает для команды возможность размышлять над процессом и регулярно его улучшать, привнося в игру все отзывы.
Предупреждение: не путайте простое применение терминов Scrum с фактическим использованием Scrum
В неорганизованных организациях, стремящихся замаскировать свои проблемы с процессами, знакомый анти-паттерн использует терминологию scrum в качестве системы маркировки поверх своих методов и инструментов для водопада. Это может создать путаницу и даже негативные ассоциации среди людей, которые видели, что эти термины использовались неправильно, и которые ошибочно полагают, что видели схватку в действии.
Изучая эту книгу, вы узнаете больше о том, как функционирует скрам. Вы познакомитесь со всеми аспектами схватки, включая ее ритуалы, артефакты и роли, которые он создает для людей в организации. Мы собираемся познакомить вас с командой людей, работающих в scrum-среде, и покажем вам, как они приняли scrum в первую очередь и как они адаптировались к ней.
Прежде чем мы доберемся до этого, стоит уделить время тому, чтобы поместить схватку в исторический контекст. В конце концов, scrum — не единственный способ организовать разработку продукта. Scrum появился как раз в то время, когда веб-разработка возникла на инженерном уровне, и он процветал, когда мобильные технологии стали частью нашей повседневной жизни. Если вы подумаете о том, как работает схватка, откуда она взялась и как мы ее применяем, я думаю, вы поймете, что для этого может быть причина.
Примечание: нечетный словарь Scrum
Лексика схватки отличительна и может показаться странной. Это намеренно. Scrum использует такие термины, как ритуал, артефакт и история, чтобы прояснить, что эти концепции отличаются от связанных идей, которые могут встречаться в других подходах к управлению проектами.
Краткая история Scrum
Первоначальная концепция scrum пришла из Японии и была представлена в 1986 году в рамках игры по разработке новых продуктов Хиротаки Такеучи и Икудзиро Нонаки. Они применили концепцию схватки, взятой из регби командной игры, чтобы описать межфункциональную организацию команды, основанную на продвижении вперед в многоуровневом подходе.
Их концепции были кодифицированы как методология Scrum на совместной презентации в 1995 году Кена Швабера и Джеффа Сазерленда, основанной на их личном опыте применения концепций в их собственных организациях. Эта работа вдохновила книгу 2001 года Agile Software Development with Scrum , написанную Швабером и Майком Бидлом.
В то время наиболее распространенным подходом к разработке программного обеспечения была модель водопада . В рамках модели «водопад» разработка продукта происходит поэтапно, последовательно от требований до проектирования, реализации и выпуска. До 1990-х годов большая часть разработки программного обеспечения была ориентирована на поставку упакованного программного обеспечения для настольных компьютеров. Такие продукты имели длительные циклы разработки и выпуска. Хотя водопад хорошо подходит для продуктов с долгой траекторией развития, он не очень хорошо адаптируется к ситуациям, когда продукт должен постоянно меняться в ответ на меняющиеся условия.
В середине-конце 1990-х годов появились новые модели публикации с использованием электронных средств массовой информации и Интернета. Для их поддержки организациям, занимающимся разработкой программного обеспечения, необходимо было обеспечить большую гибкость, чтобы адаптироваться к изменяющимся браузерам, сжатым срокам мультимедиа и множеству платформ с различными требованиями. Вскоре после этого разработка больших монолитных программных приложений, которые жили на настольных компьютерах, уступила место более мелким, более гибким приложениям, которые доставлялись через мобильные устройства. Для их разработки необходим другой подход.
Не случайно гибкие подходы стали кодифицированными и быстро стали популярными, так как рынок переходил с настольного программного обеспечения на веб и мобильное программное обеспечение.
Сравнивая Scrum и водопад
Медленный цикл развития водопада все еще может быть уместным в мире разработки аппаратного обеспечения или даже в играх. Эти отрасли зависят от длинных, стабильных рынков, где многие решения либо повторяются, ограничены внешними ресурсами, либо их необходимо принимать заранее, из-за огромных масштабов и затрат на развитие.
Интернет и мобильные технологии движутся слишком быстро для подхода с водопадом. К тому времени, как вы закончите разработку решения одной проблемы и сбор отзывов от пользователей, технология уже перешла на новый уровень, и у вас может появиться очень небольшое окно возможностей извлечь выгоду из вашего решения.
При использовании подхода «водопад» идеи о том, что необходимо разрабатывать, могут исходить от клиентов, от руководителей, от исследований рынка или от воображения людей, принимающих решения и определяющих бюджеты. Эти идеи передаются менеджерам по продукту, которые создают длинную дорожную карту продукта. Они устанавливают и собирают требования, выписывают классические документы с требованиями к продукту, а затем передают эти требования дизайнерам для создания прототипов в виде каркасов и макетов. Эти прототипы передаются инженерной команде, которая реализует эти идеи и производит продукт, который в конечном итоге может быть выпущен на рынок. Пока этот продукт не будет выпущен и передан в руки клиентов, никакой обратной связи в процессе не создается.
В гибкой организации руководящие цели и ключевые показатели эффективности направляют процесс, но команда сама справляется с этими задачами. Владелец продукта поддерживает общее видение и работает с мастером схватки, чтобы убедиться, что все в команде четко понимают цели и способы их измерения. Вклад дизайнеров и инженеров на каждом этапе этого процесса. Функции задуманы и сформулированы в истории, когда команда готова работать над ними. Ни одна идея не заперта в статическую временную шкалу продукта
Для компании, которая нанимает собственную команду дизайнеров и инженеров, ценность состоит в том, чтобы эти люди могли донести свое дизайнерское мышление и свои текущие технические знания на пользу собственным целям организации. Дизайнеры должны оценивать пользовательский опыт и находить лучшие решения проблем реальных клиентов, а не украшать плохие идеи, чтобы сделать их функциональными.
Вовлечение инженеров в разработку идей позволяет им использовать новейшие технологии как можно раньше, поскольку они в лучшем положении, чтобы знать, что технически возможно. Чем раньше дизайнеры и инженеры будут вовлечены в процесс планирования, тем более гибким будет развитие.
Scrum позволяет использовать все ресурсы команды, когда и где они могут принести наибольшую пользу, и работать вместе устойчивым и продуктивным образом. Вместо того, чтобы ждать завершения полного цикла, прежде чем какие-либо данные могут быть возвращены в систему, на каждом этапе генерируются идеи, которые поощряются всплывать на поверхность в конце каждого спринта. Полное участие команды на каждом этапе процесса позволяет этим идеям соответствовать целям и поддерживать видение организации.
Предупреждение: смешивание схватки с водопадом
В то время как некоторые организации могут утверждать, что следуют за схватками, многие из них фактически следуют измененному подходу водопада, используя методы схватки только для развития. Остальная часть организации структурируется вокруг долгоживущих временных рамок продукта со статическими целями. Хотя это может быть улучшение по сравнению с чистым водопадом, поскольку оно позволяет инженерам итерировать и улучшать свой процесс, оно не в полной мере использует потенциал схватки. Изоляция разборок внутри цикла разработки без привлечения знаний команды к процессу планирования и тестирования рынка — пустая трата ресурсов и упущенная возможность.
Смешивать небольшую разборку с организацией водопада, как правило, не очень хорошая идея, поскольку она может привлечь внимание к фундаментальным конфликтам между различными подходами и вызвать трения.