Скрам (разработка программного обеспечения)

Scrum — это гибкая среда командного сотрудничества, обычно используемая в разработке программного обеспечения и других отраслях.

Scrum предписывает командам разбивать работу на цели , которые необходимо выполнить в рамках ограниченных по времени итераций, называемых спринтами . Каждый спринт длится не более одного месяца и обычно длится две недели. Скрам-команда оценивает прогресс на ограниченных по времени стоячих совещаниях продолжительностью до 15 минут, называемых ежедневными скрамами . В конце спринта команда проводит еще две встречи: одну проверку спринта, чтобы продемонстрировать работу заинтересованным сторонам и получить обратную связь, и одну внутреннюю ретроспективу спринта . Человека, отвечающего за Scrum-команду, обычно называют Scrum-мастером . ^{[ 2 ]}

Подход Scrum к разработке продуктов предполагает выведение полномочий по принятию решений на операционный уровень. ^{[ 3 ]} В отличие от последовательного подхода к разработке продукта, Scrum представляет собой итеративную и поэтапную структуру разработки продукта. ^{[ 4 ]} Scrum обеспечивает непрерывную обратную связь и гибкость, требуя от команд самоорганизации, поощряя физическое совместное размещение или тесное онлайн-сотрудничество, а также требуя частого общения между всеми членами команды. Гибкий подход Scrum частично основан на идее изменчивости требований: заинтересованные стороны будут менять свои требования по мере развития проекта. ^{[ 5 ]}

История

Термин « скрам» в разработке программного обеспечения использовался в , опубликованной в Harvard Business Review в 1986 году под названием «Игра по разработке новых новых продуктов» статье Хиротаки Такеучи и Икуджиро Нонака . Основываясь на тематических исследованиях производственных фирм в автомобильной, копировальной и принтерной отраслях , авторы изложили новый подход к разработке продуктов для повышения скорости и гибкости. Они назвали это подходом к регби , поскольку в этом процессе участвует одна межфункциональная команда, действующая на нескольких перекрывающихся этапах, на которых команда «пытается пройти дистанцию как единое целое, передавая мяч вперед и назад». ^{[ 6 ]} Позже авторы разработали Scrum в своей книге « Компания, создающая знания» . ^{[ 7 ]}

В начале 1990-х годов Кен Швабер использовал в своей компании метод Advanced Development Methods, который впоследствии стал Scrum. Джефф Сазерленд , Джон Скамниоталес и Джефф МакКенна разработали аналогичный подход в Easel Corporation, ссылаясь на подход с термином Scrum . ^{[ 8 ]} Позже Сазерленд и Швабер работали вместе, чтобы объединить свои идеи в единую структуру, официально известную как Scrum. Швабер и Сазерленд протестировали Scrum и постоянно совершенствовали его, что привело к публикации исследовательской работы в 1995 году: ^{[ 9 ]} и Манифест гибкой разработки программного обеспечения в 2001 году. ^{[ 10 ]} Швабер также сотрудничал с Бабатунде Огуннаике из исследовательской станции DuPont и Университетом штата Делавэр для разработки Scrum. Огуннаике считал, что проекты разработки программного обеспечения часто могут потерпеть неудачу при изменении первоначальных условий, если управление продуктом не основано на эмпирической практике. ^{[ 3 ]}

В 2002 году Швабер вместе с другими основал Scrum Alliance и учредил серию аккредитаций Certified Scrum . ^{[ 11 ]} Швабер покинул Scrum Alliance в конце 2009 года и впоследствии основал Scrum.org, который курирует параллельную серию аккредитации Professional Scrum . ^{[ 12 ]} С 2009 года существует общедоступный документ под названием The Scrum Guide. ^{[ 13 ]} был опубликован и обновлен Швабером и Сазерлендом. Он пересматривался шесть раз, текущая версия — ноябрь 2020 года.

Скрам-команда

Скрам-команда состоит как минимум из трех категорий людей: владелец продукта, разработчики и скрам-мастер. Владелец продукта поддерживает связь с заинтересованными сторонами, теми, кто заинтересован в результате проекта, чтобы сообщить разработчикам о задачах и ожиданиях. ^{[ 14 ]} Разработчики в Scrum-команде самостоятельно организуют работу при содействии Scrum-мастера. ^{[ 15 ]}

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

В каждой scrum-команде есть один владелец продукта. ^{[ 16 ]} Владелец продукта сосредотачивается на бизнес-стороне разработки продукта и тратит большую часть времени на поддержание связи с заинтересованными сторонами и командой. продукта Эта роль предназначена в первую очередь для представления заинтересованных сторон , голоса клиента или желаний комитета и несет ответственность за достижение бизнес-результатов. ^{[ 17 ]}^{[ 18 ]}^{[ 19 ]}^{[ 20 ]} Владельцы продукта управляют резервом продуктов и несут ответственность за максимизацию ценности, которую приносит команда. ^{[ 18 ]} Они не диктуют технические решения команде, а вместо этого могут попытаться достичь консенсуса среди членов команды. ^{[ 21 ]}^{[ 22 ]}

Являясь основным связующим звеном Scrum-команды с заинтересованными сторонами, владельцы продуктов отвечают за передачу объявлений, определений и прогресса проекта, RIDA ( риски , препятствия, зависимости и предположения), финансирование и планирование изменений, резерв продукта и управление проектом, среди прочего. другие обязанности. ^{[ 23 ]}^{[ нужен лучший источник ]} Владельцы продукта также могут при необходимости отменить спринт без участия членов команды. ^{[ 13 ]}

Разработчики

В Scrum термин «разработчик» или «член команды» относится к любому, кто играет роль в разработке и поддержке продукта и может включать в себя исследователей, архитекторов , дизайнеров, программистов и т. д. ^{[ 13 ]}^{[ 24 ]}

Скрам-мастер

Scrum координирует Scrum-мастер, роль которого заключается в обучении и обучении команд теории и практике Scrum. ^{[ 1 ]} Роли и обязанности Scrum-мастера отличаются от традиционных руководителей команд или менеджеров проектов . Некоторые обязанности scrum-мастера включают коучинг, постановку целей, решение проблем, надзор, планирование, управление отставанием и содействие общению. ^{[ 1 ]} С другой стороны, традиционные менеджеры проектов часто имеют обязанности по управлению людьми , чего нет у scrum-мастера. Скрам-команды не привлекают менеджеров проектов, чтобы максимизировать самоорганизацию разработчиков. ^{[ 25 ]}

Рабочий процесс

Спринт

Спринт (также известный как итерация , временной интервал или дизайн-спринт ) — это фиксированный период времени, в течение которого члены команды работают над определенной целью. Каждый спринт обычно длится от одной недели до одного месяца, чаще всего две недели. ^{[ 3 ]} развивался Результатом спринта является функциональный результат или продукт, который постепенно . Если спринт аварийно завершается, следующим шагом является планирование нового спринта, в ходе которого проверяется причина прекращения.

Каждый спринт начинается с мероприятия по планированию спринта, в котором определяется цель спринта. Приоритеты запланированных спринтов выбираются из бэклога. Каждый спринт заканчивается двумя событиями: ^{[ 8 ]}

Обзор спринта (прогресс демонстрируется заинтересованным сторонам для получения их отзывов)
Ретроспектива спринта (выявление уроков и улучшений для следующих спринтов)

Рекомендуемая максимальная продолжительность планирования спринта — восемь часов для четырехнедельного спринта. ^{[ 13 ]}

Ежедневная схватка

Каждый день во время спринта разработчики проводят ежедневную схватку (часто проводимую стоя ) с конкретными инструкциями, которую может проводить скрам-мастер. ^{[ 3 ]}^{[ 26 ]} Ежедневные скрам-встречи должны длиться менее 15 минут и проводиться ежедневно в одно и то же время и в одном и том же месте. Цель встречи — объявить о прогрессе, достигнутом в достижении цели спринта, и проблемах, которые могут помешать достижению цели, не вдаваясь в детальное обсуждение. По окончании отдельные участники могут пойти на «секционное заседание» или «после вечеринки» для расширенного обсуждения и сотрудничества. ^{[ 27 ]} Скрам-мастера несут ответственность за то, чтобы члены команды эффективно использовали ежедневные схватки, или, если члены команды не могут их использовать, за предоставление альтернатив для достижения аналогичных результатов. ^{[ 28 ]}^{[ 29 ]}

Пост-спринтерские мероприятия

Обзор спринта, проводимый в конце спринта, представляет собой встречу, на которой команда делится проделанной работой с заинтересованными сторонами и поддерживает с ними связь по вопросам обратной связи, ожиданий и предстоящих планов. Во время обзора спринта заинтересованным сторонам демонстрируются завершенные результаты. Рекомендуемая продолжительность обзора спринта — один час в неделю спринта. ^{[ 13 ]}

Ретроспектива спринта — это отдельная встреча, которая позволяет членам команды внутренне проанализировать сильные и слабые стороны спринта, будущие области улучшения и по постоянному улучшению процессов . действия ^{[ 30 ]}

Уточнение бэклога

Уточнение бэклога — это процесс, посредством которого члены команды пересматривают и определяют приоритетность бэклога для будущих спринтов. ^{[ 31 ]} Это можно сделать как отдельный этап перед началом нового спринта или как непрерывный процесс, над которым члены команды работают самостоятельно. Уточнение бэклога может включать в себя разбиение крупных задач на более мелкие и более четкие, уточнение критериев успеха, а также пересмотр меняющихся приоритетов и результатов.

Артефакты

Артефакты — это средство, с помощью которого Scrum-команды управляют разработкой продукта, документируя работу, проделанную в рамках проекта. Основными используемыми артефактами Scrum являются журнал невыполненной работы по продукту, журнал невыполненной работы по спринту и инкремент.

Отставание продукта

Журнал невыполненных работ по продукту представляет собой разбивку работы, которую необходимо выполнить, и содержит упорядоченный список требований к продукту (таких как функции , исправления ошибок и нефункциональные требования ), которые команда поддерживает для продукта . Порядок бэклога продукта соответствует срочности задачи. Общие форматы элементов невыполненной работы включают пользовательские истории и варианты использования . ^{[ 25 ]} владельца продукта Журнал невыполненных работ по продукту также может содержать оценку бизнес-ценности и оценку командой усилий или сложности продукта, которые можно выразить в пунктах истории с использованием округленной шкалы Фибоначчи . Эти оценки призваны помочь владельцу продукта оценить сроки и могут повлиять на порядок элементов бэклога продукта. ^{[ 32 ]}

Владелец продукта поддерживает элементы невыполненной работы по продукту и определяет их приоритетность на основе таких соображений, как риск, ценность для бизнеса, зависимости, размер и сроки. Высокоприоритетные элементы в верхней части невыполненной работы разбиваются на более мелкие детали, над которыми могут работать разработчики, тогда как задачи, расположенные ниже в невыполненной работе, могут быть более расплывчатыми. ^{[ 3 ]}

Отставание в спринте

Бэклог спринта — это подмножество элементов из бэклога продукта, предназначенных для разработчиков, которые должны решить их в конкретном спринте. ^{[ 33 ]} Разработчики заполняют этот бэклог задачами, которые они считают подходящими для заполнения спринта, используя прошлую производительность для оценки своих возможностей для каждого спринта. Scrum-подход включает в себя задачи в бэклоге спринта, которые не назначаются разработчикам каким-либо конкретным человеком или лидером. Члены команды самоорганизуются, выполняя работу по мере необходимости в соответствии с приоритетом невыполненной работы, а также своими собственными возможностями и возможностями. ^{[ 34 ]}

Приращение

Инкремент — это потенциально высвобождаемый результат спринта, который соответствует цели спринта. Он формируется из всех выполненных элементов бэклога спринта, интегрированных с работой всех предыдущих спринтов.

Другие артефакты

Диаграмма выгорания

Пример диаграммы сгорания для завершенного спринта, показывающей оставшиеся усилия в конце каждого дня.

Часто используемая в scrum диаграмма сгорания — это общедоступная диаграмма, показывающая оставшуюся работу. ^{[ 35 ]} Он обеспечивает быструю визуализацию для справки. Горизонтальная ось диаграммы выработки показывает оставшееся количество дней, а вертикальная ось — объем работы, оставшейся каждый день. Во время планирования спринта строится идеальная диаграмма сгорания. Затем во время спринта разработчики обновляют диаграмму оставшейся работы.

Диаграмма выгорания релиза

Пример диаграммы сгорания релиза, показывающий завершенный объем каждого спринта (MVP = минимально жизнеспособный продукт )

Обновляемая в конце каждого спринта диаграмма выработки релизов показывает прогресс в достижении объема прогноза. Горизонтальная ось диаграммы выгорания релиза показывает спринты в релизе, а вертикальная ось показывает объём работы, выполненной в конце каждого спринта.

Скорость

Некоторые менеджеры проектов полагают, что общие усилия команды за один спринт можно определить путем оценки работы, выполненной за последний спринт. Сбор исторических данных о « скорости » является руководством, помогающим команде понять свои возможности.

Ограничения

Некоторые утверждают, что скрам-мероприятия, такие как ежедневные схватки и обзоры схваток, снижают производительность и приводят к потере времени, которое лучше было бы потратить на реальные продуктивные задачи. ^{[ 36 ]}^{[ 37 ]} Также замечено, что Scrum создает трудности для команд, работающих неполный рабочий день или географически удаленных команд; те, у которых есть узкоспециализированные члены, которым лучше работать самостоятельно или в рабочих группах; и те, которые непригодны для инкрементального тестирования и тестирования при разработке . ^{[ 38 ]}^{[ 39 ]}

Адаптации

Скрам часто адаптируется или адаптируется в разных контекстах для достижения разных целей. ^{[ 40 ]} Распространенным подходом к адаптации Scrum является сочетание Scrum с другими методологиями разработки программного обеспечения, поскольку Scrum не охватывает весь жизненный цикл разработки продукта . ^{[ 41 ]} Различные специалисты по Scrum также предложили более подробные методы применения или адаптации Scrum к конкретным проблемам или организациям. Многие называют эти методы «шаблонами», что аналогично использованию шаблонов проектирования в архитектуре и программном обеспечении. ^{[ 42 ]}^{[ 43 ]}

Разрушение

Scrumban — это модель производства программного обеспечения, основанная на Scrum и Kanban . Чтобы проиллюстрировать каждый этап работы, команды, работающие в одном помещении, часто используют стикеры или большую доску. ^{[ 44 ]} Модели Канбан позволяют команде визуализировать этапы работы и ограничения. ^{[ 45 ]}

Скрам из схваток

Скрам из схваток — это метод управления схваткой в масштабе для нескольких команд, координирующих работу над одним и тем же продуктом. В ежедневных скрам-совещаниях Scrum-of-Scrum участвуют представители, выбранные из каждой отдельной команды, которые могут быть либо разработчиком, либо скрам-мастером. В качестве инструмента координации Scrum Scrums позволяет командам коллективно работать над общекомандными рисками, препятствиями, зависимостями и предположениями (RIDA), которые можно отслеживать в собственном журнале невыполненных работ. ^{[ 46 ]}^{[ 47 ]}

Масштабная схватка

Крупномасштабная схватка — это среда разработки продуктов, которая масштабирует схватку с помощью различных правил и рекомендаций, разработанная Басом Воддом и Крейгом Ларманом . ^{[ 48 ]}^{[ 49 ]} Структура имеет два уровня: первый уровень, рассчитанный на восемь команд; и второй уровень, известный как «LeSS Huge», на котором могут работать сотни разработчиков. ^{[ 50 ]}

Критика

Систематический обзор показал, что «распределенный Scrum не оказывает никакого влияния, ни положительного, ни отрицательного на общий успех проекта» в распределенной разработке программного обеспечения. ^{[ 51 ]}

Мартин Фаулер , один из авторов «Манифеста гибкой разработки программного обеспечения », раскритиковал то, что он называет «фальшивой гибкой» практикой, которая «игнорирует ценности и принципы гибкой разработки». ^{[ 52 ]} и «гибкий промышленный комплекс, навязывающий людям методы», что противоречит принципу Agile, согласно которому «люди и взаимодействие важнее процессов и инструментов». ^{[ 10 ]} и позволяя людям, выполняющим работу, решать, как она выполняется, изменяя процессы в соответствии с их потребностями.

В сентябре 2016 года Рон Джеффрис, подписавший Agile-манифест , ^{[ 10 ]} описал то, что он назвал «Темным Скрамом», сказав, что «Скрам может быть очень небезопасным для программистов». ^{[ 53 ]}

См. также

Цитаты

^ Перейти обратно: ^а ^б ^с Кен Швабер ; Джефф Сазерленд . «Руководство по Scrum» (PDF) . Скрам.орг . Проверено 15 июня 2023 г.
^ «Что такое Scrum Master? Все, что вам нужно знать – советник Forbes» . www.forbes.com . Проверено 16 ноября 2023 г.
^ Перейти обратно: ^а ^б ^с ^д ^и Швабер, Кен (1 февраля 2004 г.). Гибкое управление проектами с помощью Scrum . Майкрософт Пресс . ISBN 978-0-7356-1993-7 .
^ «Что такое Скрам?» . Что такое Скрам? Agile Framework для реализации сложных проектов — Scrum Alliance . Скрам Альянс . Проверено 24 февраля 2016 г.
^ Дж. Генри и С. Генри. Количественная оценка процесса сопровождения программного обеспечения и волатильности требований. В Proc. конференции ACM по информатике, страницы 346–351, 1993 г.
^ Такеучи, Хиротака; Нонака, Икудзиро (1 января 1986 г.). «Игра по разработке новых продуктов» . Гарвардское деловое обозрение . Проверено 9 июня 2010 г. Перемещение Scrum вниз
^ Компания, создающая знания . Издательство Оксфордского университета. 1995. с. 3. ISBN 978-0-19-976233-0 . Проверено 12 марта 2013 г.
^ Перейти обратно: ^а ^б Сазерленд, Джефф (октябрь 2004 г.). «Гибкая разработка: уроки, извлеченные из первого Scrum» . Архивировано из оригинала (PDF) 30 июня 2014 года . Проверено 26 сентября 2008 г.
^ Сазерленд, Джеффри Виктор ; Швабер, Кен (1995). Проектирование и реализация бизнес-объектов: материалы семинара OOPSLA '95 . Мичиганский университет . п. 118. ИСБН 978-3-540-76096-2 .
^ Перейти обратно: ^а ^б ^с «Манифест гибкой разработки программного обеспечения» . Проверено 17 октября 2019 г.
^ Максимини, Доминик (8 января 2015 г.). Скрам-культура: внедрение гибких методов в организациях . Менеджмент для профессионалов. Чам: Springer (опубликовано в 2015 г.). п. 26. ISBN 978-3-319-11827-7 . Проверено 25 августа 2016 г. Кен Швабер и Джефф Сазерленд впервые представили Scrum на конференции OOPSLA в Остине, штат Техас, в 1995 году. [...] В 2001 году была опубликована первая книга о Scrum. [...] Год спустя (2002 г.) Кен основал Scrum Alliance, целью которого является обеспечение обучения и сертификации Scrum во всем мире.
^ "Дом" . Скрам.орг . Проверено 6 января 2020 г.
^ Перейти обратно: ^а ^б ^с ^д ^и Сазерленд, Джефф ; Швабер, Кен (2013). «Скрам-руководства» . ScrumGuides.org . Проверено 15 июня 2023 г.
^ Моррис, Дэвид (2017). Scrum: идеальная основа для гибких проектов . В простых шагах. стр. 178–179. ISBN 978-1-84078-731-3 . OCLC 951453155 .
^ Кобб, Чарльз Г. (2015). Руководство для менеджера проекта по освоению Agile: принципы и практики адаптивного подхода . Хобокен, Нью-Джерси: John Wiley & Sons. п. 37. ИСБН 978-1-118-99104-6 .
^ Кон, Майк (2010). Как добиться успеха в Agile: разработка программного обеспечения с использованием Scrum . Река Аппер-Сэддл, Нью-Джерси: Аддисон-Уэсли. ISBN 978-0-321-57936-2 .
^ Рубин, Кеннет (2013), Essential Scrum. Практическое руководство по самому популярному гибкому процессу , Аддисон-Уэсли, с. 173, ISBN 978-0-13-704329-3
^ Перейти обратно: ^а ^б МакГрил, Дон; Йохам, Ральф (4 июня 2018 г.). Профессиональный владелец продукта: использование Scrum как конкурентное преимущество . Аддисон-Уэсли Профессионал. ISBN 978-0-13-468665-3 .
^ Пихлер, Роман (11 марта 2010 г.). Гибкое управление продуктами с помощью Scrum: создание продуктов, которые нравятся клиентам . Аддисон-Уэсли Профессионал. ISBN 978-0-321-68413-4 .
^ Эмблер, Скотт. «Роль владельца продукта: доверенное лицо заинтересованных сторон для Agile-команд» . www.agilemodeling.com . Проверено 22 июля 2016 г. [...] на практике оказывается, что у этой роли есть два важнейших аспекта: во-первых, как доверенное лицо заинтересованных сторон в команде разработчиков, а во-вторых, как представитель команды проекта перед всем сообществом заинтересованных сторон в целом.
^ «Руководство по Scrum» (PDF) . Скрам.орг. п. 6 . Проверено 15 июня 2023 г.
^ «Роль владельца продукта» . Скрам Альянс . Проверено 26 мая 2018 г.
^ «Роль владельца продукта» . Подготовка к тестированию Scrum Master . Проверено 3 февраля 2017 г.
^ Рад, Надер К.; Терли, Фрэнк (2018). Курсы Agile Scrum Foundation, второе издание . С-Хертогенбос, Нидерланды: Ван Харен. п. 26. ISBN 978-94-018-0279-6 .
^ Перейти обратно: ^а ^б Пит Димер; Габриэль Бенефилд; Крейг Ларман; Бас Водде (17 декабря 2012 г.). «The Scrum Primer: Краткое руководство по теории и практике Scrum (версия 2.0)» . ИнфоВ.
^ «Что такое ежедневный скрам?» . Скрам.орг . Проверено 6 января 2020 г.
^ Флюэллинг, Пол (2018). Руководство Agile-разработчика: Получите больше пользы от разработки программного обеспечения: извлеките максимум пользы из методологии Agile . Бирмингем, Великобритания: Packt Publishing Ltd., с. 91. ИСБН 978-1-78728-020-5 .
^ Маккенна, Дэйв (2016). Искусство Scrum: Как Scrum-мастера объединяют команды разработчиков и раскрывают гибкость . Аликиппа, Пенсильвания: CA Press. п. 126. ИСБН 978-1-4842-2276-8 .
^ Дронгелен, Майк ван; Деннис, Адам; Гарабедян, Ричард; Гонсалес, Альберто; Кришнасвами, Аравинд (2017). Бережливая разработка мобильных приложений: применяйте методологии экономичного стартапа для разработки успешных приложений для iOS и Android . Бирмингем, Великобритания: Packt Publishing Ltd., с. 43. ИСБН 978-1-78646-704-1 .
^ Рубин, Кеннет (2012), Essential Scrum. Практическое руководство по самому популярному гибкому процессу , Аддисон-Уэсли (опубликовано в 2013 г.), с. 375, ISBN 978-0-13-704329-3
^ Институт управления проектами 2021 , Глоссарий §3 Определения.
^ Хиггинс, Тони (31 марта 2009 г.). «Требования к авторству в гибком мире» . БА Таймс.
^ Расс Дж. Мартинелли; Драган З. Милошевич (5 января 2016 г.). Набор инструментов управления проектами: инструменты и методы для практикующего менеджера проектов . Уайли. п. 304. ИСБН 978-1-118-97320-2 .
^ Кен Швабер ; Джефф Сазерленд . «Руководство по Scrum» (PDF) . Скрам.орг . Проверено 25 мая 2018 г.
^ Чарльз Г. Кобб (27 января 2015 г.). Руководство для менеджера проекта по освоению Agile: принципы и практики адаптивного подхода . Джон Уайли и сыновья. п. 378. ИСБН 978-1-118-99104-6 .
^ Дженсон, Джон (8 марта 2019 г.). «Встречи: убийца производительности разработчиков» . TandemSeven — инновационная компания Experience . Архивировано из оригинала 5 июня 2020 года . Проверено 5 июня 2020 г.
^ «Не всем разработчикам нравится Agile, и вот 5 причин почему» . Деловые вопросы . 4 декабря 2019 года . Проверено 5 июня 2020 г.
^ Терк, Дэн; Франция, Роберт; Румпе, Бернхард (2014) [2002]. «Ограничения гибких программных процессов». Материалы Третьей международной конференции по экстремальному программированию и гибким процессам в программной инженерии : 43–46. arXiv : 1409.6600 .
^ «Проблемы и проблемы внедрения Scrum» (PDF) . Международный журнал научных и инженерных исследований . 3 (8). Август 2012 года . Проверено 10 декабря 2015 г.
^ Хрон, Михал; Обвегесер, Николаус (1 января 2022 г.). «Почему и как Scrum адаптируется на практике: Систематический обзор» . Журнал систем и программного обеспечения . 183 : 111110. doi : 10.1016/j.jss.2021.111110 . ISSN 0164-1212 . S2CID 240950847 .
^ Хрон, М.; Обвегесер, Н. (январь 2018 г.). «Scrum на практике: обзор адаптаций Scrum» (PDF) . Материалы 51-й Гавайской международной конференции по системным наукам (HICSS) 2018 г., 3–6 января 2018 г.
^ Бьёрнвиг, Гертруда; Коплиен, Джим (21 июня 2008 г.). «Скрам как организационные модели» . Гертруда и Коуп.
^ «Сообщество Scrum Pattern» . ScrumPLoP.org . Проверено 22 июля 2016 г.
^ Ладас, Кори (27 октября 2007 г.). «запрет схватки» . Бережливая разработка программного обеспечения. Архивировано из оригинала 23 августа 2018 года . Проверено 13 сентября 2012 г.
^ Книберг, Хенрик; Скарин, Маттиас (21 декабря 2009 г.). «Канбан и Скрам: максимально эффективно использовать оба» (PDF) . ИнфоQ . Проверено 22 июля 2016 г.
^ «Управление рисками – как не дать рискам испортить ваши проекты!» . Келли Уотерс.
^ «Скрам из скрамов» . Гибкий Альянс. 17 декабря 2015. Архивировано из оригинала 9 февраля 2014 года . Проверено 17 декабря 2013 г.
^ «Крупномасштабный Scrum (LeSS)» . 2014.
^ Гргич (2015). «Организация удаления накипи с помощью LeSS (Блог)» .
^ Ларман, Крейг; Бас Водде (май – июнь 2013 г.). «Масштабирование гибкой разработки» (PDF) . Перекрестные помехи .
^ Сантос, Ронни де Соуза; Ральф, Пол; Аршад, Архам; Стол, Клаас-Ян (5 октября 2023 г.). «Распределенный Scrum: метаанализ кейса» . Обзоры вычислительной техники ACM . 56 (4): 1–37. дои : 10.1145/3626519 . S2CID 263672588 .
^ Фаулер, Мартин (25 августа 2018 г.). «Состояние гибкого программного обеспечения в 2018 году» . martinfowler.com . Архивировано из оригинала 14 сентября 2023 года . Проверено 14 сентября 2023 г.
^ Джеффрис, Рон (8 сентября 2016 г.). «Тёмный Скрам» . ronjeffries.com . Проверено 6 мая 2024 г.

Общие и цитируемые ссылки

Димер, Пит; Бенефилд, Габриэль; Ларман, Крейг; Водде, Бас (2009). «Практический курс по Скраму» . Проверено 1 июня 2009 г.
Янофф, Н.С.; Рост, Л. (2000). «Процесс разработки программного обеспечения Scrum для небольших команд» (PDF) . Архивировано из оригинала (PDF) 6 ноября 2015 года . Проверено 26 февраля 2015 г.
Мюнх, Юрген; Арбалет, Уве; Сото, Мартин; Ковальчик, Мартин (2012). Определение и управление программным процессом . Спрингер. ISBN 978-3-642-24291-5 .
Руководство по совокупности знаний по управлению проектами (руководство PMBOK) (7-е изд.). Ньютаун-сквер, Пенсильвания: Институт управления проектами. 2021. ISBN 978-1-62825-664-2 .
Рубин, Кеннет (2013). Essential Scrum: Практическое руководство по самому популярному гибкому процессу . Аддисон-Уэсли. п. 173. ИСБН 978-0-13-704329-3 .
Ваканити, Дэниел (февраль 2018 г.). «Руководство по Канбану для Scrum-команд» (PDF) . scrum.org . Проверено 12 марта 2018 г.
Верхейен, Гюнтер (2013). Скрам – карманный путеводитель (умный попутчик в путешествии) . ISBN 978-90-8753-720-3 .

Внешние ссылки

Scrum-библиотека Agile Alliance
Описание процесса Scrum в рамках проекта Eclipse Process Framework (EPF).

[scrumguidepdf2020-1] Перейти обратно: ^а ^б ^с Кен Швабер ; Джефф Сазерленд . «Руководство по Scrum» (PDF) . Скрам.орг . Проверено 15 июня 2023 г.

[2] «Что такое Scrum Master? Все, что вам нужно знать – советник Forbes» . www.forbes.com . Проверено 16 ноября 2023 г.

[schwaber-3] Перейти обратно: ^а ^б ^с ^д ^и Швабер, Кен (1 февраля 2004 г.). Гибкое управление проектами с помощью Scrum . Майкрософт Пресс . ISBN 978-0-7356-1993-7 .

[scrumalliance-4] «Что такое Скрам?» . Что такое Скрам? Agile Framework для реализации сложных проектов — Scrum Alliance . Скрам Альянс . Проверено 24 февраля 2016 г.

[5] Дж. Генри и С. Генри. Количественная оценка процесса сопровождения программного обеспечения и волатильности требований. В Proc. конференции ACM по информатике, страницы 346–351, 1993 г.

[TakeuchiNonaka-6] Такеучи, Хиротака; Нонака, Икудзиро (1 января 1986 г.). «Игра по разработке новых продуктов» . Гарвардское деловое обозрение . Проверено 9 июня 2010 г. Перемещение Scrum вниз

[7] Компания, создающая знания . Издательство Оксфордского университета. 1995. с. 3. ISBN 978-0-19-976233-0 . Проверено 12 марта 2013 г.

[autogenerated1-8] Перейти обратно: ^а ^б Сазерленд, Джефф (октябрь 2004 г.). «Гибкая разработка: уроки, извлеченные из первого Scrum» . Архивировано из оригинала (PDF) 30 июня 2014 года . Проверено 26 сентября 2008 г.

[OOPSLA95-9] Сазерленд, Джеффри Виктор ; Швабер, Кен (1995). Проектирование и реализация бизнес-объектов: материалы семинара OOPSLA '95 . Мичиганский университет . п. 118. ИСБН 978-3-540-76096-2 .

[agilemanifesto-10] Перейти обратно: ^а ^б ^с «Манифест гибкой разработки программного обеспечения» . Проверено 17 октября 2019 г.

[11] Максимини, Доминик (8 января 2015 г.). Скрам-культура: внедрение гибких методов в организациях . Менеджмент для профессионалов. Чам: Springer (опубликовано в 2015 г.). п. 26. ISBN 978-3-319-11827-7 . Проверено 25 августа 2016 г. Кен Швабер и Джефф Сазерленд впервые представили Scrum на конференции OOPSLA в Остине, штат Техас, в 1995 году. [...] В 2001 году была опубликована первая книга о Scrum. [...] Год спустя (2002 г.) Кен основал Scrum Alliance, целью которого является обеспечение обучения и сертификации Scrum во всем мире.

[12] "Дом" . Скрам.орг . Проверено 6 января 2020 г.

[scrumguidesite-13] Перейти обратно: ^а ^б ^с ^д ^и Сазерленд, Джефф ; Швабер, Кен (2013). «Скрам-руководства» . ScrumGuides.org . Проверено 15 июня 2023 г.

[:0-14] Моррис, Дэвид (2017). Scrum: идеальная основа для гибких проектов . В простых шагах. стр. 178–179. ISBN 978-1-84078-731-3 . OCLC 951453155 .

[15] Кобб, Чарльз Г. (2015). Руководство для менеджера проекта по освоению Agile: принципы и практики адаптивного подхода . Хобокен, Нью-Джерси: John Wiley & Sons. п. 37. ИСБН 978-1-118-99104-6 .

[:1-16] Кон, Майк (2010). Как добиться успеха в Agile: разработка программного обеспечения с использованием Scrum . Река Аппер-Сэддл, Нью-Джерси: Аддисон-Уэсли. ISBN 978-0-321-57936-2 .

[Essential_Scrum:_Velocity-17] Рубин, Кеннет (2013), Essential Scrum. Практическое руководство по самому популярному гибкому процессу , Аддисон-Уэсли, с. 173, ISBN 978-0-13-704329-3

[:3-18] Перейти обратно: ^а ^б МакГрил, Дон; Йохам, Ральф (4 июня 2018 г.). Профессиональный владелец продукта: использование Scrum как конкурентное преимущество . Аддисон-Уэсли Профессионал. ISBN 978-0-13-468665-3 .

[19] Пихлер, Роман (11 марта 2010 г.). Гибкое управление продуктами с помощью Scrum: создание продуктов, которые нравятся клиентам . Аддисон-Уэсли Профессионал. ISBN 978-0-321-68413-4 .

[20] Эмблер, Скотт. «Роль владельца продукта: доверенное лицо заинтересованных сторон для Agile-команд» . www.agilemodeling.com . Проверено 22 июля 2016 г. [...] на практике оказывается, что у этой роли есть два важнейших аспекта: во-первых, как доверенное лицо заинтересованных сторон в команде разработчиков, а во-вторых, как представитель команды проекта перед всем сообществом заинтересованных сторон в целом.

[scrumguidepdf2016-21] «Руководство по Scrum» (PDF) . Скрам.орг. п. 6 . Проверено 15 июня 2023 г.

[22] «Роль владельца продукта» . Скрам Альянс . Проверено 26 мая 2018 г.

[23] «Роль владельца продукта» . Подготовка к тестированию Scrum Master . Проверено 3 февраля 2017 г.

[:2-24] Рад, Надер К.; Терли, Фрэнк (2018). Курсы Agile Scrum Foundation, второе издание . С-Хертогенбос, Нидерланды: Ван Харен. п. 26. ISBN 978-94-018-0279-6 .

[scrumprimer-25] Перейти обратно: ^а ^б Пит Димер; Габриэль Бенефилд; Крейг Ларман; Бас Водде (17 декабря 2012 г.). «The Scrum Primer: Краткое руководство по теории и практике Scrum (версия 2.0)» . ИнфоВ.

[26] «Что такое ежедневный скрам?» . Скрам.орг . Проверено 6 января 2020 г.

[:5-27] Флюэллинг, Пол (2018). Руководство Agile-разработчика: Получите больше пользы от разработки программного обеспечения: извлеките максимум пользы из методологии Agile . Бирмингем, Великобритания: Packt Publishing Ltd., с. 91. ИСБН 978-1-78728-020-5 .

[28] Маккенна, Дэйв (2016). Искусство Scrum: Как Scrum-мастера объединяют команды разработчиков и раскрывают гибкость . Аликиппа, Пенсильвания: CA Press. п. 126. ИСБН 978-1-4842-2276-8 .

[:4-29] Дронгелен, Майк ван; Деннис, Адам; Гарабедян, Ричард; Гонсалес, Альберто; Кришнасвами, Аравинд (2017). Бережливая разработка мобильных приложений: применяйте методологии экономичного стартапа для разработки успешных приложений для iOS и Android . Бирмингем, Великобритания: Packt Publishing Ltd., с. 43. ИСБН 978-1-78646-704-1 .

[Essential_Scrum:_Velocity2-30] Рубин, Кеннет (2012), Essential Scrum. Практическое руководство по самому популярному гибкому процессу , Аддисон-Уэсли (опубликовано в 2013 г.), с. 375, ISBN 978-0-13-704329-3

[FOOTNOTEProject_Management_Institute2021Glossary_§3_Definitions-31] Институт управления проектами 2021 , Глоссарий §3 Определения.

[32] Хиггинс, Тони (31 марта 2009 г.). «Требования к авторству в гибком мире» . БА Таймс.

[MartinelliMilosevic2016-33] Расс Дж. Мартинелли; Драган З. Милошевич (5 января 2016 г.). Набор инструментов управления проектами: инструменты и методы для практикующего менеджера проектов . Уайли. п. 304. ИСБН 978-1-118-97320-2 .

[scrumguidepdf2017-34] Кен Швабер ; Джефф Сазерленд . «Руководство по Scrum» (PDF) . Скрам.орг . Проверено 25 мая 2018 г.

[Cobb2015-35] Чарльз Г. Кобб (27 января 2015 г.). Руководство для менеджера проекта по освоению Agile: принципы и практики адаптивного подхода . Джон Уайли и сыновья. п. 378. ИСБН 978-1-118-99104-6 .

[36] Дженсон, Джон (8 марта 2019 г.). «Встречи: убийца производительности разработчиков» . TandemSeven — инновационная компания Experience . Архивировано из оригинала 5 июня 2020 года . Проверено 5 июня 2020 г.

[37] «Не всем разработчикам нравится Agile, и вот 5 причин почему» . Деловые вопросы . 4 декабря 2019 года . Проверено 5 июня 2020 г.

[38] Терк, Дэн; Франция, Роберт; Румпе, Бернхард (2014) [2002]. «Ограничения гибких программных процессов». Материалы Третьей международной конференции по экстремальному программированию и гибким процессам в программной инженерии : 43–46. arXiv : 1409.6600 .

[39] «Проблемы и проблемы внедрения Scrum» (PDF) . Международный журнал научных и инженерных исследований . 3 (8). Август 2012 года . Проверено 10 декабря 2015 г.

[40] Хрон, Михал; Обвегесер, Николаус (1 января 2022 г.). «Почему и как Scrum адаптируется на практике: Систематический обзор» . Журнал систем и программного обеспечения . 183 : 111110. doi : 10.1016/j.jss.2021.111110 . ISSN 0164-1212 . S2CID 240950847 .

[41] Хрон, М.; Обвегесер, Н. (январь 2018 г.). «Scrum на практике: обзор адаптаций Scrum» (PDF) . Материалы 51-й Гавайской международной конференции по системным наукам (HICSS) 2018 г., 3–6 января 2018 г.

[42] Бьёрнвиг, Гертруда; Коплиен, Джим (21 июня 2008 г.). «Скрам как организационные модели» . Гертруда и Коуп.

[43] «Сообщество Scrum Pattern» . ScrumPLoP.org . Проверено 22 июля 2016 г.

[scrumban-44] Ладас, Кори (27 октября 2007 г.). «запрет схватки» . Бережливая разработка программного обеспечения. Архивировано из оригинала 23 августа 2018 года . Проверено 13 сентября 2012 г.

[knibergskarin-45] Книберг, Хенрик; Скарин, Маттиас (21 декабря 2009 г.). «Канбан и Скрам: максимально эффективно использовать оба» (PDF) . ИнфоQ . Проверено 22 июля 2016 г.

[46] «Управление рисками – как не дать рискам испортить ваши проекты!» . Келли Уотерс.

[scrumofscrums-47] «Скрам из скрамов» . Гибкий Альянс. 17 декабря 2015. Архивировано из оригинала 9 февраля 2014 года . Проверено 17 декабря 2013 г.

[48] «Крупномасштабный Scrum (LeSS)» . 2014.

[49] Гргич (2015). «Организация удаления накипи с помощью LeSS (Блог)» .

[50] Ларман, Крейг; Бас Водде (май – июнь 2013 г.). «Масштабирование гибкой разработки» (PDF) . Перекрестные помехи .

[51] Сантос, Ронни де Соуза; Ральф, Пол; Аршад, Архам; Стол, Клаас-Ян (5 октября 2023 г.). «Распределенный Scrum: метаанализ кейса» . Обзоры вычислительной техники ACM . 56 (4): 1–37. дои : 10.1145/3626519 . S2CID 263672588 .

[stateofagile-52] Фаулер, Мартин (25 августа 2018 г.). «Состояние гибкого программного обеспечения в 2018 году» . martinfowler.com . Архивировано из оригинала 14 сентября 2023 года . Проверено 14 сентября 2023 г.

[53] Джеффрис, Рон (8 сентября 2016 г.). «Тёмный Скрам» . ronjeffries.com . Проверено 6 мая 2024 г.

[ 1 ]

[ 2 ]

[ 3 ]

[ 4 ]

[ 5 ]

[ 6 ]

[ 7 ]

[ 8 ]

[ 9 ]

[ 10 ]

[ 11 ]

[ 12 ]

[ 13 ]

[ 14 ]

[ 15 ]

[ 16 ]

[ 17 ]

[ 18 ]

[ 19 ]

[ 20 ]

[ 21 ]

[ 22 ]

[ 23 ]

[ 24 ]

[ 25 ]

[ 26 ]

[ 27 ]

[ 28 ]

[ 29 ]

[ 30 ]

[ 31 ]

[ 32 ]

[ 33 ]

[ 34 ]

[ 35 ]

[ 36 ]

[ 37 ]

[ 38 ]

[ 39 ]

[ 40 ]

[ 41 ]

[ 42 ]

[ 43 ]

[ 44 ]

[ 45 ]

[ 46 ]

[ 47 ]

[ 48 ]

[ 49 ]

[ 50 ]

[ 51 ]

[ 52 ]

[ 53 ]