Подготовительный этап в разработке информационных система в образовании (ИСО) - презентация

1 Подготовительный этап в разработке информационных система в образовании (ИСО)

2 ГОСТ ISO/IEC 12207:1995 (российский аналог ГОСТ Р ИСО/МЭК ) Стандарты жизненного цикла ПО 2

3 ISO/IEC 12207:1995 «Information technology–Software life cycle processes» с дополнениями и изменениями ISO/IEC 12207:1995/AMD 1:2002 и ISO/IEC 12207:2002/AMD 2:2004 (принят в новой редакции в 2008 году) ISO/IEC 12207:2008 «Systems and software engineering–Software life cycle processes» ISO/IEC TR 15271:1998 Information technology – Guide for ISO/IEC (Software Life Cycle Processes) ISO/IEC TR 16326:1999 Software engineering – Guide for the application of ISO/IEC to project management Спецификации ISO/IEC 12207:1995, ISO/IEC TR 15271:1998 и ISO/IEC TR 16326:1999 введены в качестве национальных стандартов РФ ISO/IEC

4 Подготовка программного средства. Анализ требований технического задания. Проектирование архитектуры программного средства. Детальное проектирование программного средства. Конструирование программного средства. Комплексирование программного средства. Тестирование. Разработка 4

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

6 Анализ области применения разрабатываемой системы с точки зрения определения требований к ней. Оформление требований к программному средству, которые должны описывать: функциональные и технические требования, включая производительность, физические характеристики и окружающие условия, под которые должен быть создан программный объект архитектуры (далее - программный объект); требования к внешним интерфейсам программного объекта архитектуры; квалификационные требования; требования безопасности, включая требования, относящиеся к методам эксплуатации и сопровождения, воздействию окружающей среды и травмобезопасности персонала; требования защиты, включая требования, относящиеся к допустимой точности информации; эргономические требования, включая требования, относящиеся к ручным операциям, взаимодействию "человек-машина", персоналу и областям, требующим концентрации внимания человека, связанным с чувствительностью объекта к ошибкам человека и обученности персонала; требования к определению данных и базе данных; требования по вводу в действие и приемке поставляемого программного продукта на объекте(ах) эксплуатации и сопровождения; требования к документации пользователя; требования к эксплуатации объекта пользователем; требования к обслуживанию пользователя. Анализ ТЗ 6

7 Оценка ТЗ с учётом следующих критериев (при этом результаты оценок должны быть документально оформлены):учёт потребностей заказчика; соответствие потребностям заказчика; тестируемость; выполнимость проектирования системной архитектуры; возможность эксплуатации и сопровождения. 7

8 Определение общей архитектуры системы (архитектура верхнего уровня). В архитектуре должны быть указаны объекты технических и программных средств и ручных операций. Должно быть обеспечено распределение всех требований к системе между объектами архитектуры. Затем должны быть определены объекты конфигурации технических и программных средств и ручных операций на основе объектов архитектуры. Должна быть документально оформлена привязка системной архитектуры и требований к системе относительно установленных объектов. Оценка системной архитектуры и требований к объектам архитектуры с учётом следующих критериев (при этом результаты оценок должны быть документально оформлены): учёт требований к системе; соответствие требованиям к системе; соответствие используемых стандартов и методов проектирования; возможность программных объектов архитектуры выполнять установленные для них требования; возможности эксплуатации и сопровождения. Проектирование архитектуры программного средства 8

9 Трансформирование требований к программному объекту в архитектуру, которая описывает общую структуру объекта и определяет компоненты программного объекта. Разработка и оформление общего (эскизного) проекта внешних интерфейсов программного объекта и интерфейсов между компонентами объекта. Разработка и оформление общего проекта базы данных. Разработка и оформление предварительной версии документации пользователя. Разработка и оформление предварительных общих требований к тестированию программного объекта и графику сборки программного продукта. Оценка архитектуры программного объекта и эскизные проекты интерфейсов и базы данных по следующим критериям: учёт требований к программному объекту; внешняя согласованность с требованиями к программному объекту; внутренняя согласованность между компонентами программного объекта; соответствие методов проектирования и используемых стандартов; возможность технического проектирования; возможность эксплуатации и сопровождения. Детальное проектирование программного средства 9

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

11 Разработка и документальное оформление следующие продукты: каждый программный модуль и базу данных; процедуры испытаний (тестирования) и данные для тестирования каждого программного модуля и базы данных. Разработка плана сборки для объединения программных модулей и компонентов в программный объект. План должен включать требования к испытаниям (тестированию), процедуры тестирования, контрольные данные, обязанности исполнителя и программу испытаний. План должен быть документально оформлен. Сбор программных модулей и компонентов. Сбор объектов программной в единую систему вместе с объектами технической конфигурации, ручными операциями и, при необходимости, с другими системами. Комплексирование программного средства 11

12 Тестирование в соответствии квалификационным требованиям к программному объекту. Оценка проекта, запрограммированного программного объекта, тестирование по следующим критериям: тестовое покрытие требований к программному объекту; соответствие ожидаемым результатам; возможность сборки и тестирования системы (при их проведении); возможность эксплуатации и сопровождения. Тестирование системы и оценена по следующим критериям: тестовое покрытие требований к системе; соответствие ожидаемым результатам; возможность эксплуатации и сопровождения. Проведение аудиторской проверки и доработка Тестирование 12

13 Водопадная (каскадная, последовательная) модель 13

14 Поэтапная модель с промежуточным контролем 14

15 Итерационная модель 15

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

17 Спиральная модель 17

18 фаза определения требований и анализа; фаза проектирования; фаза реализации; фаза внедрения. 18 Фазы по RAD

19 Concept of Operations (COO) концепция (использования) системы; Life Cycle Objectives (LCO) цели и содержание жизненного цикла; Life Cycle Architecture (LCA) архитектура жизненного цикла; здесь же возможно говорить о готовности концептуальной архитектуры целевой программной системы; Initial Operational Capability (IOC) первая версия создаваемого продукта, пригодная для опытной эксплуатации; Final Operational Capability (FOC) – готовый продукт, развернутый (установленный и настроенный) для реальной эксплуатации. 19

20 V-Model 20

21 детализация проекта возрастает при движении слева направо, одновременно с течением времени, и ни то, ни другое не может повернуть вспять. Итерации в проекте производятся по горизонтали, между левой и правой сторонами буквы. Применительно к разработке информационных систем V-Model вариация каскадной модели, в которой задачи разработки идут сверху вниз по левой стороне буквы V, а задачи тестирования вверх по правой стороне буквы V. Внутри V проводятся горизонтальные линии, показывающие, как результаты каждой из фаз разработки влияют на развитие системы тестирования на каждой из фаз тестирования. Модель базируется на том, что приемо-сдаточные испытания основываются, прежде всего, на требованиях, системное тестирование на требованиях и архитектуре, комплексное тестирование на требованиях, архитектуре и интерфейсах, а компонентное тестирование на требованиях, архитектуре, интерфейсах и алгоритмах. 21 Основные принципы

22 Минимизация рисков: V-образная модель делает проект более прозрачным и повышает качество контроля проекта путём стандартизации промежуточных целей и описания соответствующих им результатов и ответственных лиц. Это позволяет выявлять отклонения в проекте и риски на ранних стадиях и улучшает качество управления проектов, уменьшая риски. Повышение и гарантии качества: V-Model стандартизованная модель разработки, что позволяет добиться от проекта результатов желаемого качества. Промежуточные результаты могут быть проверены на ранних стадиях. Универсальное документирование облегчает читаемость, понятность и проверяемость. Уменьшение общей стоимости проекта: Ресурсы на разработку, производство, управление и поддержку могут быть заранее просчитаны и проконтролированы. Получаемые результаты также универсальны и легко прогнозируются. Это уменьшает затраты на последующие стадии и проекты. Повышение качества коммуникации между участниками проекта: Универсальное описание всех элементов и условий облегчает взаимопонимание всех участников проекта. Таким образом, уменьшаются неточности в понимании между пользователем, покупателем, поставщиком и разработчиком 22 Цели

23 Пользователи V-Model участвуют в разработке и поддержке V-модели. Комитет по контролю за изменениями поддерживает проект и собирается раз в год для обработки всех полученных запросов на внесение изменений в V-Model. На старте любого проекта V-образная модель может быть адаптирована под этот проект, так как эта модель не зависит от типов организаций и проектов. V-model позволяет разбить деятельность на отдельные шаги, каждый из которых будет включать в себя необходимые для него действия, инструкции к ним, рекомендации и подробное объяснение деятельности. 23 Достоинства

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

25 Основные идеи: Личности и их взаимодействия важнее, чем процессы и инструменты; Работающее программное обеспечение важнее, чем полная документация; Сотрудничество с заказчиком важнее, чем контрактные обязательства; Реакция на изменения важнее, чем следование плану. Гибкая методология разработки 25

26 Принципы: удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения; приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта); частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще); тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта; проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием; рекомендуемый метод передачи информации личный разговор (лицом к лицу); работающее программное обеспечение лучший измеритель прогресса; спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок; постоянное внимание улучшению технического мастерства и удобному дизайну; простота искусство не делать лишней работы; лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды; постоянная адаптация к изменяющимся обстоятельствам. 26

27 Agile Modeling Agile Unified Process Agile Data Method DSDM Essential Unified Process Экстремальное программирование Feature driven development (FDD) Getting Real OpenUP Scrum Бережливая разработка программного обеспечения Методологии 27

28 Короткий цикл обратной связи (Fine scale feedback) Разработка через тестирование (Test driven development) Игра в планирование (Planning game) Заказчик всегда рядом (Whole team, Onsite customer) Парное программирование (Pair programming) Непрерывный, а не пакетный процесс Непрерывная интеграция (Continuous Integration) Рефакторинг (Design Improvement, Refactor) Частые небольшие релизы (Small Releases) Понимание, разделяемое всеми Простота (Simple design) Метафора системы (System metaphor) Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership) Стандарт кодирования (Coding standard or Coding conventions) Социальная защищенность программиста (Programmer welfare): 40-часовая рабочая неделя (Sustainable pace, Forty hour week) Экстремальное программирование 28

29 Исключение затрат. Затратами считается всё, что не добавляет ценности для потребителя. В частности: излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение. Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком. Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов. Предельно быстрая доставка заказчику. Короткие итерации. Мотивация команды. Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий. Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг. Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, действовать мало, промахиваться быстро; учиться стремительно». Бережливая разработка программного обеспечения 29

30 разработка общей модели; составление списка необходимых функций системы; планирование работы над каждой функцией; проектирование функции; реализация функции. Feature driven development 30

31 31

32 Разработка программного обеспечения основывается на формальных методах. Инкрементальная реализации в рамках статистического контроля качества Статистическое тестирование Формальная верификация Cleanroom Software Engineering 32

33 Совместная работа с целью согласования интересов и достижения общего понимания; Развитие с целью непрерывного обеспечения обратной связи и совершенствования проекта; Концентрация на архитектурных вопросах на ранних стадиях для минимизации рисков и организации разработки; Выравнивание конкурентных преимуществ для максимизации потребительской ценности для заинтересованных лиц. OpenUP 33

34 Инструментарий должен быть нацелен на минимизацию времени разработки. Создание прототипа для уточнения требований заказчика. Цикличность разработки: каждая новая версия продукта основывается на оценке результата работы предыдущей версии заказчиком. Минимизация времени разработки версии, за счёт переноса уже готовых модулей и добавления функциональности в новую версию. Команда разработчиков должна тесно сотрудничать, каждый участник должен быть готов выполнять несколько обязанностей. Управление проектом должно минимизировать длительность цикла разработки. RAD 34

35 Планирование - совокупность требований, полученных при системном планировании и анализе процедуры разработки жизненного цикла (SDLC). На этом этапе пользователи, менеджеры и IT-специалисты обсуждают задачи проекта, его объём, системные требования, а также сложности, которые могут возникнуть при разработке. Фаза завершается согласованием ключевых моментов с RAD-группой и получением от руководителей проекта разрешения на продолжение. Модель быстрой разработки приложений (RAD) Пользовательское проектирование - на протяжении данного этапа пользователи, взаимодействуя с системными аналитиками, разрабатывают модели и прототипы, которые включают в себя все необходимые системные функции. Для перевода пользовательских прототипов в рабочие модели RAD-группа обычно использует технику объединенной разработки приложений (JAD) и CASE-инструменты. Пользовательское проектирование оказывается длительным интерактивным процессом, который позволяет пользователям понять, изменить и в конечном счете выбрать рабочую модель, отвечающую их требованиям. Конструирование - этап, в котором основная задача заключается в разработке программ и приложений. Аналогична стадии "реализация" в SDLC. В RAD, однако, пользователи продолжают принимать участие и по- прежнему могут предлагать изменения или улучшения в виде разработанных ими докладов. В их задачи входит программирование и разработка приложений, написание кода, интеграция модулей и системное тестирование. Переключение - включает в себя операции по конверсии данных, тестирование, переход на новую систему и тренировку пользователей. По своим задачам напоминает финальную стадию SDLC. Сравнивая с традиционными методами разработки ПО, весь процесс оказывается сжатым по времени. Как результат, новая система оказывается быстрее построенной, доставленной до заказчика и установленной на рабочих местах. Фазы разработки 35

36 36

37 Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков. Концентрация на выполнении требований заказчиков к исполняемой программе (анализ и построение модели прецедентов (вариантов использования)). Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки. Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта. Постоянное обеспечение качества на всех этапах разработки проекта (продукта). Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам. Rational Unified Process 37

38 38

39 Формируются видение и границы проекта. Создается экономическое обоснование (business case). Определяются основные требования, ограничения и ключевая функциональность продукта. Создается базовая версия модели прецедентов. Оцениваются риски. 39 Начало (Inception)

40 Документирование требований (включая детальное описание для большинства прецедентов). Спроектированную, реализованную и оттестированную исполняемую архитектуру. Обновленное экономическое обоснование и более точные оценки сроков и стоимости. Сниженные основные риски. 40 Уточнение (Elaboration)

41 реализация большей части функциональности продукта. Фаза Построение завершается первым внешним релизом системы и вехой начальной функциональной готовности (Initial Operational Capability). 41 Построение (Construction)

42 создается финальная версия продукта и передается от разработчика к заказчику. Это включает в себя программу бета-тестирования, обучение пользователей, а также определение качества продукта. В случае, если качество не соответствует ожиданиям пользователей или критериям, установленным в фазе Начало, фаза Внедрение повторяется снова. Выполнение всех целей означает достижение вехи готового продукта (Product Release) и завершение полного цикла разработки. 42 Внедрение (Transition)

43 модели: модель проектной группы модель процессов Microsoft Solutions Framework 43

44 Распределение ответственности при фиксации отчетности Наделяйте членов команды полномочиями Концентрируйтесь на бизнес-приоритетах Единое видение проекта Проявляйте гибкость будьте готовы к переменам Поощряйте свободное общение Принципы 44

45 Команда соратников Сфокусированность на нуждах заказчика Нацеленность на конечный результат Установка на отсутствие дефектов Стремление к самосовершенствованию Заинтересованные команды работают эффективно Концепции 45

46 управление программой управление продуктом разработка тестирование управление релизом удовлетворение потребителя ролевые кластеры 46

47 Выработка концепции (Envisioning) Планирование (Planning) Разработка (Developing) Стабилизация (Stabilizing) Внедрение (Deploying) Модель процессов 47

48 48

49 Вовлечение пользователя - это основа ведения эффективного проекта, где разработчики делят с пользователями рабочее пространство и поэтому принимаемые решения будут более точными. Команда должна быть уполномочена принимать важные для проекта решения без согласования с начальством. Частая поставка версий результата, с учётом такого правила, что «поставить что-то хорошее раньше - это всегда лучше, чем поставить всё идеально сделанное в конце». Анализ поставок версий с предыдущей итерации учитывается на последующей. Главный критерий как можно более быстрая поставка программного обеспечения, которая удовлетворяет текущим потребностям рынка. Но в то же время поставка продукта, который удовлетворяет потребностям рынка, менее важно, чем решение критических проблем в функционале продукта. Разработка - итеративная и инкрементная. Она основывается на обратной связи с пользователем, чтобы достичь оптимального с экономической точки зрения решения. Любые изменения во время разработки - обратимы. Требования устанавливаются на высоком уровне прежде, чем начнётся проект. Тестирование интегрировано в жизненный цикл разработки. Взаимодействие и сотрудничество между всеми участниками необходимо для его эффективности. DSDM 49

50 Исследование реализуемости Исследование экономической целесообразности Создание функциональной модели Проектирование и разработка Реализация 50

51 Добавление теста Запуск всех тестов: убедиться, что новые тесты не проходят Написать код Запуск всех тестов: убедиться, что все тесты проходят Рефакторинг Повторить цикл Разработка через тестирование TDD 51

52 52 Scrum

53 Скрам-мастер (ScrumMaster) проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам- процесса. Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве скрам-мастера. владелец проекта (Product Owner) представляет интересы конечных пользователей и других заинтересованных в продукте сторон. Скрам-команда (Scrum Team) кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет 7±2 человека. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта. Пользователи (Users) Клиенты, Продавцы (Stakeholders) лица, которые инициируют проект и для кого проект будет приносить выгоду. Они вовлечены в скрам только во время обзорного совещания по спринту (Sprint Review). Управляющие (Managers) люди, которые управляют персоналом. Эксперты-консультанты (Consulting Experts) 53 Роли в скрам-процессе

54 Обязательные поля ID уникальный идентификатор, порядковый номер, применяемый для идентификации историй в случае их переименования. Название (Name) краткое описание истории. Оно должно быть однозначным, чтобы и разработчики, и владелец проекта могли понять, о чем идёт речь и отличить одну историю от другой. Важность (Importance) степень важности данной истории, по мнению владельца проекта. Обычно представляет собой натуральное число, иногда для этой цели используются числа Фибоначчи. Чем больше значение, тем выше приоритет. Предварительная оценка (initial estimate) начальная оценка объёма работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story pointах. Приблизительно соответствует числу «идеальных человеко-часов». Как продемонстрировать (how to demo) краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. Данное поле может представлять собой код автоматизированного теста для приёмо- сдаточного испытания. 54 Артефакты

55 Дополнительные поля Иногда, также, используются дополнительные поля в резерве проекта, в основном для того, чтобы помочь владельцу проекта определиться с его приоритетами. Категория (track). Например, «панель управления» или «оптимизация». При помощи этого поля владелец проекта может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет. Компоненты (components) указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkboxов, которые отмечаются, если соответствующие компоненты требуют изменений. Инициатор запроса (requestor). владелец продукта может захотеть хранить информацию о всех заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ. ID в системе учёта дефектов (bug tracking ID) если вы используете отдельную систему отслеживания ошибок, тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся. 55

56 Из резерва проекта выбираются задачи, обязательства по выполнению которых за спринт принимает на себя команда; На основе выбранных задач создается резерв спринт. Каждая задача оценивается в идеальных человеко-часах; Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи; Обсуждается и определяется, каким образом будет реализован этот объём работ; Продолжительность совещания ограничено сверху 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п. (первая часть совещания) Участвует владелец проекта и скрам команда: выбирают задачи из резерва продукта; (вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют резерв спринта. 56 Планирование спринта (Sprint Planning Meeting)

57 начинается точно вовремя; все могут наблюдать, но только «свиньи» говорят; длится не более 15 минут; проводится в одном и том же месте в течение спринта. В течение совещания каждый член команды отвечает на 3 вопроса: Что сделано с момента предыдущего ежедневного совещания? Что будет сделано с момента текущего совещания до следующего? Какие проблемы мешают достижению целей спринта? (Над решением этих проблем работает скрам мастер. Обычно это решение проходит за рамками ежедневного совещания и в составе лиц, непосредственно затронутых данным препятствием.) 57 Ежедневное совещание (Daily Scrum meeting)

58 Проводится после ежедневного скрам совещания. Позволяет нескольким скрам командам обсуждать работу, фокусируясь на общих областях и взаимной интеграции. Повестка та же, что и на ежедневном скрам совещании плюс следующие вопросы: Что каждая команда сделала с момента предыдущего ежедневного совещания? Что каждая команда сделает к следующему ежедневному совещанию Есть ли проблемы, мешающие или замедляющие работу каждой команды? Нужно ли другой команде сделать что-то из задач вашей команды? 58 Скрам над скрамом (Scrum of Scrums)

59 Проводится после завершения спринта. Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам. Привлекается максимальное количество зрителей. Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт). Нельзя демонстрировать незавершенную функциональность. Ограничена 4-мя часами в зависимости от продолжительности итерации и инкремента продукта. 59 Обзор итогов спринта (Sprint review meeting)

60 Проводится после завершения спринта. Члены команды высказывают своё мнение о прошедшем спринте. Отвечают на два основных вопроса: Что было сделано хорошо в прошедшем спринте? Что надо улучшить в следующем? Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения). Ограничена 13-мя часами. 60 Ретроспективное совещание (Retrospective мeeting)

61 IBM Rational Team Concert Visual Studio 2010, Microsoft Team Foundation Server 61 Средства управления проектами поддерживающие скрам