Управление проектом ИС

Основные виды деятельности программной инженерии:Бизнес-анализФормирование виденияАнализ требованийРазработка архитектурыТестированиеУправление проектомУправление средойУправление конфигурациейУправление требованиямиУсовершенствованиеДетальное проектированиеРеализацияЭкспертиза (испытание)ДокументированиеОбучениеВнедрениеЭксплуатацияСопровождение

Проект – это упорядоченная совокупность действий, направленная на достижение наперёд заданной цели, ограниченная требованиями к:срокамстоимостиуровню рискакачеству ожидаемых результатов.Понятие проекта 1Понятие проекта 2Управление проектами – это успешное управление изменениями некоторой материальной системы.

Признаки проектной деятельности:Однократность условий в их совокупностиОтграничение от других замысловПостановка цели, ограниченной во времениОграничения финансового, персонального или другого родаОрганизация, специфичная для проекта.

АНАЛИЗ И ПЛАНИРОВАНИЕ1. Наглядное представление цели2. Сделайте список задач3. Должен быть 1 руководитель4. Распределите задач по людям5. Управляйте ожиданиями.КОНТРОЛЬ И ВЫПОЛНЕНИЕ ПЛАНА6. Используйте подходящий стиль руководства7. Знайте, что происходит8. Сообщайте людям, что происходит9. Повторяйте пп. 1-8 до достижения п. 1010. Приз

Наглядное представление целиТочное определение целиОбоснование цели (самомотивация)Мотивация командыИзменения цели и их контроль.

Сделай список задач и…

Должен быть один руководительЛидерствоОтветственностьПолномочияКоличество проектов...

Распределить задачи по людямУдостовериться, что у каждой задачи есть исполнительПринять во внимание др. занятия исполнителейПопытаться максимизировать силы той команды, которую Вы получили 

Управляйте ожиданиямиЯвные и скрытые риски«Заделы»«поиск обновлений таблицы» «техническое обслуживание памяти»Управление требованиями

Используйте подходящий стиль руководстваНесколько человек – тысячи человекКаждый – индивидуум со своими страхами, предубеждениями, желаниями, надеждами, опытом, проблемами, амбициямиКак начать работу со столь сложным организмом?Как поддерживать рабочую атмосферу?

Знайте, что происходитЗавершающиеся задачиЗапускаемые задачиЗадачи в работеГрафик:– Изменений нет– Поправимый сбой– Сбой, приводящий к изменению графика.

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

Повторяйте пп. 1-8 до достижения п. 10

Приз

Управление программными проектами в RUPОбщая схема работ по управлениюДвухуровневое планированиеРабота с рискамиМониторинг и метрикиУправление персоналомУправление бюджетомУправление контактами и контрактами.На каждом этапе работ RUP разрабатывается своя группа моделей и документов (artifacts).Основным результатом итеративного процесса является последовательное совершенствование моделей и документации (artifacts).

Начальная фаза разработки (Inception Phase)Основная задача начальной фазы разработки - определение конечных целей проекта.Для этого выявляются все акторы, с которыми система должна взаимодействовать, определяется суть их деятельности и основные функции.Начальная фаза завершается принятием принципиального решения о целесообразности проведения дальнейшей разработки.

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

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

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

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

Определение риска IT-проекта (Новиков, RUP)Случайная переменная, которая в пределах нормального распределения может принимать значение, подвергающее опасности, либо исключающее успех проектаЧто-то, находящееся на пути к успеху, в настоящее время неизвестное или трудно поддающееся определению.

УспехДостижение всех требований и ограничений, ожидаемых от проекта.

Прямой и косвенный рискиПрямой риск – риск, который в существенной степени может контролироваться проектомКосвенный риск – риск, мало или вообще никак не управляемый проектом.

Атрибуты рисковВероятность наступленияВлияние на проект (серьезность)Значительность риска как интегральная характеристика -Шкала: высокий, существенный, умеренный, незначительный, низкий.

Что такое управление рисками? (РусРиск)Это процесс:Систематического выявления потенциальных рисковых событийОценки уровня их влиянияРазработки решений по управлению, применяемых в стратегическом и оперативном управлении для обеспечения уверенности в достижении целей.

М. Фаулер. Классификация рисков

Риски, связанные с требованиямиВарианты использования (UC) VS функции – Типичное взаимодействие Система-Пользователь, обеспечивающее достижение цели Пользователя – Выделение ключевых (essential) UCМодель предметной областиГоризонтальные прототипы

Технологические рискиКомпоненты, согласование компонентВертикальные прототипы на ранних стадиях проектаМодульное построение (возможность замены)Анализ вновь поступающих UC – «сходимость» архитектуры.

Риски, связанные с квалификацией персоналаОшибка, первая в рейтинге пост-анализа проекта:«Нам следовало больше внимания уделять обучению»Курсы«Играющий тренер»Семинары, обсужденияТекущий контроль и оперативная помощь.

Существуют ли политические силы, которые могут оказаться на вашем пути и серьезно повлиять на выполнение вашего проекта?

Стратегии работы с рискамиСтратегии поведенияПредотвращение риска: реорганизация проекта так, чтобы этот риск не мог на него воздействоватьПередача риска: реорганизация проекта так, чтобы кто-то другой или что-то другое имели с ним дело (заказчик, продавец, банк, другой элемент и т.д.)Принятие и локализация риска: учесть этот риск как неизбежный. Подготовить план действий на случай появления этого риска и контролировать его симптомы.RUP – работа с рисками

Четыре «П» разработки ПОПерсонал (кто это делает)Проект (выполнение необходимых действий)Продукт (артефакты)Процесс (способ, которым это делается)

ПерсоналОбсуждаются вопросы:Размеры коллективаДеление его на управляемые группыСпособы управленияРоли участников рабочего процессаСпециализацияНавыкиУровень квалификации/производительностьЛичностные качества, отношение к проектуОбучение…

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

ПроектОрганизационная сущность, упорядоченная совокупность действий, необходимых для создания конечного продукта:Контакт с заказчикомНаписание документацииПроектированиеПрограммированиеТестирование…

ПроцессСемейства процессов разработки ПОПрогнозирующие (predictive) = тяжеловесные (heavyweight)– применяются при стабильных требованиях и многочисленной группе разработчиков разной квалификации;Облегченные, подвижные, гибкие, адаптивные (lightweight, agile)– применяются при малочисленной группе квалифицированных разработчиков и грамотном заказчике, который имеет возможность участвовать в процессе.

Прогнозирующие методологииОбеспечивают защиту инвестиций в условиях формальных отношений «Заказчик-Исполнитель»Основываются на долгосрочном планировании ресурсовОбладают четким планом по получению результатов в терминах вех этапов и фазИзменения требований обеспечиваются процедурой управления изменениямиUP / RUP / EUP / OUPMSF / MOFOracle Method (AIM/CDM/PJM/BPR /OSM)MIL-STD-498…

Rational Unified Process (RUP)Основан на шести лучших советах по организации процесса разработки программного обеспечения:Разрабатывайте итеративноУправляйте требованиямиПользуйтесь модульными архитектурамиИспользуйте визуальное моделированиеНе забывайте о проверке качестваСледите за изменениями.

Open UPOpenUP – ограниченная версия RUP, адаптированная для небольших команд и agileпроектовOpenUP – итеративный процесс, который минимален, завершен, и расширяемБазируется на риск-менеджменте в интеративной разработке, управляется вариантами использованиями, архитектурно центрированOpenUP представлен IBM Rational в 2005 группе Eclipse foundation и открыт для использованияДоступен на http://epf.eclipse.org/wikis/openup/ .

Enterprise UPРасширенный вариант UPРазработан Scott W. Ambler and Larry Constantine в 2000, в 2005 модифицирован Ambler, John Nalbone and Michael VizdosДобавлены новые фазы и потоки работЦель – обеспечение системных процессов сопровождения КИСВ 2013 году создана «agile-версия», доступная на http://www.enterpriseunifiedprocess.com/ .Потоки работ масштаба предприятияМоделирование бизнес-процессов предприятияУправление портфелем (ценных бумаг)Архитектура предприятияСтратегическое повторное использованиеУправление персоналомАдминистрирование предприятияСовершенствование процесса программного обеспечения.

MSFМетодология разработки программного обеспечения, предложенная корпорацией Microsoft.Опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами при разработки решения.MSF представляет собой согласованный набор концепций, моделей и правил.

Структура MSFДВЕ МОДЕЛИ:Модель ПРОЕКТНОЙ ГРУППЫМодель ПРОЦЕССОВТРИ ДИСЦИПЛИНЫ:Управления ПРОЕКТАМИУправления РИСКАМИУправления ПОДГОТОВКОЙ

Базовые принципы MSFЕдиное видение проектаПроявляйте гибкость – будьте готовы к переменамКонцентрируйтесь на бизнес-приоритетахПоощряйте свободное общение.

Microsoft Operation Framework (MOF)Цель заключается в предоставлении ИТ- подразделениям руководств, помогающих создавать, эксплуатировать и поддерживать ИТ-услуги, обеспечивая получение ожидаемых коммерческих преимуществ от конкретных инвестиций в ИТ с приемлемым уровнем риска.Модель предназначена для создания среды, в которой компания и ИТ-подразделение смогут совместно работать над совершенствованием деятельности и использовать при этом проактивную модель, определяющую процессы и стандартные процедуры, направленные на повышение эффективности и продуктивности ИТ-услуг. MOF предлагает логический подход к принятию решений и обмену информацией при планировании, развертывании и поддержке ИТ- услуг.

Oracle MethodCDM (Custom Development Method) - разработка прикладного ПО;PJM (Project Management Method) - управление проектом;AIM (Application Implementation Method) - внедрение прикладного ПО;BPR (Business Process Reengineering) - реинжиниринг бизнес-процессов;OCM (Organizational Change Management) - управление изменениямии др.

Методология Oracle CDMСтандарт, детализированный до уровня заготовок проектных документов, рассчитанных на прямое использование в проектах ИС с реализацией на инструментальных средствах Oracle.Ориентирован на поддержку деятельности разработчика.

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

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

ПроектированиеТребования преобразуются в формальные (детальные) спецификации ИСНа основе концептуальных моделей вырабатываются технические спецификации будущей ИС:– определяется структура и состав БД;– специфицируется набор программных модулейНачальный вариант проектных спецификаций может быть получен автоматически с помощью специализированных утилит на основе созданной концептуальной модели.

РеализацияСоздание и тестирование приложенийСоздаются программы, соответствующие всем требованиям проектных спецификацийЭтап широко автоматизирован, т.к. Oracle CDM имеет специальное инструментальное средство Oracle Designer, в состав которого входят генераторы приложений.

Внедрение и ЭксплуатацияАнализируются– производительность и– целостность системы,выполняется поддержка и, при необходимости, модификация системы.

Процессы CDMRD - Определение производственных требованийES - Исследование существующих системTA - Определение технической архитектурыDB - Проектирование и построение БДMD - Проектирование и реализация модулейCV - Конвертирование данныхDO - ДокументированиеTE - ТестированиеTR - ОбучениеTS - Переход к новой системеPS - Поддержка и сопровождение.

Последовательности задач (1)Последовательности задач (2)RD.020 – RD.030 – RD.070 – BR.020 – BR.080 – MD.020 – MD.060 – DO.070 – TE.110 – PM.050 – CV.140 – PM.080, где:RD.020 – изучение существующих бизнес-процессовRD.030 – моделирование будущих бизнес-процессовRD.070 – выявление детальных требований к будущим бизнес-процессамBR.020 – отображение бизнес-процессов в функциональность приложенияBR.080 – тестирование принятых решенийMD.020 – оценка решений по доработке функциональности приложенияMD.060 – проект расширений функциональности приложенияDO.070 – разработка инструкций пользователяTE.110 – тестирование приложенияPM.050 – установка приложения на систему периода эксплуатацииCV.140 – ввод начальных данныхPM.080 – запуск новой системы.

AIM – процесс «Доработка»Доработка (2)AIM разделяет доработку:при «нехватке» возможностей приложения, касающихся функциональностипри «нехватке» возможностей приложения, касающихся отчетовпри «нехватке» возможностей приложения по предоставлению/ограничению доступа к функциям и даннымпри разработке программ автоматической конвертации (программ переноса бизнес-данных в новое приложение). Доработка основного функционала BR.020 – BR.080 – MD.020BR.020 – выявление «дыр» функциональности приложения, предварительное формулирование решения, как можно устранить «дыры»BR.080 – первоначальная оценка предложенного предварительного решенияMD.020 – окончательное формулирование решения, как можно устранить «дыры», оценка трудозатрат.

Степень адаптивностиОграничивается тремя разновидностями каскадной модели ЖЦ: "классическая" (предусмотрены все работы/задачи и этапы), "быстрая разработка" (Fast Track) (еще более сильно ориентированная на использование инструментов моделирования и программирования Oracle), "облегченный подход" (рекомендуемый в случае малых проектов и возможности быстро прототипировать приложения).Методология не предусматривает:включение дополнительной задачи, которой нет в CDM, и ее привязку к остальным;удаление задачи (и порождаемых ею документов);изменение последовательности выполнения задач по сравнению с предложенной (тем более - по ходу процесса проектирования).

Степень обязательностиМетодология необязательна, но может считаться фирменным стандартом; при формальном применении степень обязательности полностью соответствует ограничениям возможностей адаптацииПрикладная система рассматривается в основном как программно-техническая система – нет поддержки преобразований организационной структуры, реально всегда происходящих при переходе к новой ИС.Другой фактической ориентацией методики является ее (исторически понятная) направленность на создание Информационной Системы с Базами Данных в достаточно традиционном понимании.

Agile - методологииНацелены на преодоление ожидаемой неполноты требований и их постоянного измененияКогда меняются требования, команда разработчиков тоже меняетсяКоманда с трудом может предсказать будущее проектаСуществует точный план лишь на ближайшее времяБолее удаленные во времени планы существуют лишь как декларации о целях проекта, ожидаемых затратах и результатах.Основные постулаты манифеста последователей гибких методологий (Agile Manifesto):Индивидуумы и их взаимодействие важнее процессов и инструментовРаботоспособное программное обеспечение важнее обширной документацииСотрудничество с заказчиком важнее заключения контрактаГотовность к изменениям важнее следования плану.

12 Принципов AgileУдовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;Приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);Частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;Проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;Рекомендуемый метод передачи информации—личный разговор (лицом к лицу);Работающее программное обеспечение—лучший измеритель прогресса;Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;Постоянное внимание улучшению технического мастерства и удобному дизайну;Простота—искусство не делать лишней работы;Лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;Постоянная адаптация к изменяющимся обстоятельствам.

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

ТестированиеКод тестирует сам себяТестирующее программное обеспечениеОпережающее тестированиеТесты в качестве документации работы системы. Нет лишней работы.

Agile - Документирование кодаКому это нужно?Подсказки в IDE, автогенерация документацииПоддержка актуальности документации в кодеКод должен быть понятен САМ ПО СЕБЕМодульные и функциональные тесты – тоже документирование.

Agile - МетодологииICONIXMSF for Agile Software DevelopmentKanban in Software DevelopmentScrumLean Software DevelopmentDSDM (Dynamic System Development Method)AgileUPXP (eXtreme Programming)CrystalFDD (Feature Driven Development)

eXtreme Programming (XP) – Экстремальное программирование.Основная идея — устранить высокую стоимость изменений, вносимых в ПО в процессе как разработки, так и эксплуатацииЦикл разработки - очень короткие итерацииЧетыре базовых действия:– выслушивание заказчика– проектирование– кодирование– тестированиеЗаказчик постоянно присутствует в группе разработчиковПри принятии решений всегда стремятся выбрать самое простое, тесты пишутся еще до написания кодаСборка системы выполняется ежедневно.

Основные черты XPПростотаОбщениеОбратная связьРешительность

XP – что требуется от разработчикаОценка времениПроектированиеПрограммированиеКачество

XP – Что нужно знать заказчикуКак долго?Что сделано?Насколько хорошо?

XP – Что нужно знать разработчикуЧто нужно сделать?Когда это нужно сделать?Когда это сделано?

Основные методики ХРИгра в планирование (planning game)— быстро определяет перечень задач (объем работ), которые необходимо реализовать в следующей версии продукта, для этого рассматриваются бизнес- приоритеты и технические оценкиНебольшие версии (small releases) — самая первая упрощенная версия системы быстро вводится в эксплуатацию, после этого через относительно короткие промежутки времени происходит выпуск версии за версиейМетафора (metaphor) — эта простая общедоступная и общеизвестная история, которая коротко описывает, как работает вся система. Эта история управляет всем процессом разработки«Простой» проект (simple design) — в каждый момент времени система должна быть спроектирована так просто, как это возможно. Чрезмерная сложность устраняется, как только ее обнаруживаютТестирование (testing) — программисты постоянно пишут тесты для модулей. Заказчики пишут тесты, которые демонстрируют работоспособность и завершенность той или иной возможности системыПереработка (refactoring) — программисты реструктурируют систему, не изменяя при этом ее поведения. При этом они устраняют дублирование кода, улучшают коммуникацию, упрощают код и повышают его гибкость.Программирование парами (pair programming) — весь разрабатываемый код пишется двумя программистами на одном компьютереКоллективное владение (collective ownership) — в любой момент времени любой член команды может изменить любой код в любом месте системыНепрерывная интеграция (continuous integration) — система интегрируется и собирается множество раз в день. Это происходит каждый раз, когда завершается решение очередной задачи40-часовая неделя (40-hour week) — программисты работают не более 40 часов в неделю. Никогда нельзя работать сверхурочно две недели подрядЗаказчик на месте разработки (on-site customer) — в состав команды входит представитель Заказчика - пользователь системы. Он доступен в течение всего рабочего дня и способен отвечать на вопросы о системеСтандарты кодирования (coding standards) — программисты пишут весь код в соответствии с правилами, которые обеспечивают коммуникацию при помощи кода

SCRUMРоли:Владелец продукта (Product Owner) – ЛПР, отвечает за определение требований к продуктуКоманда (Team) – кроссфункциональные профессионалыСкрам-мастер (ScrumMaster) – организатор, отвечает за решение проблем и соблюдение методологии Scrum.Фазы проекта:Подготовка (Pregame): общий план проекта, список основных требований к продукту, высокоуровневая архитектура продуктаРеализация (Game): итеративное развитие продуктаЗавершение (Postgame): действия, необходимые для подготовки продукта к выходу на рынок.

Итерация в SCRUMОснова Scrum - итеративная разработкаВ Scrum итерация называется Sprint, Результатом Sprint является готовый продукт (build).

Артефакты ScrumВсего 3 документа:Журнал продукта (Product Backlog) – высокоуровневый список функциональных и технических требований, необходимых для реализации продукта- Приоритезированный список имеющихся на данный момент бизнес-требований и технических требований к системе- Product Backlog постоянно пересматривается и дополняется – в него включаются новые требования, удаляются ненужные, пересматриваются приоритеты.Журнал спринта (Sprint Backlog) – детализированный список функциональных и технических требований, необходимых для успешного завершения итерацииГрафик спринта (Burndown Chart) – показывает ежедневное изменение общего объема работ, оставшегося до завершения итерации.

Product OwnerОтвечает за формирование видения продуктаУправляет ROI (возврат инвестиций)Управляет ожиданиями заказчиков и всех заинтересованных лицКоординирует и приоритизирует Product backlogПредоставляет понятные и тестируемые требования командеВзаимодействует с командой и заказчикомОтвечает за приемку кода в конце каждой итерации.

Скрам мастерСоздает атмосферу доверияУчаствует в митингах в качестве организатораУстраняет препятствияВскрывает проблемы и открытые вопросы видимымиОтвечает за соблюдение практик и процесса в командеПроводит Daily Scrum Meeting и отслеживает прогресс команды при помощи Sprint Backlog, отмечая статус всех задач в спринте.

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

Организация спринтаСпринт начинается с сессии планирования (Sprint Planning Meeting) - определяется объем функциональности, которая будет реализована в течение спринтаЕжедневно проводится собрание участников проекта - скрам- сессия (Daily Scrum Meeting)По завершению спринта проводится демонстрационная сессия (Sprint Review Meeting)В результате каждого спринта в продукте реализуется новый, заметный для владельца продукта, объем функциональностиВ конце каждого спринта продукт остается в работоспособном состоянии.

Сессия планирования спринтаВ начале каждого спринта проводится два митинга:В первом митинге спринта участвуют заказчики, пользователи, менеджмент, Product Owner, Скрам Мастер и команда. Артефакт: Sprint Backlog– Результат: цель спринта (Sprint Goal) и Sprint Backlog – функциональность, которая будет разработана в течение следующего спринта для достижения цели спринта.Во втором митинге участвуют Скрам Мастер, команда. Артефакт: в Sprint Backlog появляются задачи– Результат: Для каждого элемента Sprint Backlog определяется список задач и оценивается их продолжительность. 

Daily Scrum MeetingПроходит каждое утро в начале дня и не превышает 15 мин.Информирует членов команды о занятости в проектеЦель митинга – поделиться информацией, а не решать проблемы в проекте. Все требующие специального обсуждения вопросы должны быть вынесены за пределы митингаКаждый член команнды отвечает на вопрос:– Что сделано вчера?– Что будет сделано сегодня?– С какими проблемами столкнулся?

Демо и ревью спринтаПроводит скрам-мастер при помощи команды в подготовке, длительность не более 4 часовДемонстрируется и оценивается инкремент продукта, созданный за последний спринтРешаемые задачи, препятствия, решенные и нерешенные проблемыПринимается решение о развитии системы.

Feature-driven development – методология, созданная Джеффом Де Люка. Разработка ведется в пять этапов:Построение моделиСоздание списка функцийПланирование реализации функцийСоздание архитектуры для функцийРеализация функций.Достоинством этой методологии стоит считать изначальную поддержку больших групп разработчиков, так как отдельные функции разрабатываются отдельными мини-командами во главе с ведущим разработчиком.Разделение и координация происходят на этапах 3-4.

Crystal Clear«Легковесная» гибкая методология, созданная Алистером Коуберном (Cockburn, 2004).Предназначена для небольших команд в 6-8 человек для разработки некритичных бизнес-приложений.Семь методов/практик, три являются обязательными:Частая поставка продуктаУлучшения через рефлексиюЛичные коммуникацииЧувство безопасностиФокусировкаПростой доступ к экспертамКачественное техническое окружение.

ICONIXМетодология разработки программного обеспечения, сфокусированная на анализе требований и моделировании.В рамках ICONIX используется подмножество UML для анализа требований:Диаграмма вариантов использования;Диаграмма классов;Диаграмма робастности;Диаграмма последовательности.

KanbanЦель – сократить время прохода задачи до «готовности».Задача = ММФ – минимальная маркетинговая фича Уменьшение числа || выполняемых ЧЕЛОВЕКОМ задач (“work in progress”).Визуализация задач.Постоянное совершенствование производства.Система очень проста, удобна как для веб-студий, так и для работы с фрилансерами.

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

Преимущества KANBANУменьшение числа параллельно выполняемых задач значительно уменьшает время выполнения каждой отдельной задачиБыстрое выявление проблемных задачВычисление времени на выполнение усредненной задачи.

Agile Unified Process (AUP) – упрощенная версия IBM Rational Unified Process, созданнаяСкоттом Амблером и состоящая из семи методов:Моделирование используется для понимания бизнес-требования и предметной областиРеализация – это преобразование модели в исполняемый код с модульными тестамиТестирование – способ поиска дефектов и верификации системы на предмет соответствия требованиямРазмещение – доставка готовой системы пользователямУправление конфигурациями – управление доступом и версиями артефактов проектаУправление проектом – непосредственные активности, связанные с ходом проекта: управление и координация людей, управление рисками, управление финансами и так далееСреда – совокупность процессов, инструментов, стандартов и правил.

Microsoft Solutions Framework (MSF) for Agile Software Development.Используя типы рабочих элементов (WITs), отчеты и панели мониторинга, показанные на рисунке, команды могут планировать проекты и затем отслеживать ход реализации этих проектов, просматривать его и составлять соответствующие отчеты. Эти артефакты, основанные на принципах и значениях Agile, создаются при создании командного проекта с помощью шаблона процесса Microsoft Solutions Framework (MSF) for Agile Software Development.Последняя версия шаблона процесса Agile автоматически передается в Team Foundation Server (TFS) при установке или обновлении до последней версии TFS. Используйте Диспетчер шаблонов процессов, чтобы загружать и отправлять шаблоны процессов.Помимо WIT, отчетов и панелей мониторинга, команды обладают доступом к набору общих запросов рабочих элементов, чтобы отслеживать данные, анализировать ход выполнения и принимать решения.