✖


Jump to content

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

(Перенаправлено из Крупномасштабного Scrum )
Эта статья о среде разработки программного обеспечения. Чтобы узнать о других вариантах использования, см. Scrum .

Часть серии о
Разработка программного обеспечения
Основная деятельность
Парадигмы и модели
Методологии и рамки
Вспомогательные дисциплины
Практики
Инструменты
Стандарты и своды знаний
Глоссарии
Контуры
Мероприятия Scrum Agile на основе Scrum Guide 2020. [1]

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

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

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

История [ править ]

Использование термина scrum в разработке программного обеспечения пришло из статьи Harvard Business Review 1986 года под названием «Игра по разработке новых новых продуктов», написанной Хиротакой Такеучи и Икуджиро Нонака . Основываясь на тематических исследованиях производственных фирм в автомобильной, копировальной и принтерной отраслях , авторы изложили новый подход к разработке продуктов для повышения скорости и гибкости. Они назвали это подходом к регби , поскольку в этом процессе участвует одна межфункциональная команда, действующая на нескольких перекрывающихся фазах, в которых команда «пытается пройти дистанцию ​​как единое целое, передавая мяч вперед и назад». [6] Позже авторы разработали Scrum в своей книге « Компания, создающая знания» . [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] был опубликован и обновлен Швабером и Сазерлендом. Он пересматривался 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]

Рабочий процесс [ править ]

Спринт [ править ]

Не путать с Hackathon § Code sprints .
Фреймворк 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 = минимально жизнеспособный продукт)
Основная статья: Диаграмма выгорания

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

Скорость [ править ]

Основная статья: Velocity (разработка программного обеспечения)

Некоторые менеджеры проектов полагают, что общие усилия команды за один спринт можно определить путем оценки работы, выполненной за последний спринт. Сбор исторических данных о « скорости » является руководством, помогающим команде понять свои возможности. Тем не менее, концепция скорости вызывает споры среди практиков 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 в масштабе, когда несколько команд координируют работу над одним и тем же продуктом. В ежедневных скрам-совещаниях Scrum-of-Scrum участвуют представители, выбранные из каждой отдельной команды, которые могут быть либо разработчиком, либо скрам-мастером. В качестве инструмента координации Scrum of Scrums позволяет командам коллективно работать над общекомандными рисками, препятствиями, зависимостями и предположениями (RIDA), которые можно отслеживать в собственном журнале невыполненных работ. [46] [47]

Масштабная схватка [ править ]

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

Критика [ править ]

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

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

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

См. также [ править ]

Цитаты [ править ]

  1. ^ Jump up to: Перейти обратно: а б с Кен Швабер ; Джефф Сазерленд . «Руководство по Scrum» (PDF) . Скрам.орг . Проверено 15 июня 2023 г.
  2. ^ «Что такое Scrum Master? Все, что вам нужно знать – советник Forbes» . www.forbes.com . Проверено 16 ноября 2023 г.
  3. ^ Jump up to: Перейти обратно: а б с д и Швабер, Кен (1 февраля 2004 г.). Гибкое управление проектами с помощью Scrum . Майкрософт Пресс . ISBN  978-0-7356-1993-7 .
  4. ^ «Что такое Скрам?» . Что такое Скрам? 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. ^ Jump up to: Перейти обратно: а б Сазерленд, Джефф (октябрь 2004 г.). «Agile Development: уроки, извлеченные из первого Scrum» . Архивировано из оригинала (PDF) 30 июня 2014 года . Проверено 26 сентября 2008 г.
  9. ^ Сазерленд, Джеффри Виктор ; Швабер, Кен (1995). Проектирование и реализация бизнес-объектов: материалы семинара OOPSLA '95 . Мичиганский университет . п. 118. ИСБН  978-3-540-76096-2 .
  10. ^ Jump up to: Перейти обратно: а б с «Манифест гибкой разработки программного обеспечения» . Проверено 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. ^ Jump up to: Перейти обратно: а б с д и ж г Сазерленд, Джефф ; Швабер, Кен (2013). «Скрам-руководства» . ScrumGuides.org . Проверено 15 июня 2023 г.
  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 .
  16. ^ Кон, Майк (2010). Как добиться успеха в Agile: разработка программного обеспечения с использованием Scrum . Река Аппер-Сэддл, Нью-Джерси: Аддисон-Уэсли. ISBN  978-0-321-57936-2 .
  17. ^ Рубин, Кеннет (2013), Essential Scrum. Практическое руководство по самому популярному гибкому процессу , Аддисон-Уэсли, с. 173, ISBN  978-0-13-704329-3
  18. ^ Jump up to: Перейти обратно: а б МакГрил, Дон; Йохам, Ральф (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. ^ Jump up to: Перейти обратно: а б Пит Димер; Габриэль Бенефилд; Крейг Ларман; Бас Водде (17 декабря 2012 г.). «The Scrum Primer: Краткое руководство по теории и практике 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 г.). Набор инструментов управления проектами: инструменты и методы для практикующего менеджера проектов . Уайли. п. 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 г.
  53. ^ Джеффрис, Рон (8 сентября 2016 г.). «Тёмный Скрам» . ronjeffries.com . Проверено 6 мая 2024 г.

Ссылки [ править ]

Внешние ссылки [ править ]

На Wikimedia Commons есть средства массовой информации, связанные со Scrum (разработка) .
В Wikisource есть оригинальный текст, относящийся к этой статье:
Retrieved from "https://en.wikipedia.org/w/index.php?title=Scrum_(software_development)&oldid=1230206138#Large-scale_scrum"
Arc.Ask3.Ru: конец переведенного документа.
Arc.Ask3.Ru
Номер скриншота №: e9ce769c9db93b6f6f5437523b37cf80__1718955240
URL1:https://arc.ask3.ru/arc/aa/e9/80/e9ce769c9db93b6f6f5437523b37cf80.html
Заголовок, (Title) документа по адресу, URL1:
Scrum (software development) - Wikipedia
Данный printscreen веб страницы (снимок веб страницы, скриншот веб страницы), визуально-программная копия документа расположенного по адресу URL1 и сохраненная в файл, имеет: квалифицированную, усовершенствованную (подтверждены: метки времени, валидность сертификата), открепленную ЭЦП (приложена к данному файлу), что может быть использовано для подтверждения содержания и факта существования документа в этот момент времени. Права на данный скриншот принадлежат администрации Ask3.ru, использование в качестве доказательства только с письменного разрешения правообладателя скриншота. Администрация Ask3.ru не несет ответственности за информацию размещенную на данном скриншоте. Права на прочие зарегистрированные элементы любого права, изображенные на снимках принадлежат их владельцам. Качество перевода предоставляется как есть. Любые претензии, иски не могут быть предъявлены. Если вы не согласны с любым пунктом перечисленным выше, вы не можете использовать данный сайт и информация размещенную на нем (сайте/странице), немедленно покиньте данный сайт. В случае нарушения любого пункта перечисленного выше, штраф 55! (Пятьдесят пять факториал, Денежную единицу (имеющую самостоятельную стоимость) можете выбрать самостоятельно, выплаичвается товарами в течение 7 дней с момента нарушения.)