stringtranslate.com

Scrum (разработка ПО)

События Scrum Agile, основанные на The Scrum Guide 2020 [1]

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

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

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

История

Термин scrum в разработке программного обеспечения появился в 1986 году в Harvard Business Review под названием «The New New Product Development Game» Хиротаки Такеучи и Икудзиро Нонака . На основе тематических исследований производственных компаний в автомобильной, копировальной и принтерной отраслях авторы изложили новый подход к разработке продукта для повышения скорости и гибкости. Они назвали это подходом регби , поскольку процесс включает в себя одну кросс-функциональную команду, работающую на нескольких перекрывающихся этапах, в которых команда «пытается пройти дистанцию ​​как единое целое, передавая мяч вперед и назад». [6] Позже авторы разработали scrum в своей книге « The Knowledge Creating Company» . [7]

В начале 1990-х годов Кен Швабер использовал то, что впоследствии стало Scrum в его компании Advanced Development Methods. Джефф Сазерленд , Джон Скумниоталес и Джефф Маккенна разработали аналогичный подход в 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 года.

Scrum-команда

Scrum-команда организована по крайней мере из трех категорий лиц: владелец продукта, разработчики и scrum-мастер. Владелец продукта связывается с заинтересованными сторонами, теми, кто заинтересован в результате проекта, чтобы сообщать разработчикам о задачах и ожиданиях. [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-мастера. Scrum-команды не включают менеджеров проектов, чтобы максимизировать самоорганизацию среди разработчиков. [25]

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

Спринт

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

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

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

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

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

Ежедневная схватка в вычислительном зале

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

События после спринта

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

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

Уточнение отставания

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

Артефакты

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

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

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

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

Спринт бэклог

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

Приращение

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

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

Диаграмма выработки

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

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

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

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

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

Скорость

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

Ограничения

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

Адаптации

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

Скрамбан

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

Схватка схваток

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

Крупномасштабная схватка

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

Критика

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

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

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

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

Цитаты

  1. ^ abc Кен Швабер ; Джефф Сазерленд . "The Scrum Guide" (PDF) . Scrum.org . Получено 15 июня 2023 г. .
  2. ^ «Что такое Scrum Master? Все, что вам нужно знать – Forbes Advisor». www.forbes.com . Получено 16 ноября 2023 г. .
  3. ^ abcde Швабер, Кен (1 февраля 2004 г.). Agile Project Management with Scrum . Microsoft Press . ISBN 978-0-7356-1993-7.
  4. ^ "Что такое Scrum?". Что такое Scrum? Agile Framework для завершения сложных проектов – Scrum Alliance . Scrum Alliance . Получено 24 февраля 2016 г.
  5. ^ Дж. Генри и С. Генри. Количественная оценка процесса сопровождения программного обеспечения и изменчивости требований. В Трудах конференции ACM по информатике, страницы 346–351, 1993.
  6. ^ Такеучи, Хиротака; Нонака, Икудзиро (1 января 1986 г.). «Новая игра в разработку нового продукта». Harvard Business Review . Получено 9 июня 2010 г. Перемещение Scrum вниз по полю
  7. ^ Компания, создающая знания. Oxford University Press. 1995. стр. 3. ISBN 978-0-19-976233-0. Получено 12 марта 2013 г. .
  8. ^ ab Sutherland, Jeff (октябрь 2004 г.). "Agile Development: Lessons learned from the first Scrum". Архивировано из оригинала (PDF) 30 июня 2014 г. Получено 26 сентября 2008 г.
  9. ^ Сазерленд, Джеффри Виктор ; Швабер, Кен (1995). Проектирование и реализация бизнес-объектов: Труды семинара OOPSLA '95 . Мичиганский университет . стр. 118. ISBN 978-3-540-76096-2.
  10. ^ abc "Manifesto for Agile Software Development" . Получено 17 октября 2019 г. .
  11. ^ Максимини, Доминик (8 января 2015 г.). Scrum Culture: Introducing Agile Methods in Organizations. Management for Professionals. Cham: Springer (опубликовано в 2015 г.). стр. 26. ISBN 978-3-319-11827-7. Получено 25 августа 2016 г. Кен Швабер и Джефф Сазерленд впервые представили Scrum на конференции OOPSLA в Остине, штат Техас, в 1995 году. [...] В 2001 году была опубликована первая книга о Scrum. [...] Год спустя (2002) Кен основал Scrum Alliance, целью которого было обеспечить всемирное обучение и сертификацию по Scrum.
  12. ^ "Home". Scrum.org . Получено 6 января 2020 г. .
  13. ^ abcde Сазерленд, Джефф ; Швабер, Кен (2013). «Скрам-гиды». ScrumGuides.org . Проверено 15 июня 2023 г.
  14. ^ Моррис, Дэвид (2017). Scrum: идеальная структура для agile-проектов . В Easy Steps. стр. 178–179. ISBN 978-1-84078-731-3. OCLC  951453155.
  15. ^ Кобб, Чарльз Г. (2015). Руководство для менеджеров проектов по освоению Agile: принципы и практики адаптивного подхода . Хобокен, Нью-Джерси: John Wiley & Sons. стр. 37. ISBN 978-1-118-99104-6.
  16. ^ Кон, Майк (2010). Успех с Agile: Разработка программного обеспечения с использованием Scrum . Upper Saddle River, NJ: Addison-Wesley. ISBN 978-0-321-57936-2.
  17. ^ Рубин, Кеннет (2013), Essential Scrum. Практическое руководство по самому популярному Agile-процессу , Addison-Wesley, стр. 173, ISBN 978-0-13-704329-3
  18. ^ ab McGreal, Don; Jocham, Ralph (4 июня 2018 г.). Профессиональный владелец продукта: использование Scrum в качестве конкурентного преимущества. Addison-Wesley Professional. ISBN 978-0-13-468665-3.
  19. ^ Пихлер, Роман (11 марта 2010 г.). Agile Product Management with Scrum: Creating Products that Customers Love . Addison-Wesley Professional. ISBN 978-0-321-68413-4.
  20. ^ Эмблер, Скотт. «Роль владельца продукта: доверенное лицо заинтересованной стороны для гибких команд». agilemodeling.com . Получено 22 июля 2016 г. [ ...] на практике эта роль имеет два важнейших аспекта: во-первых, как доверенное лицо заинтересованной стороны в команде разработчиков и, во-вторых, как представитель проектной группы для всего сообщества заинтересованных сторон в целом.
  21. ^ "The Scrum Guide" (PDF) . Scrum.org. стр. 6 . Получено 15 июня 2023 г. .
  22. ^ "Роль владельца продукта". Scrum Alliance . Получено 26 мая 2018 г.
  23. ^ "Роль владельца продукта". Scrum Master Test Prep . Получено 3 февраля 2017 г.
  24. ^ Рад, Надер К.; Терли, Фрэнк (2018). Курсы Agile Scrum Foundation, второе издание . С-Хертогенбос, Нидерланды: Ван Харен. п. 26. ISBN 978-94-018-0279-6.
  25. ^ аб Пит Димер; Габриэль Бенефилд; Крейг Ларман; Бас Водде (17 декабря 2012 г.). «Букварь по Scrum: облегченное руководство по теории и практике Scrum (версия 2.0)». ИнфоВ.
  26. ^ "Что такое Daily Scrum?". Scrum.org . Получено 6 января 2020 г.
  27. ^ Флюэллинг, Пол (2018). Справочник разработчика Agile: Получите больше пользы от разработки программного обеспечения: извлеките максимум из методологии Agile . Бирмингем, Великобритания: Packt Publishing Ltd. стр. 91. ISBN 978-1-78728-020-5.
  28. ^ Маккенна, Дэйв (2016). Искусство Scrum: как Scrum-мастера объединяют команды разработчиков и раскрывают гибкость . Аликуиппа, Пенсильвания: CA Press. стр. 126. ISBN 978-1-4842-2276-8.
  29. ^ Дронгелен, Майк ван; Деннис, Адам; Гарабедиан, Ричард; Гонсалес, Альберто; Кришнасвами, Аравинд (2017). Разработка бережливых мобильных приложений: применение методологий бережливого стартапа для разработки успешных приложений для iOS и Android . Бирмингем, Великобритания: Packt Publishing Ltd. стр. 43. ISBN 978-1-78646-704-1.
  30. ^ Рубин, Кеннет (2012), Essential Scrum. Практическое руководство по самому популярному Agile-процессу , Addison-Wesley (опубликовано в 2013 г.), стр. 375, ISBN 978-0-13-704329-3
  31. ^ Институт управления проектами 2021, Глоссарий §3 Определения.
  32. ↑ Хиггинс, Тони (31 марта 2009 г.). «Требования к разработке в мире Agile». BA Times.
  33. ^ Расс Дж. Мартинелли; Драган З. Милошевич (5 января 2016 г.). Project Management ToolBox: Инструменты и методы для практикующего менеджера проектов. Wiley. стр. 304. ISBN 978-1-118-97320-2.
  34. ^ Кен Швабер ; Джефф Сазерленд . "The Scrum Guide" (PDF) . Scrum.org . Получено 25 мая 2018 г. .
  35. ^ Чарльз Г. Кобб (27 января 2015 г.). Руководство для менеджеров проектов по освоению Agile: принципы и практики адаптивного подхода. John Wiley & Sons. стр. 378. ISBN 978-1-118-99104-6.
  36. ^ Дженсон, Джон (8 марта 2019 г.). «Встречи: убийца производительности для разработчиков». TandemSeven – The Experience Innovation Company . Архивировано из оригинала 5 июня 2020 г. . Получено 5 июня 2020 г. .
  37. ^ «Не всем разработчикам нравится Agile, и вот 5 причин почему». Business Matters . 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. ^ Hron, M.; Obwegeser, N. (январь 2018 г.). "Scrum на практике: обзор адаптаций Scrum" (PDF) . Труды 51-й Гавайской международной конференции по системным наукам (HICSS) 2018 г., 3–6 января 2018 г.
  42. ^ Бьёрнвиг, Гертруда; Коплиен, Джим (21 июня 2008 г.). «Скрам как организационные модели». Гертруда и Коуп.
  43. ^ "Scrum Pattern Community". ScrumPLoP.org . Получено 22 июля 2016 г. .
  44. ^ Ладас, Кори (27 октября 2007 г.). "scrum-ban". Lean Software Engineering. Архивировано из оригинала 23 августа 2018 г. Получено 13 сентября 2012 г.
  45. ^ Книберг, Хенрик; Скарин, Маттиас (21 декабря 2009 г.). «Канбан и Скрам: максимально эффективно использовать оба» (PDF) . ИнфоQ . Проверено 22 июля 2016 г.
  46. ^ «Управление рисками — как не дать рискам испортить ваши проекты!». Келли Уотерс.
  47. ^ "Scrum of Scrums". Agile Alliance. 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.
  52. ^ Фаулер, Мартин (25 августа 2018 г.). «Состояние Agile Software в 2018 году». martinfowler.com . Архивировано из оригинала 14 сентября 2023 г. . Получено 14 сентября 2023 г. .
  53. ↑ Джеффрис, Рон (8 сентября 2016 г.). «Темный Scrum». ronjeffries.com . Получено 6 мая 2024 г. .

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

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

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