Разработка программного обеспечения | |
---|---|
Процесс разработки ПО | |
Ключевые процессы | |
Анализ • Проектирование • Программирование • Документирование • Тестирование | |
Модели | |
Итеративная • Спиральная • Каскадная • V-Model • Dual Vee Model | |
Методологии | |
Agile (XP, Lean, Scrum, FDD и др.) • Cleanroom • OpenUP • RAD • RUP • MSF • DSDM • TDD • BDD | |
Сопутствующие дисциплины | |
Конфигурационное управление • Управление проектами • Управление требованиями • Обеспечение качества |
Эта статья должна быть полностью переписана. |
SCRUM (/skrʌm/[1]; англ. scrum «схватка») — метод управления проектами.
Следует различать SCRUM[2] и Agile[3].
SCRUM используется как в сфере разработки ПО, так и в других производственных бизнес-отраслях[4].
Кроме управления проектами по разработке ПО, SCRUM может также использоваться в работе команд поддержки программного обеспечения, как подход к управлению разработкой и сопровождению программ, а также в ремонте[5].
Подход впервые описали Хиротака Такэути (en:Hirotaka Takeuchi) и Икудзиро Нонака(en:Ikujiro Nonaka) в статье The New Product Development Game (Harvard Business Review, январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «подход регби».
В 1991 году ДеГрейс и Шталь в книге «Нечестивые проблемы, праведные решения»[6] ссылались на этот подход, как на SCRUM (толкотня; схватка вокруг мяча (в регби)), спортивный термин, приведенный в статье Такэути и Нонакой. Кен Швабер (en:Ken Schwaber) в начале 1990-х использовал подход, который привел SCRUM в его компанию. Впервые методология SCRUM была представлена на общее обозрение задокументированным, четко сформированным и описанным совместно Швабером и Джефом Сазерлендом (en:Jeff Sutherland) на OOPSLA’95[7] в Остине. Швабер и Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь их опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как SCRUM. Швабер объединил усилия с Майком Бидлом (Mike Beedle) в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM»[8].
SCRUM (SCRibing Unified Methodology[9] или SCRapbooking Unified Methodology[10] или Sprint Continious Rugby Unified Methodology[11]) — набор принципов, ценностей, политик, ритуалов, артефактов, основанных на скрайбинге[12] и скрапбукинге[13], на которых строится процесс SCRUM-разработки, позволяющий в жестко фиксированные и небольшие по времени итерации, называемые спринтами (sprints), предоставлять конечному пользователю работающий продукт с новыми бизнес-возможностями, для которых определен наибольший приоритет. Методология основана на лего-фасилитации[14][15], тактиках и стратегиях из регби и бега на короткие дистанции (спринта), с помощью артефактов и ритуалов скрайбинга и скрапбукинга. Возможности к реализации в очередном спринте определяются в начале спринта на совещании Sprint Planning Meeting планирования методом Planning Poker и не могут изменяться на всем его протяжении. При этом строго фиксированная небольшая длительность спринта придает процессу разработки предсказуемость и гибкость.
Спринт[16] — итерация в скраме, в ходе которой создается инкремент бизнес-продукта. Жестко фиксирован по времени. Длительность одного спринта от 1 до 4 недель. Чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах скрам-команда уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, кросс-функциональности команд и требований, часто методом проб и ошибок. Для оценки объема работ в спринте можно использовать предварительную оценку, измеряемую в очках истории. Предварительная оценка длины спринта фиксируется в бэклоге проекта.
Диаграмма, демонстрирующая количество сделанной и оставшейся работы относительно времени на разработку проекта.
Данные диаграммы необходимо ежедневно обновлять, чтобы в реальном времени показывать подвижки и издержки в работе над спринтом и проектом, доступные для всех членов SCRUM-команды: скрам-мастера и скрам-владельца продукта.
Диаграмма сгорания работ для спринта — показывает, сколько задач сделано и сколько еще остается сделать в текущем спринте.
Журнал пожеланий проекта (англ. Project backlog) — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items). Журнал пожеланий проекта открыт для редактирования для всех участников скрам-процесса. Project backlog ведется SCRUM Product Owner.
Журнал пожеланий спринта (англ. Sprint backlog) — содержит функциональность, выбранную владельцем продукта из журнала пожеланий проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. На Sprint Planning Meeting команда оценивает объем работы, который нужно проделать для завершения спринта[17] методом Planning Poker.
Канбан-доска должна состоять как минимум из трех колонок: «сделать» (англ. to-do), «в процессе» (in progress), «сделано»(done). При разработке ПО SCRUM канбан-доска обычно включает следующие колонки в соответствии со статусом задач: обсуждается (backlog), согласовано (ready), кодируется (coding), тестируется (testing), подтверждается (approval) и сделано (done). На доску в соответствующий столбец прикрепляются канбан-карточки[18]. Вместо специальных канбан-карточек, которые обычно обозначают потребность или пропускную способность, вместе с доской используются магниты, пластиковые фишки, цветные шайбы или стикеры для представления рабочих элементов и процессов. Каждый из этих объектов представляет собой этап производственного процесса и движется по доске, по мере прогресса. Такое движение соответствует движению SCRUM-процесса производства по Burndown Chart сверху вниз. Часто используется электронная Канбан-доска[19].
Требования к канбан-доске и канбан-карточкам[20]:
Это краткое описание бизнес-цели, ради которой выполняется данный спринт. Цель на спринт помогает команде принимать бизнес-обоснованные решения. Этот артефакт необходим для того, чтобы команда проекта могла самостоятельно принимать решение в случае появления альтернативных путей решения бизнес-задачи.
Инкремент Продукта — это готовый продукт в конце спринта. Показывают заинтересованным на демонстрации[2], чтобы собрать отзывы и решить, что делать с продуктом дальше[21].
Требуемую бизнес-функциональность, которую добавляют в бэклог, часто называют историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>». Такая структура удобна тем, что понятна как разработчикам, так и заказчикам.
Остановка спринта может быть произведена раньше срока его планового окончания в исключительных ситуациях. Спринт может остановить команда, если понимает, что не может достичь цели спринта в отведенное время. Спринт может остановить скрам мастер или владелец продукта, если исчезает необходимость в реализации цели спринта. После этого начинается новый спринт.
Абстрактная метрика оценки сложности истории, которая не учитывает затраты в человекочасах. Обычно используют одну из следующих шкал:
Добавляются к историям спринта. Выполнение каждой задачи оценивается в часах. Каждая задача не должна превышать 12 часов (зачастую команда настаивает, чтобы максимальная продолжительность задачи равнялась одному рабочему дню).
Критерии, определяющие степень готовности элемента из журнала пожеланий пользователя.
Общее количество очков, набранных скрам-командой за предыдущий спринт. Данная метрика помогает команде понять, сколько историй она может сделать за один спринт.
По методике Scrum в производственном процессе есть определенные роли, разбитые на две группы «свиней» и «кур». Эти названия были использованы из-за шутки[источник не указан 33 дня]
Свинья идет по дороге. Курица смотрит на нее и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать „Яичница с беконом“?». «Так не пойдет, — отвечает свинья, — ведь тогда мне придется полностью посвятить себя проекту, а ты будешь вовлечена только частично».
Свиньи создают продукт, тогда как куры заинтересованы, но не настолько — ведь им все равно, будет ли проект удачным или нет, на них это мало отразится. Требования, пожелания, идеи и влияние кур принимаются во внимание, но им не разрешают непосредственно включаться в ход скрам-проекта.
«Свиньи» полностью включены в проект и в скрам-процесс.
Скрам-мастер (SCRUM Master) — проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Таким образом скрам-мастер есть сервант-лидер (Servant Leader) команды.
Главным инструментом скрам-мастера является чемодан фасилитатора, куда входят коробочки для карточек, для аксессуаров, для маркеров, клейкие карты, булавки, маркеры, канцелярский нож, клейкая лента.
Скрам-владелец продукта (SCRUM Product Owner) — представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
Скрам-команда (SCRUM Team) — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды составляет от 5 до 9 человек. Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Никто, кроме скрам-команды, скрам-мастера и владельца продукта не может вмешиваться в процесс разработки на протяжении спринта. Кросс-функциональность команды позволяет максимально эффективно планировать затраты на реализацию бизнес-требований и в сжатые сроки поставлять реально работающие бизнес-приложения в полном соответствии с изменяющимися требованиями заказчика.
Иногда также используются дополнительные поля в бэклоге проекта в основном для того, чтобы помочь SCRUM-владельцу продукта определиться с его приоритетами.
В начале спринта SCRUM Product Owner вносит в Product Backlog новые User Story и удаляет сделанные[2]. Затем проводятся совещания.
Происходит в начале новой итерации спринта.
Покер планирования (англ. Planning Poker, а также англ. Scrum poker) — техника оценки, основанная на достижении договоренности, главным образом используемая для оценки сложности предстоящей работы или относительного объема решаемых задач при разработке программного обеспечения.
Planning Poker проводится на Sprint Planning Meeting.
Для проведения покера планирования необходимо подготовить список обсуждаемых функций и несколько колод пронумерованных карт. Колода карт содержит карты 0, ?, 1, 2, 3, 5, 8, 13, 20, 40, 100, «?», «Чашка кофе». Знак вопроса означает, что «игрок» не понял до конца смысл обсуждаемого или не обладает достаточной информацией, чтобы оценить ее. Чашка кофе, в свою очередь, означает «Я устал, давайте передохнем».
Каждому участнику обсуждения выдается по одной колоде карт. Все колоды идентичны друг другу.
Обсуждение проводится следующим образом.
Скрам-мастер, не участвующий в обсуждении, ведет собрание.
Владелец продукта представляет краткие обзоры каждого из пунктов. Команда может задавать вопросы и вести обсуждение предложений и рисков. Итог обсуждения записывается скрам-мастером. Участники выбирают по одной карте и кладут их рубашкой вверх, показывая таким образом, что выбор сделан. Числовые достоинства карт могут использоваться по-разному: они могут означать количество дней, наиболее подходящие дни или относительные единицы сложности (англ. story points).
Каждый участник называет свою карту и переворачивает ее.
Участникам с высокими и низкими оценками дается возможность высказаться и обосновать свою оценку. Процесс обсуждения продолжается до тех пор, пока не будет достигнут консенсус. Голос участника, который, скорее всего, будет владеть разработкой, имеет больший вес в «голосовании на основе консенсуса».
Таймер используется для обеспечения структурированности обсуждения; скрам-мастер может в любое время перезапустить таймер, по истечении времени все обсуждения должны быть прекращены, затем начинается новый круг покера.
SCRUM-мастер[5] задает каждому члену SCRUM-команды три вопроса:
Если коллектив больше 11 человек то команда больше рекомендуемого SCRUM размера. Для расширения SCRUM предложена методика SCRUM of SCRUMs[23].
Тогда коллектив разбивается на несколько SCRUM-команд. В каждой cвой скрам-мастер и скрам-владелец продукта.
Команды проводят Daily SCRUM.
После ежедневного скрам-совещания проводится митинг SCRUM of SCRUMs (SoS[24]). Это значит следующее. От каждой команды выбирается по представителю. Представители разбиваются по 5-9 человек. Каждой группе назначается главный скрам-мастер (Chief SCRUM Master[25]) и главный скрам-владелец продукта (Chief SCRUM Product Owner[26]) из числа скрам-мастеров и скрам-владельцев продукта, участвующих в проекте. Команда представителей из разных SCRUM Team называется SCRUM of SCRUMs Team[27]. В таком составе проводят 15-минутный стоячий скрам-митинг — SCRUM of SCRUMs (SoS) или Meta SCRUM или Scaled Daily SCRUM(SDS)[28].
Кен Швабер рекомендует проводить SCRUM of SCRUMs каждый день[29].
Однако некоторые команды SCRUM of SCRUMs проводят не каждый день, а 2—3 раза в неделю[29]. Это нарушает базовые принципы SCRUM и является классическим примером SCRUMbut[30][31]. Это не позволяет в полной мере использовать все преимущества SCRUM[32].
SCRUM of SCRUMs позволяет нескольким скрам-командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Главный скрам-мастер задает всем членам SCRUM of SCRUMs-команды четыре вопроса[29], три первых вопроса повторяют вопросы Daily SCRUM:
Если SCRUM of SCRUMs не охватывает весь коллектив, может быть проведен митинг SCRUM of SCRUM of SCRUMs (SCRUM-3, SoSoS)[33], SCRUM of SCRUM of SCRUM of SCRUMs (SCRUM-4, SoSoSoS[34])[35], и так далее[36]. Последний MetaSCRUM называется Executive Meta SCRUM(EMS) или Executive Action Team(EAT). Такой подход позволяет всего за час организовать работу 4096 человек[35].
Порядок проведения SCRUM of SCRUMs такой же как у Daily SCRUM[27] -
Проводится в конце спринта.
Беклог отправляется в парикмахерскую для того, чтобы скрам-команда и владелец продукта могли[37]:
Проводится в конце спринта.
В SCRUM важнейшую роль играют квалифицированные SCRUM Master, SCRUM Product Owner и SCRUM Team. Основатели SCRUM и сертифицированные тренеры (CST) проводят обучающие курсы с последующей сертификацией специалистов по SCRUM. Обязательную основу для всех составляют навыки скрам-мастера. Далее идет специализация на SCRUM Master, SCRUM Product Owner и SCRUM Developer (член SCRUM Team). Успешно сдавшим экзамен выдаются сертификаты: Certified SCRUM Master (CSM), Certified SCRUM Product Owner (CSPO), Certified SCRUM Developer (CSD), Professional SCRUM Master (PSM), Professional SCRUM Product Owner (PSPO), Professional SCRUM Developer (PSD).
Возможно дальнейшее обучение с выдачей сертификата тренера по SCRUM — Certified SCRUM Trainer (CST) или Professional SCRUM Trainer (PST). К сертификации на CST допускаются лица, имеющие сертификат CSM или CSPO[38].
В рамках сертификации PST выделяются тренеры скрам-мастеров (PSSMT), скрам-владельцев продукта (PSPOT) и скрам-разработчиков (PSDT)[39][40] [41]. Для допуска к курсам тренеров — train-the-trainer (TTT) и сертификации требуются:
Только следуя всем правилам SCRUM, можно прийти к успеху проекта. Каждый принцип SCRUM приносит прибыль, а отказ от него — убыток. В этом заключается особенность SCRUM.
SCRUMbut — это использование лишь части принципов SCRUM, сохраняя убежденность в работе по SCRUM[30][31]. Это не только не позволяет в полной мере использовать все преимущества SCRUM[30], но и ухудшает производительность по сравнению с полным отсутствием методологии.
Исследования показали, что SCRUMbut снижает ежегодную прибыль с 400 % до 0—35 %[32]. При этом за 100 % принята производительность работы по «водопаду», а за 400 % — по SCRUM. Большое исследование причин и последствий SCRUMbut проведено в работе «ScrumBut in Professional Software Development»[42].
Классические примеры SCRUMbut[30]:
Большое число примеров SCRUMbut приведено на сайте Джеффа Сазерленда — SCRUM ALLIANCE[43].
Кроме классической методики SCRUM of SCRUMs (SoS) применяют методики LeSS[44][45][46][47] (от 2 до 8 команд), Nexus[48], RAGERAGE | Scaled Agile Transformations | Process | cPrime</ref>, DAD[49], APM[50][51], SAFe[52]. Для очень больших проектов вместо LeSS применяют LeSS Huge[45](8+ команд). Только методики SoS[53] и Nexus[54] созданы Сазерлендом и Швабером[45] и преподаются на сертификационных курсах CSM и PSM.
Данная страница на сайте WikiSort.ru содержит текст со страницы сайта "Википедия".
Если Вы хотите её отредактировать, то можете сделать это на странице редактирования в Википедии.
Если сделанные Вами правки не будут кем-нибудь удалены, то через несколько дней они появятся на сайте WikiSort.ru .