Сборник словарей и энциклопедий → Фразеологический словарь русского языка → Слова на букву «К» в Фразеологическом словаре русского языка → КАК СНЕЖНЫЙ КОМ в Фразеологическом словаре русского языка

КАК СНЕЖНЫЙ КОМ — это

---

---

КАК СНЕЖНЫЙ КОМ

нарастать, расти и под.

Стремительно быстро и увеличиваясь в размерах.

Имеется в виду, что проявление чьих-л. чувств, желаний, количество дел (Р) неумолимо возрастает. Говорится с неодобрением, если действие представляется говорящему нежелательным. реч. стандарт. ? Р росло как снежный ком.

неизм.

Обычно с глаголами несов. в.

В роли обст.

Порядок слов-компонентов фиксир.

Отвращение к самому себе нарастало как снежный ком. Караван историй, 2001.Спортивным журналистам различных телеканалов после того, как с эстафеты сняли женскую команду, удалось так быстро «накрутить» население, что остаётся только удивляться, насколько наши люди заждались этого призывного клича: наших бьют! Возмущение в стране нарастало как снежный ком. МК, 2002.

Ничего ведь не нужно делать. Отнял чужое — и всё. А дальше это желание нарастает как снежный ком, который катится до кладбища и подминает под себя всё. МК-Бульвар, 2001.

Недовольство учителей росло, как снежный ком, назревал скандал. И, наконец, меня вызвали на педсовет. Н. Евдокимов, Страстная площадь.

— Мне кажется, что мои неприятности начинают расти, как снежный ком. — Напротив, — возразил Дронго. — Вы раскроете несколько убийств. <…> Разве это плохо? Ч. Абдуллаев, Резонёр.

Долги перед коммунальными службами растут как снежный ком. МК, 2002.

И, как снежный ком, катясь, растёт — так росло, росло Рождество, подвигаясь, как горящий куст, как зимняя радуга, — пока не подходило так близко, что опрокидывалось над залой — сверкающей ёлкой <…>. А. Цветаева, Неисчерпаемое.

— Только что уволились двое моих секретарей, так что дела наворачиваются как снежный ком. Справитесь? С. Шелдон, Звёзды сияют с небес.

культурологический комментарий:

фразеол. восходит к древнейшим формам осознания мира и соотносится через компонент снежный (от снег) со стихийно-природным кодом культуры, т. е. с совокупностью наименований явлений природы, функционирующих в роли знаков «языка» культуры.

В основе образа фразеол. лежит природная метафора, в которой нарастающие чувства, эмоции, события и под. уподобляются стремительно катящемуся с горы и неизбежно увеличивающемуся снежному потоку (ко/му), представляющему потенциальную опасность, что служит поводом для отрицательной оценки в образе фразеол.

Для современного городского жителя образ фразеол., вероятно, связан с лепкой снеговика.

фразеол.

Жизненный цикл ПО. Scrum шаг за шагом

в целом выполняет роль эталона, т. е. меры, быстро нарастающих, как правило, негативных чувств, ощущений, событий.

автор:

И. В. Захаренко

Большой фразеологический словарь русского языка. — М.: АСТ-Пресс.

Е.Н. Телия.

2006.

---

---

Ссылки на страницу

• Прямая ссылка: http://1slovar.ru/phrase_dictionary/5140/;
• HTML-код ссылки: <a href=’http://1slovar.ru/phrase_dictionary/5140/’>Что означает КАК СНЕЖНЫЙ КОМ в Фразеологическом словаре русского языка</a>;
• BB-код ссылки: [url=http://1slovar.ru/phrase_dictionary/5140/]Определение понятия КАК СНЕЖНЫЙ КОМ в Фразеологическом словаре русского языка[/url].

В Скраме есть два важных компонента: Бэклог Продукта и Бэклог Спринта. Часто их путают и не понимают, зачем они вообще нужны.

Атрибуты Scrum

Мы составили мегатаблицу, чтобы разложить всё по полочкам.

Что такое

Бэклог Продукта Единственный упорядоченный список требований к Продукту, то есть перечень всех возможностей и фич, которые заинтересованные люди хотят увидеть в Продукте.

Бэклог Спринта Список дел по воплощению в жизнь выбранных элементов Бэклога Продукта, то есть перечень улучшений, которые Команда будет делать в ближайший Спринт, и описание, как именно они будут эти улучшения реализовывать.

Как выглядят

Как угодно, лишь бы было удобно Команде. Чаще всего это табличка в Excel, доска со стикерами, виртуальная доска в Trello или Jira.

Что содержат	Бэклог Продукта Новые характеристики или функции Продукта.	Бэклог Спринта Конкретные шаги по достижению Цели Спринта.
Компания «Бойцовский клуб» организует трансляцию боксёрских поединков. У них есть сайт, где пользователи смотрят записи старых боёв и прямые трансляции. Эдакий ютуб для боксёров.
В Бэклоге Продукта «Бойцовского клуба» самый большой приоритет у следующей задачи: дать пользователям возможность делать ставки на боксёров, чтобы получить дополнительную прибыль.	В Бэклоге Спринта Команда разделяет большую задачу по ставкам на конкретные шаги: — добавить новый раздел на сайт; — прикрутить онлайн-платежи; — придумать, как перечислять деньги победителям; — протестировать, как работает; — собрать обратную связь.

Кто составляет

Бэклог Продукта За него отвечает Владелец Продукта.

Бэклог Спринта Его составляет Команда Разработки.

Кто влияет на содержание

Владелец Продукта. Он может принимать во внимание мнение стейкхолдеров и клиентов, но окончательное решение и ответственность за Бэклог Продукта лежит только на нём.

Команда Разработки. Кроме неё никто не может добавить или убрать задачи из Бэклога Спринта.

Когда создают

На самом первом Планировании Спринта.

На каждом Планировании Спринта.

Когда изменяют

На Планировании Спринта, Обзоре Спринта или Уточнении Бэклога Продукта (PBR) меняется порядок элементов в Бэклоге Продукта и степень их детализации. Могут добавляться новые идеи, старые могут убираться из списка.

Бэклог Спринта меняется хоть ежедневно, в зависимости от скорости работы Команды. Важно: изменения появляются из-за того, что в ходе работы Команда разбивает задачи на более мелкие или понимает, что потребуется сделать что-то ещё для достижения Цели Спринта.

Сколько существуют

Бэклог Продукта Пока жив Продукт.

Бэклог Спринта Живёт один Спринт (1–4 недели).

Сколько команд используют

Бэклог Продукта один независимо от количества команд. 1 Продукт — 1 Бэклог Продукта — много команд.

У каждой команды свой Бэклог Спринта. Если у нас пять команд, то Бэклогов Спринта будет пять. 1 Продукт — много Бэклогов Спринта — много команд.

Завершают ли в Спринте

Нет, пока Продукт есть на рынке, в Бэклоге Продукта будут появляться новые элементы.

Да, в идеале все элементы Бэклога Спринта выполняются за Спринт.

Как детализируют

Элементы вверху Бэклога Продукта детализированы лучше, чем те, которые внизу.

Все элементы Бэклога Спринта детализированы примерно одинаково.

Надеемся, вам стало понятнее, что это за Бэклоги и с чем их едят.

Повторим короткой строкой:

1. Бэклог Продукта — это список планируемых улучшений Продукта, расставленных по приоритету. Его составляет Владелец Продукта с учётом мнения стейкхолдеров и клиентов. Бэклог Продукта существует, пока жив Продукт.
2. Бэклог Спринта — это список дел на Спринт, который составляет Команда Разработки. В Бэклоге Спринта Команда описывает конкретные шаги, с помощью которых она воплотит в жизнь элементы Бэклога Продукта. Каждый Спринт Команда создаёт новый Бэклог Спринта.

Самое важное

Запомнить Бэклог Продукта — это список планируемых улучшений Продукта, расставленных по приоритету. Бэклог Спринта — это список конкретных шагов по воплощению в жизнь выбранных элементов Бэклога Продукта.

Говорить правильно Бэклог Продукта Бэклог Спринта Узнать больше Руководство по Скраму (ПДФ, 1 МБ)

Текст: Катя Кондратьева

автор : eugene

Методология разработки Scrum

Scrum (skrʌm «схватка») — это методология управления проектами. Основной акцент использования данной методология делается на качественном контроле процесса разработки. Scrum является одной из наиболее популярных «методологий» разработки ПО. Кроме управления проектами по разработке ПО, Scrum может также использоваться и по сопровождению программ.

В статье «The New Product Development Game» (Гарвардский Деловой Обзор, январь-февраль 1986) Хиротака Такэути и Икудзиро Нонака отметили, что проекты, над которыми работают небольшие команды из специалистов, как правило, производят лучшие результаты. Они сослались на «подход регби» Scrum (толкотня, схватка вокруг мяча).

Впервые метод Scrum был представлен на общее обозрение задокументированным, чётко сформированным и описанным совместно Швабером и Джефом Сазерлендом, которые на протяжении следующих лет работали вместе, чтобы описать и представить весь их опыт и лучшие практические образцы для управления проектами в одно целое, в ту методологию, что известна сегодня как Scrum.

Использование Scrum предполагает на этапе планирования разделить проект разработки ПО на несколько фиксированных небольших по времени итераций, иначе называемые спринтами Sprint. Каждая последовательная итерация согласно её приоритету завершается предоставлением конечному пользователю работающего ПО с новыми возможностями. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.

Процесс управления проектом Scrum

Терминология проекта Scrum

• Sprint — этап разработки;
• Sprint backlog — задачи по этапу разработки;
• Project backlog — cписок требований к функциональности.

Итерация Sprint

Основой Scrum является Sprint — этап разработки, в течении которого выполняется определенная работа над продуктом. Полная разработка проекта состоит из коротких этапов Sprint’ов. Функции, которые нужно реализовать на каждом Sprint’е, строго фиксированы и их нельзя менять по ходу спринта; они разбиты на задачи, имеющие оценки и приоритеты.

Перед началом каждого Sprint’а производится Sprint planning, на котором оценивается содержимое Project backlog и формируется Sprint backlog, содержащий задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, являющуюся мотивирующим фактором, которую можно достичь с помощью выполнения задач из Sprint backlog.

Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении всей жизни продукта. По окончанию Sprint’а должна быть получена новая рабочая, но не окончательная, версия продукта.

Список требований проекта Project backlog

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

В классическом Scrum подразумевается, что заказчик проекта может вносить любые изменения прямо по ходу проекта, но не в текущий Sprint. В большинстве случаев бюджет разработки ПО зафиксирован.

Scrum на простом языке

А это значит, что и возможности Заказчика влиять на ход выполнения тоже ограничены. Тем не менее, при необходимости можно оформить «Дополнительное соглашение» к договору с учетом изменения финансовой составляющией проекта поскольку потребность добавлять или менять какие-либо функции проекта для Заказчика очень актуальна. Это способствует разработке нужного клиенту проекта, а не того, что формально представлено в ТЗ.

Поэтому, в качестве Backlog’а, как правило, используется перечень задач из технического задания, очерченных и закрепленных в договоре, плюс фиксированные в доп-соглашениях доработки, возникающие по ходу работы.

Список требований спринта Sprint backlog

Журнал пожеланий спринта Sprint backlog содержит функциональность проекта для определенного этапа Sprint’a.

Роли в управлении проектом Scrum

По методике Scrum в производственном процессе есть определённые роли, разбитые на 2 группы « свиней» и «кур». Эти названия были использованы вследствии следующей распространенной шутки :

Курица предлагает свинье: «А давай откроем ресторан!» Свинья удивленно смотрит на курицу и отвечает: «Идея хорошая, а как ты хочешь его назвать?» Курица недолго думает и отвечает : «Почему бы не назвать ‘Яичница с беконом’?».
«Так не пойдёт, — отвечает свинья, — ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично».

Согласно Scrum «Свиньи» создают продукт, в то время как «куры» не настолько заинтересованы в готовом продукте. Им всё равно, будет ли проект удачным или нет, на них это мало отразится. Поэтому требования, пожелания и идеи «кур» принимаются во внимание, но им не разрешают непосредственно включаться в ход Scrum-проекта.

Классический Scrum использует 3 базовых роли («Свиньи») :

• Product owner (PO) — владелец продукта представляет интересы заказчика в проекте.
  PO является не членом команды разработчиков, а связующим звеном между командой разработчиков и заказчиком, т.е. это должен быть представитель заказчика. Поскольку роль накладывает высокие требования к опыту и компетенции индивида в сфере разработки и развития проекта, а также требует постоянного личного участия в проекте (что не всегда возможно для заказчика), то данную роль, как правило, выполняет менеджер проекта.
• Scrum master (SM) «служащий лидер» — член команды, следящий за соблюдением принципов Scrum.
  Роль SM не предполагает каких-то дополнительных полномочий по проекту. Задача SM — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучении и мотивации команде, оказание помощи PO.
• Development team (DT) — команда разработчиков.
  Команда разработчиков состоит из специалистов, выполняющих непосредственную работу над проектом. Согласно «The Scrum Guide» DT должна обладать следующими качествами :
  • должна быть самоорганизующейся. Никто (включая SM и PO) не может указывать DT каким образом преобразовать Project backlog в работающий продукт;
  • должна быть многофункциональной и обладать всеми необходимыми навыками для создания работающего продукта;
  • должна отвечать за проект вся команда, а не отдельные её члены.

  Рекомендуемый размер команды DT, как правило составляет 6…8 человек. Согласно идеологам Scrum, команда большего размера требует слишком больших ресурсов на коммуникации, в то время как команда меньшего размера повышает риски (в виду возможного отсутствия требуемых навыков) и уменьшает размер работы, который можно выполнить за определенный отрезок времени.

Дополнительные роли (Ancillary roles) в методологии Scrum («Куры») :

• клиенты Stakeholders — лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в Scrum только во время обзорного совещания по спринту Sprint Review;
• управляющие персоналом Managers;
• эксперты-консультанты Consulting Experts.

Работа по этапам

Основная задача Product Owner’а связана с поддержкой в актуальном состоянии списка задач по проекту Backlog и правильной расстановкой приоритетов согласно бизнес-целям проекта. При этом в Backlog попадают, как правило, не мелкие задачи, типа изменить интерфейс формы, а более крупные бизнес-задачи, например «реализовать единую авторизацию через социальные сети».

В начале каждого этапа команда набирает себе из списка Project backlog столько задач, сколько способна реально выполнить за этап Sprint’a. Разбивает на подзадачи и уточняет сроки.

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

В начале новой итерации Sprint’a необходимо выполнить соответствующее планирование. Для этого из Backlog’a проекта выбираются задачи, которые за Sprint команда DT должна выполнить. На основе выбранных задач создается Backlog Sprint’a.

Каждую задачу спринта необходимо оценить в идеальных человеко-часах. Решение задачи должно занимать от 8 до 16 часов, т.е. не более двух рабочих дней. При необходимости задачу можно разбить на подзадачи.

Во время планирования обсуждается и определяется порядок реализации всего объёма работ. Продолжительность совещания имеет строгие ограничения (не более одного рабочего дня) и зависит от продолжительности итерации и опыта команды.

Ежедневный контроль, Daily meetings

Daily meetings, иначе называемый Stand-up Meeting проводится каждый день. На протяжении всего Sprint’a команда регулярно собирается в одно и то же время. Каждый член команды DT должен ответить на три вопроса :

• Что было сделано вчера?
• Что будет сделано сегодня?
• Какие есть проблемы?

При проведении Daily-Meeting важно не опуститься до обсуждения технических деталей проекта, либо формального выяснения статуса проекта.

Остановка спринта, Abnormal Termination

Остановка спринта раньше запланированного срока может быть произведена в исключительных ситуациях. Если команда понимает, что не может достичь цели спринта в отведённое время, то она может остановить Sprint. Также спринт может остановить владелец проекта, если исчезает необходимость в реализации цели спринта.

После остановки спринта проводится совещание с командой DT, где обсуждаются причины остановки. После этого команда переходит к выполнению очередного Sprint’a.

Диаграмма сгорания задач Burndown chart

Для наглядного представления состояния проекта используется диаграмма сгорания задач Burndown chart, демонстрирующая количество проделанной и оставшейся работы относительно всего времени, выделенного на разработку проекта. Диаграмму необходимо регулярно (ежедневно) обновлять, чтобы в реальном времени показывать подвижки и издержки в работе над спринтом и проектом. Burndown chart должна быть доступна для всех членов проекта.

Существуют два вида диаграммы :

• диаграмма сгорания работ для спринта, представляющая объем выполненных и невыполненных задач в текущем спринте;
• диаграмма сгорания работ для проекта, представляющая объем выполненных и невыполненных задач готового программного продукта (обычно строится на основе нескольких спринтов).

Особенности Scrum-проекта

1.

В Scrum-проекте изменения в требования можно вносить в любой момент.
Таким образом можно менять Product backlog по ходу выполнения. Это затрудняет использование принципов Scrum в fixed-cost/fixed-time проектах. Идеология Scrum утверждает, что заранее невозможно предусмотреть все изменения, поэтому нет смысла заранее планировать весь проект, ограничившись только just-in-timе планированием, т. е. планированием только тех работ, которые должны быть выполнены в ближайших Sprint’ах.

2. В Scrum-проекте главным источником достоверной информации является эмпирический опыт участников.
В «The Scrum Guide» говорится о необходимости полного и точного выполнения положений Scrum в виду отсутствия формального лидера и руководителя.

3. Мотивация команды играет важную роль в успехе Scrum-проекта.
Одним из основных принципов Scrum-проекта являются наличие многофункциональной и самоорганизующейся команды разработчиков DT. Исследования социологов показывают, что численность самомотивированных сотрудников, способных на самоорганизацию не велика. Таким образом, лишь небольшая часть сотрудников способна эффективно работать в Scrum-проекте без существенных изменений в ролях, что приводит к неверному использованию принципов Scrum.

Плюсы и минусы Scrum-проекта

Одним из главных плюсов, с точки зрения Заказчика, является быстрый запуск Srcum-проекта с самыми приоритетными функциями и минимально возможным бюджетом. Таким образом, Scrum ориентирован на клиента. Scrum предоставляет клиенту возможность вносить изменения в требования в любой момент времени, но не гарантирует, что эти изменения будут выполнены. Возможность изменения требований привлекательна для многих заказчиков ПО. Кроме этого, Scrum упрощает контроль за ходом выполнения работ.

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

Важной слабостью Scrum является создание многофункциональной самоорганизующейся команды. Формирование эффективной команды разработчиков для Scrum-проекта часто сопряжено с отсутствием соответствующих специалистов (знания + опыт + зарплата) как в компании, так и на рынке труда.

Следует отметить, что Scrum не подходит для выполнения Гос-заказов, где до начала разработки ПО должно быть все согласовано, т.е. сформировано ТЗ и определены требования, установлены сроки по этапам и утвержден бюджет.