stringtranslate.com

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

Мероприятия Scrum Agile на основе Руководства по Scrum 2020 [1]

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

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

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

История

Использование термина Scrum в разработке программного обеспечения пришло из статьи 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, который курирует параллельную серию профессиональных аккредитаций Scrum . [12] С 2009 года Швабер и Сазерленд публикуют и обновляют общедоступный документ под названием The Scrum Guide [13] . Он пересматривался 6 раз, текущая версия — ноябрь 2020 года.

Термин «схватка» ранее был зарегистрирован как торговая марка Швабера, но срок регистрации истек. Было высказано предположение, что Швабер упустил его из виду с намерением признать и дать возможность широкому использованию этого термина сообществом. [ нужна цитата ]

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

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

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

В каждой 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]

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

Спринт

Фреймворк Scrum (PBI на рисунке относится к элементу невыполненной работы по продукту)
Скрам-процесс

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

Если спринт аварийно завершается, следующим шагом является планирование нового спринта, в ходе которого проверяется причина прекращения.

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

Scrum делает упор на практические результаты в конце каждого спринта, что приближает разработанный продукт к успеху на рынке.

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

В начале спринта scrum-команда проводит мероприятие по планированию спринта, чтобы:

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

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

Ежедневная ссора в компьютерном зале. Такое централизованное расположение помогает команде приступить к работе вовремя.

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

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

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

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

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

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

Артефакты

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

Резерв продукта

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

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

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

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

Приращение

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

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

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

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

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

Выпуск диаграммы выгорания

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

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

Скорость

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

Ограничения

Некоторые утверждают, что мероприятия Scrum, такие как ежедневные Scrum и обзор Scrum, снижают производительность и тратят время, которое можно было бы лучше потратить на реальные продуктивные задачи. [36] [37] На практике многие практикующие схватки проводят мероприятия, такие как ежедневные схватки, как расширенное обсуждение, не соблюдая требования по ограничению времени. [ нужна цитата ]

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

Адаптации

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

Скрамбан

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

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

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

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

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

Критика

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

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

Смотрите также

Цитаты

  1. ^ abc Кен Швабер ; Джефф Сазерленд . «Руководство по Scrum» (PDF) . Скрам.орг . Проверено 15 июня 2023 г.
  2. ^ «Что такое Scrum Master? Все, что вам нужно знать - советник Forbes» . www.forbes.com . Проверено 16 ноября 2023 г.
  3. ^ abcde Швабер, Кен (1 февраля 2004 г.). Гибкое управление проектами с помощью Scrum . Майкрософт Пресс . ISBN 978-0-7356-1993-7.
  4. ^ «Что такое Scrum?». Что такое Скрам? Agile Framework для реализации сложных проектов — Scrum Alliance . Скрам Альянс . Проверено 24 февраля 2016 г.
  5. ^ Дж. Генри и С. Генри. Количественная оценка процесса сопровождения программного обеспечения и волатильности требований. В Proc. конференции ACM по информатике, страницы 346–351, 1993 г.
  6. ^ Такеучи, Хиротака; Нонака, Икудзиро (1 января 1986 г.). «Игра по разработке новых продуктов». Гарвардское деловое обозрение . Проверено 9 июня 2010 г. Перемещение Scrum вниз
  7. ^ Компания, создающая знания. Издательство Оксфордского университета. 1995. с. 3. ISBN 978-0-19-976233-0. Проверено 12 марта 2013 г.
  8. ^ аб Сазерленд, Джефф (октябрь 2004 г.). «Гибкая разработка: уроки, извлеченные из первого Scrum». Архивировано из оригинала (PDF) 30 июня 2014 года . Проверено 26 сентября 2008 г.
  9. ^ Сазерленд, Джеффри Виктор ; Швабер, Кен (1995). Проектирование и реализация бизнес-объектов: материалы семинара OOPSLA '95 . Мичиганский университет . п. 118. ИСБН 978-3-540-76096-2.
  10. ^ ab «Манифест гибкой разработки программного обеспечения» . Проверено 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 г.
  13. ^ abcdefg Сазерленд, Джефф ; Швабер, Кен (2013). «Скрам-гиды». ScrumGuides.org . Проверено 15 июня 2023 г.
  14. ^ Моррис, Дэвид (2017). Scrum: идеальная основа для гибких проектов . В простых шагах. стр. 178–179. ISBN 978-1-84078-731-3. ОКЛК  951453155.
  15. ^ Кобб, Чарльз Г. (2015). Руководство для менеджера проекта по освоению Agile: принципы и практики адаптивного подхода . Хобокен, Нью-Джерси: John Wiley & Sons. п. 37. ИСБН 978-1-118-99104-6.
  16. ^ Кон, Майк (2010). Как добиться успеха в Agile: разработка программного обеспечения с использованием Scrum . Река Аппер-Сэддл, Нью-Джерси: Аддисон-Уэсли. ISBN 978-0-321-57936-2.
  17. ^ Рубин, Кеннет (2013), Essential Scrum. Практическое руководство по самому популярному гибкому процессу , Аддисон-Уэсли, с. 173, ISBN 978-0-13-704329-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 г. [...] на практике оказывается, что у этой роли есть два важнейших аспекта: во-первых, как доверенное лицо заинтересованных сторон в команде разработчиков, а во-вторых, как представитель команды проекта перед всем сообществом заинтересованных сторон в целом.
  21. ^ «Руководство по Scrum» (PDF) . Скрам.орг. п. 6 . Проверено 15 июня 2023 г.
  22. ^ «Роль владельца продукта». Скрам Альянс . Проверено 26 мая 2018 г.
  23. ^ «Роль владельца продукта» . Подготовка к тестированию Scrum Master . Проверено 3 февраля 2017 г.
  24. ^ Рад, Надер К.; Терли, Фрэнк (2018). Курсы Agile Scrum Foundation, второе издание . С-Хертогенбос, Нидерланды: Ван Харен. п. 26. ISBN 978-94-018-0279-6.
  25. ^ аб Пит Димер; Габриэль Бенефилд; Крейг Ларман; Бас Водде (17 декабря 2012 г.). «Букварь по Scrum: облегченное руководство по теории и практике Scrum (версия 2.0)». ИнфоВ.
  26. ^ «Что такое ежедневный скрам?». Скрам.орг . Проверено 6 января 2020 г.
  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.
  29. ^ Дронгелен, Майк ван; Деннис, Адам; Гарабедян, Ричард; Гонсалес, Альберто; Кришнасвами, Аравинд (2017). Бережливая разработка мобильных приложений: применяйте методологии экономичного стартапа для разработки успешных приложений для iOS и Android . Бирмингем, Великобритания: Packt Publishing Ltd., с. 43. ИСБН 978-1-78646-704-1.
  30. ^ Рубин, Кеннет (2012), Essential Scrum. Практическое руководство по самому популярному гибкому процессу , Аддисон-Уэсли (опубликовано в 2013 г.), с. 375, ISBN 978-0-13-704329-3
  31. ^ Институт управления проектами 2021, Глоссарий §3 Определения.
  32. ↑ Хиггинс, Тони (31 марта 2009 г.). «Требования к авторству в гибком мире». БА Таймс.
  33. ^ Расс Дж. Мартинелли; Драган З. Милошевич (5 января 2016 г.). ToolBox для управления проектами: инструменты и методы для практикующего менеджера проектов. Уайли. п. 304. ИСБН 978-1-118-97320-2.
  34. ^ Кен Швабер ; Джефф Сазерленд . «Руководство по Scrum» (PDF) . Скрам.орг . Проверено 25 мая 2018 г.
  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 г.
  44. ↑ Ладас, Кори (27 октября 2007 г.). «запрет схватки». Бережливая разработка программного обеспечения. Архивировано из оригинала 23 августа 2018 года . Проверено 13 сентября 2012 г.
  45. ^ Книберг, Хенрик; Скарин, Маттиас (21 декабря 2009 г.). «Канбан и Скрам: максимально эффективно использовать оба» (PDF) . ИнфоQ . Проверено 22 июля 2016 г.
  46. ^ «Управление рисками - как не дать рискам испортить ваши проекты!». Келли Уотерс.
  47. ^ "Скрам из скрамов" . Гибкий Альянс. 17 декабря 2015. Архивировано из оригинала 9 февраля 2014 года . Проверено 17 декабря 2013 г.
  48. ^ «Крупномасштабный Scrum (LeSS)» . 2014.
  49. ^ Гргич (2015). «Организация удаления накипи с помощью LeSS (Блог)».
  50. ^ Ларман, Крейг; Бас Водде (май – июнь 2013 г.). «Масштабирование гибкой разработки» (PDF) . Перекрестные помехи .
  51. ^ Сантос, Ронни де Соуза; Ральф, Пол; Аршад, Архам; Стол, Клаас-Ян (5 октября 2023 г.). «Распределенный Scrum: метаанализ кейса». Обзоры вычислительной техники ACM . дои : 10.1145/3626519 . S2CID  263672588.
  52. ↑ Фаулер, Мартин (25 августа 2018 г.). «Состояние гибкого программного обеспечения в 2018 году». martinfowler.com . Архивировано из оригинала 14 сентября 2023 года . Проверено 14 сентября 2023 г.

Рекомендации

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

На Wikimedia Commons есть средства массовой информации, связанные со Scrum (разработка) .
В Wikisource есть оригинальный текст, относящийся к этой статье:
Руководство по Скраму