Жас ғалымдардың VII халықаралық Ғылыми конференциясының материалдары 25-26 сәуір 2011 жыл

 
93 
Полученный  от  физического  источника  шум  затем  "дистиллируется"  криптографической 
хэш-функцией  так,  чтобы  каждый  бит  зависел  от  каждого  бита.  Достаточно  часто  для 
хранения случайной информации используется довольно большой пул (несколько тысяч бит) 
и  каждый  бит  пула  делается  зависимым  от  каждого  бита  шумовой  информаци  и  каждого 
другого бита пула криптографически надежным (strong) способом.  
Когда  нет  настоящего  физического  источника  шума,  приходится  пользоваться 
псевдослучайными  числами.  Такая  ситуация  нежелательна,  но  часто  возникает  на 
компьютерах  общего  назначения.  Всегда  желательно  получить  некий  шум  окружения  --- 
скажем  от  величины  задержек  в  устройствах,  цифры  статистики  использования  ресурсов, 
сетевой  статистики,  прерываний  от  клавиатуры  или  чего-то  иного.  Задачей  является 
получить  данные,  непредсказуемые  для  внешнего  наблюдателя.  Для  достижения  этого 
случайный пул должен содержать как минимум 128 бит настоящей энтропии.  
Криптографические генераторы псевдослучайных чисел обычно используют большой 
пул  (seed-значение),  содержащий  случайную  информацию.  Биты  генерируется  путем 
выборки  из  пула  с  возможным  прогоном  через  криптографическую  хэш-функцию,  чтобы 
спрятать содержимое пула от внешнего наблюдателя. Когда требуется новая порция бит, пул 
перемешивается  путем  шифровки  со  случайным  ключом  (его  можно  взять  из 
неиспользованной пока части пула) так, чтобы каждый бит пула зависел от каждого другого 
бита.  Новый  шум  окружения  должен  добавляться  к  пулу  перед  перемешиваниям,  дабы 
сделать предсказание новых значений пула еще более сложным.  
Имеется  множество  других  криптографических  атак  и  криптоаналитических 
подходов.  Однако  приведенные  выше  являются,  наиболее  важными  для  практической 
разработки систем. 
Литература 
1.Салома А. Криптография с открытым ключом. Пер. с англ. - М.: Мир, 1996.-304с. 
2.  Расторгуев  С.П.  Программные  методы  защиты  информации  в  компьютерах  и  сетях. 
Издательство агентства «Яхтсмен » М.-, 1991. -368с 
3.  Петpаков  А.В.  Основы  практической  защиты  инфоpмации  [Текст]:  Учебное 
пособие/МОРФ.-4-е изд., доп.-М.: СОЛОН-Пpесс,2005.-384с.  
 
 
УДК 004.424 
 
ТЕОРЕТИЧЕСКИЕ ОСНОВЫ ТРЕХМЕРНОГО МОДЕЛИРОВАНИЯ 
 
Абенова Айнур Алтынбековна 
магистрант, КРУ, г. Астана 
Научный руководитель - к.ф.м.н., доцент Шаханова Г.А.  
 
В  последние  годы  особенно  широко  используется  во  всех  областях  человеческой 
деятельности метод моделирования, как средство познания. 
Моделирование  —  исследование  объектов  познания  на  их  моделях;  построение  и 
изучение  моделей  реально  существующих  предметов,  процессов  или  явлений  с  целью 
получения  объяснений  этих  явлений,  а  также  для  предсказания  явлений,  интересующих 
исследователя. 
Виды моделирования 
В  силу  многозначности  понятия  «модель»  в  науке  и  технике  не  существует  единой 
классификации  видов  моделирования:  классификацию  можно  проводить  по  характеру 
моделей,  по  характеру  моделируемых  объектов,  по  сферам  приложения  моделирования  (в 
технике,  физических  науках,  кибернетике  и т. д.).  Например,  можно  выделить  следующие 
виды моделирования: 

 
Информационное моделирование 

 
94 

 
Компьютерное моделирование 

 
Математическое моделирование 

 
Математико-картографическое моделирование 

 
Молекулярное моделирование 

 
Цифровое моделирование 

 
Логическое моделирование 

 
Педагогическое моделирование 

 
Психологическое моделирование 

 
Статистическое моделирование 

 
Структурное моделирование 

 
Физическое моделирование 

 
Экономико-математическое моделирование 

 
Имитационное моделирование 

 
Эволюционное моделирование и т. д. 
Процесс моделирования 
Процесс моделирования включает три элемента: 

 
субъект (исследователь), 

 
объект исследования, 

 
модель,  определяющую  (отражающую)  отношения  познающего  субъекта  и 
познаваемого объекта. 
Первый этап построения модели предполагает наличие некоторых знаний об объекте-
оригинале.  Познавательные  возможности  модели  обусловливаются  тем,  что  модель 
отображает (воспроизводит, имитирует) какие-либо существенные черты объекта-оригинала. 
Вопрос  о  необходимой  и  достаточной  мере  сходства  оригинала  и  модели  требует 
конкретного анализа.  Модель  утрачивает свой смысл как в случае тождества  с оригиналом 
(тогда  она  перестает  быть  моделью),  так  и  в  случае  чрезмерного  во  всех  существенных 
отношениях  отличия  от  оригинала.  Таким  образом,  изучение  одних  сторон  моделируемого 
объекта осуществляется ценой отказа от исследования других сторон. Поэтому любая модель 
замещает  оригинал  лишь  в  строго  ограниченном  смысле.  Из  этого  следует,  что  для  одного 
объекта 
может 
быть 
построено 
несколько 
«специализированных» 
моделей, 
концентрирующих  внимание  на  определенных  сторонах  исследуемого  объекта  или  же 
характеризующих объект с разной степенью детализации. 
На втором этапе модель выступает как самостоятельный объект исследования. Одной 
из  форм  такого  исследования  является  проведение  «модельных»  экспериментов,  при 
которых  сознательно  изменяются  условия  функционирования  модели  и  систематизируются 
данные  о  ее  «поведении».  Конечным  результатом  этого  этапа  является  множество 
(совокупность) знаний о модели. 
На  третьем  этапе  осуществляется  перенос  знаний  с  модели  на  оригинал — 
формирование  множества  знаний.  Одновременно  происходит переход  с  «языка»  модели  на 
«язык» оригинала. Процесс переноса знаний проводится по определенным правилам. Знания 
о модели должны быть скорректированы с  учетом тех свойств объекта-оригинала, которые 
не нашли отражения или были изменены при построении модели. 
Четвертый этап — практическая проверка получаемых с помощью моделей знаний и 
их  использование  для  построения  обобщающей  теории  объекта,  его  преобразования  или 
управления им. 
Моделирование  —  циклический  процесс.  Это  означает,  что  за  первым 
четырехэтапным  циклом  может  последовать  второй,  третий  и т. д.  При  этом  знания  об 
исследуемом  объекте  расширяются  и  уточняются,  а  исходная  модель  постепенно 
совершенствуется.  Недостатки,  обнаруженные  после  первого  цикла  моделирования, 
обусловленные  малым  знанием  объекта  или  ошибками  в  построении  модели,  можно 
исправить в последующих циклах. 
Как частный случай рассмотрим трехмерное компьютерное моделирование. 

 
95 
Области  применения  трехмерного  компьютерного  моделирования  необычайно 
широки:  создание  персонажей,  игр,  виртуальных  игр,  рекламы.  Классическим  примером 
использования  графического  редактора  3ds  Max  является  трехмерное  моделирование 
интерьеров. 
Трехмерное моделирование — это пространственное изображение любого объекта в 
трехмерной  системе  координат,  дающее  возможность  максимально  информативно,  точно  и 
реалистично  представить  его  форму,  текстуру,  размер  и  цвет.  Трехмерная  модель  объекта 
позволяет рассмотреть его с любого интересующего ракурса. 
Двумерные  чертежи  изделия,  различные  технические  документы  в  бумажной  форме 
не могут дать столь точное и наглядное представление об изделии, как его 3D модель. 
Трѐхмерная графика (3D, 3 Dimensions, русск. 3 измерения) — раздел компьютерной 
графики,  совокупность  приемов  и  инструментов  (как  программных,  так  и  аппаратных), 
предназначенных  для  изображения  объѐмных  объектов.  Больше  всего  применяется  для 
создания изображений на плоскости экрана или листа печатной продукции в  архитектурной 
визуализации,  кинематографе,  телевидении,  компьютерных  играх,  печатной  продукции,  а 
также в науке и промышленности. 
Трѐхмерное  изображение на плоскости отличается от  двумерного тем, что включает 
построение  геометрической  проекции  трѐхмерной  модели  сцены  на  плоскость  (например, 
экран компьютера) с помощью специализированных программ. При этом модель может, как 
соответствовать  объектам  из  реального  мира  (автомобили,  здания,  ураган,  астероид),  так  и 
быть полностью абстрактной (проекция четырѐхмерного фрактала). 
Для получения трѐхмерного изображения на плоскости требуются следующие шаги: 

 
моделирование — создание трѐхмерной математической модели сцены и объектов 
в ней. 

 
рендеринг  (визуализация)  —  построение  проекции  в  соответствии  с  выбранной 
физической моделью. 

 
вывод полученного изображения на устройство вывода - дисплей или принтер. 

 
Сцена  (виртуальное  пространство  моделирования)  включает  в  себя  несколько 
категорий объектов: 

 
Геометрия (построенная с помощью различных техник модель, например здание) 

 
Материалы  (информация  о  визуальных  свойствах  модели,  например  цвет  стен  и 
отражающая/преломляющая способность окон) 

 
Источники света (настройки направления, мощности, спектра освещения) 

 
Виртуальные камеры (выбор точки и угла построения проекции) 

 
Силы и воздействия (настройки динамических искажений объектов, применяется в 
основном в анимации) 

 
Дополнительные  эффекты  (объекты,  имитирующие  атмосферные  явления:  свет  в 
тумане, облака, пламя и пр.) 
Задача трѐхмерного моделирования  — описать эти объекты и разместить их в сцене с 
помощью  геометрических  преобразований  в  соответствии  с  требованиями  к  будущему 
изображению. 
Программное обеспечение 
Программные  пакеты,  позволяющие  создавать  трѐхмерную  графику,  то  есть 
моделировать  объекты  виртуальной  реальности  и  создавать  на  основе  этих  моделей 
изображения,  очень  разнообразны.  Последние  годы  устойчивыми  лидерами  в  этой  области 
являются  коммерческие  продукты:  такие  как  3ds  Max,  Maya,  Lightwave  3D,  SoftImage  XSI, 
Sidefx  Houdini,  Maxon  Cinema  4D  и  сравнительно  новые  Rhinoceros  3D,  modo,  Nevercenter 
Silo или ZBrush.  
Трехмерная графика активно применяется в системах автоматизации проектных работ 
(САПР)  для  создания  твердотельных  элементов:  зданий,  деталей  машин,  механизмов,  а 
также  в  архитектурной  визуализации  (сюда  относится  и  так  называемая  "виртуальная 

 
96 
археология").  Широко  применяется  3D  графика  и  в  современных  системах  медицинской 
визуализации. 
Трѐхмерная графика обычно имеет дело с виртуальным, воображаемым трѐхмерным 
пространством,  которое  отображается  на  плоской,  двухмерной  поверхности  дисплея  или 
листа бумаги. 
Программа  3ds  Max  компании  Autodesk  имеет  удобный  интерфейс,  широкий  набор 
инструментов  для  моделирования,  анимации  и  визуализации,  допускает  использование 
дополнительных модулей, расширяющих возможности пакета. С каждой новой версией 3ds 
Max 
становится 
функционально 
полнее, 
появляются 
новые 
возможности 
и 
совершенствуются имеющиеся. 
Результат  работы  с  приложением  3ds  Max  —  сцена,  состоящая  из  геометрических 
объектов, которые являются трехмерными. 
Процесс  создания  реалистичной  трехмерной  сцены  условно  можно  разбить  на  пять 
этапов: 
- моделирование; 
- текстурирование; 
- расстановка освещения; 
- размещение камер; 
- визуализация. 
Рендеринг 
На этом этапе  математическая (векторная) пространственная модель превращается  в 
плоскую  (растровую)  картинку.  Если  требуется  создать  фильм,  то  визуализируется 
последовательность  таких  картинок  —  кадров.  Как  структура  данных,  изображение  на 
экране представлено матрицей точек, где каждая точка определена, по крайней мере, тремя 
числами:  интенсивностью  красного,  синего  и  зелѐного  цвета.  Таким  образом,  рендеринг 
преобразует  трѐхмерную  векторную  структуру  данных  в  плоскую  матрицу  пикселов.  Этот 
шаг  часто  требует  очень  сложных  вычислений,  особенно  если  требуется  создать  иллюзию 
реальности.  Самый  простой  вид  рендеринга  —  это  построить  контуры  моделей  на  экране 
компьютера с помощью проекции, как показано на Рисунке 1.  
 
 
Рисунок 1. Схема проецирования сцены на экран компьютера 
 
Обычно  этого  недостаточно  и  нужно  создать  иллюзию  материалов,  из  которых 
изготовлены объекты, а также рассчитать искажения этих объектов за счѐт прозрачных сред 
(например, жидкости в стакане). 
Существует  несколько  технологий  рендеринга,  часто  комбинируемых  вместе. 
Например: 

 
Z-буфер (используется в OpenGL и DirectX 10); 

 
Сканлайн (scanline) — он же Ray casting («бросание луча», упрощенный алгоритм 
обратной трассировки лучей)  —  расчѐт  цвета  каждой точки  картинки  построением  луча  из 
точки зрения наблюдателя через воображаемое отверстие в экране на месте этого пиксела «в 

 
97 
сцену» до пересечения с первой поверхностью. Цвет пиксела будет таким же, как цвет этой 
поверхности (иногда с учѐтом освещения и т. д.); 

 
Трассировка  лучей  (рейтрейсинг,  англ. raytracing)  —  то  же,  что  и  сканлайн,  но 
цвет  пиксела  уточняется  за  счѐт  построения  дополнительных  лучей  (отражѐнных, 
преломлѐнных  и  т.  д.)  от  точки  пересечения  луча  взгляда.  Несмотря  на  название, 
применяется только обратная трассировка лучей. Прямая трассировка крайне неэффективна 
и потребляет слишком много ресурсов для получения качественной картинки; 

 
Глобальное 
освещение 
(англ. global 
illumination, 
radiosity) 
— 
расчѐт 
взаимодействия поверхностей и сред в видимом спектре излучения с помощью интегральных 
уравнений. 
Грань  между  алгоритмами  трассировки  лучей  в  настоящее  время  практически 
стѐрлась.  Так,  в  3D  Studio  Max  стандартный  визуализатор  называется  Default  scanline 
renderer,  но  он  считает  не  только  вклад  диффузного,  отражѐнного  и  собственного  (цвета 
самосвечения)  света,  но  и  сглаженные  тени.  По  этой  причине,  чаще  понятие  Raycasting 
относится к обратной трассировке лучей, а Raytracing — к прямой. 
Наиболее популярными системами рендеринга являются: 

 
PhotoRealistic RenderMan (PRMan) 

 
Mental ray 

 
V-Ray 

 
FinalRender 

 
Brazil R/S и т.д. 
Литература 
1.
 
Маров  М.  Эффективная  работа  в  3ds  MAX  4.  –  С-Петербург-Москва-Харьков-
Минск: 2002. 
2.
 
Пекарев Л. Самоучитель 3D Studio MAX4.-С-Пб.:2001. 
3.
 
Короев Ю.И. Строительное черчение и рисование.- М.:Высшая школа, 1983. 
4.
 
Авдотьин  Л.Н.  Технические  средства  в  архитектурном  проектировании.-
М.:Высшая школа,1986. 
5.
 
Блашкевич  Р.Н.,  ЗвездинаТ.И.  и  др.Интерьер  современной  квартиры.  –
М.:Стройиздат, 1988. 
 
УДК 004.424 
 
ОБЗОР МЕТОДОЛОГИИ SCRUM 
 
Абуова К.С., Варламов О.С. 
Студенты, Евразийский национальный университет им. Л.Н.Гумилева, Астана 
Научный руководитель –  Кинтонова А.Ж. 
 
Одной  из  актуальных  задач  в  сфере  разработки  программных  продуктов  является  
завершение проекта в планированные сроки. Самое оптимальное  решение этой проблемы – 
это  командная  работа,  при  которой  проект  разбивается  на  модули  и  распределяется  между 
членами команды - разработчиками. Важным фактором является целостность всего проекта 
и  контроля  его  реализацией.  Например,  увольнение  одного  из  разработчиков      приводит  к 
потере целых фрагментов  проекта. 
Другой  не  менее  важный  вопрос  –  наличие  методики  реализации  проекта. 
Современные средства разработки позволяют решить эту проблему. Для успешного проекта 
необходимо  постоянное  согласование  действий.  Можно  использовать  почту,  различные 
средства связи, но эффективнее использовать специальный инструментарии. 
Scrum - одна из самых популярных методологий гибкой разработки. Одна из причин 
ее  популярности  -  простота.  Scrum  по-настоящему  прост,  его  можно  описать  в  одной 
короткой статье, что мы и постараемся сделать в этом обзоре.  

 
98 
Принципиальное отличие этой методологии от предыдущих методологий командной 
работы над проектом – это независимое  формирование  работы   каждого члена команды в 
процессе разработки. 
Роли 
В методологии Scrum всего три роли:  

 
Scrum Master 

 
Product Owner 

 
Team. 
Скрам  Мастер  (Scrum  Master)  -  самая  важная  роль  в  методологии.  Скрам  Мастер 
отвечает  за  успех  Scrum  в  проекте.  По  сути,  Скрам  Мастер  является  интерфейсом  между 
менеджментом  и  командой.  Как правило,  эту  роль  в  проекте  играет  менеджер  проекта  или 
тимлид. Важно подчеркнуть, что Скрам Мастер не раздает задачи членам команды. Команда 
является самоорганизующейся и самоуправляемой.  
Основные обязанности Скрам Мастера таковы:  

 
Создает атмосферу доверия 

 
Участвует в митингах в качестве фасилитатора 

 
Устраняет препятствии  

 
Делает проблемы и открытые вопросы видимыми  

 
Отвечает за соблюдение практик и процесса в команде  
Скрам Мастер ведет DailyScrumMeeting и отслеживает прогресс команды при помощи 
SprintBacklog,  отмечая  статус  всех  задач  в  спринте.  ScrumMaster  может  также  помогать 
ProductOwner создавать Backlog для команды. 
ProductOwner  -  это  человек,  отвечающий  за  разработку  продукта.  Как  правило,  это 
productmanager для продуктовой разработки, менеджер проекта для внутренней разработки и 
представитель заказчика для заказной разработки. ProductOwner - это единая точка принятия 
окончательных решений для команды в проекте, именно поэтому это всегда один человек, а 
не группа или комитет.  
Обязанности ProductOwner таковы:  

 
Отвечает за формирование productvision 

 
Управляет ROI  

 
Управляет ожиданиями заказчиков и всех заинтересованных лиц  

 
Координирует и приоритизирует Productbacklog 

 
Предоставляет понятные и тестируемые требования команде  

 
Взаимодействует с командой и заказчиком  

 
Отвечает за приемку кода в конце каждой итерации  
ProductOwner  ставит  задачи  команде,  но  он  не  вправе  ставить  задачи  конкретному 
члену проектной команды в течении спринта. 
 Команда (Team) берет на себя обязательства по выполнению объема работ на спринт 
перед ProductOwner. Работа команды оценивается как работа единой группы. В Scrum вклад 
отдельных  членов  проектной  команды  не  оценивается,  так  как  это  разваливает 
самоорганизацию команды. 
Обязанности команды таковы:  

 
Отвечает за оценку элементов баклога 

 
Принимает решение по дизайну и имплементации  

 
Разрабатывает софт и предоставляет его заказчику  

 
Отслеживает собственный прогресс (вместе со Скрам Мастером).  

 
Отвечает за результат перед ProductOwner 
Размер  команды  ограничивается  размером  группы  людей,  способных  эффективно 
взаимодействовать лицом к лицу. Типичные размер команды - 7 плюс минус 2.  
Команда в Scrum кроссфункциональна. В нее входят люди с различными навыками - 
разработчики,  аналитики,  тестировщики.  Нет  заранее  определенных  и  поделенных  ролей  в 

 
99 
команде,  ограничивающих  область  действий  членов  команды.  Команда  состоит  из 
инженеров,  которые  вносят  свой  вклад  в  общий  успех  проекта  в  соответствии  со  своими 
способностями  и  проектной  необходимостью.  Команда  самоорганизуется  для  выполнения 
конкретных  задач  в  проекте,  что  позволяет  ей  гибко  реагировать  на  любые  возможные 
задачи.  
Для облегчения коммуникаций команда должна находиться в одном месте (colocated). 
Предпочтительно размещать команду не в кубиках, а в одной общей комнате для того, чтобы 
уменьшить  препятствия  для  свободного  общения.  Команде  необходимо  предоставить  все 
необходимое для комфортной работы, обеспечить досками и флипчартами, предоставить все 
необходимые инструменты и среду для работы.  
Артефакты 
ProductBacklog 
ProductBacklog  -  это  приоритезированный  список  имеющихся  на  данный  момент 
бизнес-требований и технических требований к системе. Product Backlog включает в себя use 
cases,  defects,  enhancements,  technologies,  stories,  features,  issues,  и  т.д.  Productbacklog  также 
включает задачи, важные для команды, например "провести тренинг", "добить всем памяти"  
ProductBacklog  постоянно  пересматривается  и  дополняется  -  в  него  включаются 
новые  требования,  удаляются  ненужные,  пересматриваются  приоритеты.  За  ProductBacklog 
отвечает ProductOwner. Он также работает совместно с командой для того, чтобы получить 
приближенную оценку на выполнение элементов ProductBacklog для того, чтобы более точно 
расставлять приоритеты в соответствии с необходимым временем на выполнение.  
SprintBacklog 
SprintBacklog  содержит  функциональность,  выбранную  Product  Owner  из  Product 
Backlog.  Все  функции  разбиты  по  задачам,  каждая  из  которых  оценивается  командой. 
Каждый  день  команда оценивает  объем  работы,  который  нужно  проделать  для  завершения 
задач. 
Сумма оценок оставшейся работы может быть построена как график зависимости от 
времени.  Такой  график  называется  SprintBurndownchart.  Он  демонстрирует  прогресс 
команды по ходу спринта.  
В  Scrum  итерация  называется  Sprint.  Ее  длительность  составляет  1  месяц  (30  дней). 
Результатом  Sprint  является  готовый  продукт  (build),  который  можно  передавать  (deliver) 
заказчику (по крайней мере, система должна быть готова к показу заказчику).  
Короткие спринты обеспечивают быстрый feedback проектной команде от заказчика. 
Заказчик получает возможность гибко управлять scope системы, оценивая результат спринта 
и  предлагая  улучшения  к  созданной  функциональности.  Такие  улучшения  попадают  в 
ProductBacklog,  приоритезируются  наравне  с  прочими  требованиями  и  могут  быть 
запланированы на следующий (или на один из следующих) спринтов.  
Каждый  спринт  представляет  собой  маленький  "водопад".  В  течение  спринта 
делаются все работы по сбору требований, дизайну, кодированию и тестированию продукта. 
Scope спринта должен быть фиксированным. Это позволяет команде давать обязательства на 
тот объем работ, который должен быть сделан в спринте. Это означает, что SprintBacklog не 
может быть изменен никем, кроме команды.  
Жизненный цикл спринта 
Планирование спринта 
В  начале  каждого  спринта  проводится  планирование  спринта.  В  планировании 
спринта  участвуют  заказчики,  пользователи,  менеджмент,  ProductOwner,  Скрам  Мастер  и 
команда. 
Планирование спринта состоит из двух последовательных митингов: 

 
Планирование спринта, митинг первый 
Участники: команда, ProductOwner, ScrumMaster, пользователи, менеджмент. 

 
100 
Цель:  Определить  цель  спринта  (SprintGoal)  и  SprintBacklog  -  функциональность, 
которая  будет  разработана  в  течение  следующего  спринта  для  достижения  цели  спринта. 
Артефакт: SprintBacklog 

 
Планирование спринта, митинг второй 
Участники: Скрам Мастер(ScrumMaster), команда (Team) 
Цель: 
определить, 
как 
именно 
будет 
разрабатываться 
определенная 
функциональность  для  того,  чтобы  достичь  цели  спринта.  Для  каждого  элемента 
SprintBacklog определяется список задач и оценивается их продолжительность.  
Артефакт: в SprintBacklog появляются задачи  
Если  в  ходе  спринта  выясняется,  что  команда  не  может  успеть  сделать 
запланированное  на  спринт,  то  Скрам  Мастер,  ProductOwner  и  команда  встречаются  и 
выясняют, как можно сократить scope работ и при этом достичь цели спринта.  
Остановка спринта (Sprint Abnormal Termination) 
Остановка  спринта  производится  в  исключительных  ситуациях.  Спринт  может  быть 
остановлен до того, как закончатся отведенные 30 дней. Спринт может остановить команда, 
если  понимает,  что  не  может  достичь  цели  спринта  в  отведенное  время.  Спринт  может 
остановить ProductOwner, если необходимость в достижении цели спринта исчезла.  
После остановки спринта проводится митинг с командой, где обсуждаются причины 
остановки спринта. После этого начинается новый спринт: производится его планирование и 
стартуются работы.  
DailyScrumMeeting 
Этот митинг проходит каждое утро в начале дня. Он предназначен для того, чтобы все 
члены команды знали, кто и чем занимается в проекте. Длительность этого митинга строго 
ограничена и не должна превышать 15 минут. Цель митинга - поделиться информацией. Он 
не предназначен для решения проблем в проекте. Все требующие специального обсуждения 
вопросы  должны  быть  вынесены  за  пределы  митинга.  Скрам  митинг  проводит  Скрам 
Мастер. Он по кругу задает вопросы каждому члену команды  
Что сделано вчера?  
Что будет сделано сегодня?  
С какими проблемами столкнулся?  
Скрам  Мастер  собирает  все  открытые  для  обсуждения  вопросы  в  виде  ActionItems, 
например в формате что/кто/когда, например : 
Обсудить проблему с отрисовкой контрола 
Петя и Вася  
Сразу после скрама 
Демо и ревью спринта 
Рекомендованная длительность: 4 часа  
Команда  демонстрирует  инкремент  продукта,  созданный  за  последний  спринт. 
ProductOwner,  менеджмент,  заказчики,  пользователи,  в  свою  очередь,  его  оценивают. 
Команда  рассказывает  о  поставленных  задачах,  о  том  как  они  были  решены,  какие 
препятствия  были  у  них  на  пути,  какие  были  приняты  решения,  какие  проблемы  остались 
нерешенными. На основании ревью принимающая сторона может сделать выводы о том, как 
должна  дальше  развиваться  система.  Участники  митинга  делают  выводы  о  том,  как  шел 
процесс в команде и предлагает решения по его улучшению.  
Скрам  Мастер  отвечает  за  организацию  и  проведение  этого  митинга.  Команда 
помогает  ему  составить  адженду  и  распланировать  кто  и  в  какой  последовательности  что 
представляет. Подготовка к митингу не должна занимать у команды много времени (правило 
- не более двух часов). В частности, именно поэтому запрещается использовать презентации 
в PowerPoint. Подготовка к митингу не должна занимать у команды более 2-х часов. 
Описанная  методология  позволяет  повысить  эффективность  командной  работы  в 
планировании, мониторинги и реализации проекта. 

жүктеу/скачать 8,59 Mb.

Достарыңызбен бөлісу: