Фаза внедрения

Фаза стабилизации

Фаза разработки

Промежуточные вехи фазы планирования

Фаза планирования

Фаза выработки концепции

- Формирование ядра проектной группы

- Выработка единого видения проекта (shared vision document)

- Определение рамок проекта (scope document)

- Оценка рисков

MSF рекомендует следующие промежуточные вехи:

- Ядро проектной группы сформировано

- Черновой вариант концепции проекта составлен

- Анализ и документирование проектных требований

- Создание функциональной спецификации

- Концептуальный, логический и физический дизайн

- Создание сводного плана проекта

- Создание сводного календарного графика

- Верификация технологий

- Базовая версия функциональной спецификации создана

- Базовая версия сводного плана проекта создана

- Базовая версия сводного календарного графика работ создана

- Среды разработки и тестирования развернуты

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

17. MSF: Фаза разработки. Фаза стабилизации. Фаза внедрения. Понятие вехи. [вверх]

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

Рекомендуемые промежуточные вехи:

- Концепция подтверждена

- Билд n завершен, билд n +1 завершен…

На фазе стабилизации фокус смещается в область тестирования и документирования решения. А также создание пилотного внедрения. Результатами этой фазы являются: окончательный продукт (golden release), документация выпуска, материалы поддержки решения, результаты тестирования, проектная документация и анализ пройденной фазы.

На этом этапе группа внедряет решение, стабилизирует его и, пробиваясь сквозь противоборство службы сопровождения и поддержки, таки передает решение им, получив одобрение заказчика. Группа работает над сбором метрик и анализом проекта, дабы бесценный опыт, полученный в результате проекта, не канул в дебрях короткой памяти человеческой.

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

18. Проблемы инженерных методологий и переход к Agile. [вверх]

- Конфликт уникальности программного обеспечения с подходами инженерных методологий

- Недооценка роли человеческого фактора.

- Инженерные методологии рассматривали процесс разработки как последовательность шагов, выполняемую абстрактным исполнителем

- Именно участники проекта и отношения между ними являются основным фактором, влияющим на успех проекта.

- Разработка ведётся в условиях высокой неопределённости, и попытка учесть все факторы в начале проекта (составить детальные требования, затем полностью разработать дизайн системы и т.д.) заранее обречена на провал.

- Для большинства проектов упомянутые выше проблемы являются актуальными и в большом количестве случаев приводят к провалу проектов.

По мере осознания проблем инженерных методологий стали появляться альтернативные подходы к разработке, призванные устранить их недостатки. Особенную скорость этот процесс приобрёл во второй половине 90-х годов, когда сформировалась и обрела популярность целая группа так называемых лёгких (или легковесных) методологий, таких, как Scrum, XP, DSDM, Crystal и др. Несмотря на некоторые отличия в используемых практиках, эти подходы были схожи в том, что в качестве альтернативы тяжеловесным и излишне формализованным инженерным методологиям они стремились предложить адаптивные, итерационные, подходы ориентированные на человека. Лидеры и создатели легковесных подходов активно встречались и обменивались опытом, стремясь найти точки соприкосновения и выработать общие подходы. Одна из таких встреч состоялась в феврале 2001 года на лыжном курорте Сноубёрд в штате Юта и собрала 17 ярких представителей программистской мысли (таких, как М. Фоулер, К. Бек, А. Коуберн и др.). Результат этой встречи во многом повлиял на то, как выполняются сегодня программные проекты по всему миру. Несмотря на существенную разницу в позициях, участники смогли достичь ряда важных договорённостей. Прежде всего, в качестве общего названия для своих течений они выбрали термин agile (гибкий). Фундаментальные общие ценности, объединяющие их подходы, были сведены в документ, названный Манифестом гибкой разработки. Чуть позже к Манифесту добавился и список Принципов, детализирующих особенности гибкой разработки.

19. Agile-манифест. [вверх]

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

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

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

4. Изменения (прежде всего, в требованиях) являются не только неизбежным, но и необходимым элементом практически любого проекта.

20. Принципы Agile (кратко). [вверх]

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.

3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

7. Работающий продукт — основной показатель прогресса.

8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.

9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

10. Простота — искусство минимизации лишней работы — крайне необходима.

11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

21. Понятие, история появления и предназначение CMMI. [вверх]

Capability Maturity Model Integration (CMMI) – Комплексная модель производительности и зрелости – набор моделей (методологий) совершенствования процессов в организациях разных размеров и видов деятельности. CMMI содержит набор рекомендаций в виде практик, реализация которых, по мнению разработчиков модели, позволяет реализовать цели, необходимые для полной реализации определенных областей деятельности.

Первая версия модели CMM разрабатывалась с 1984 по 1987 год Уотсом Хамфри (Watts Humphrey) и Институтом Программной Инженерии (Software Engineering Institute, SEI). SEI является подразделением Университета Карнеги-Меллона (Питтсбург, США). Работа спонсировалась и продолжает спонсироваться Министерством Обороны США, которое искало возможности сравнивать и оценивать многочисленных подрядчиков, выполнявших работы (в первую очередь, разработку программного обеспечения) за деньги оборонного бюджета.

В последующие годы было разработано несколько различных моделей CMM, которые в 2002 году были объединены в одну интегрированную модель CMMI ("I" как раз и означает "Integrated"). Хотя SEI продолжает улучшать и расширять содержание, а также спектр приложений различных моделей технологической зрелости, основным ориентиром для большинства компаний по-прежнему остается CMMI.

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

Следствие 1. CMMI допускает различные реализации и не является методологией разработки ПО, подобно MSF, Scrum, RUP и пр. Последние могут использоваться в его реализации. Так, существует, например, специальный шаблон процесса в VSTS для CMMI под названием MSF for CMMI.

Следствие 2. CMMI используется для сертификации компаний на зрелость их процессов. Изначально, в конце 80-х начале 90-х годов, CMM (тогда еще не CMMI) создавался именно как средство сертификации федеральных субподрядчиков. И только позднее, получив широкое распространение в мире, он начал использоваться, а после и ориентироваться на совершенствование процессов.

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

Со временем менялось только количество и содержание процессных областей. А вот концепция уровней зрелости – это как раз то, что за 20 с лишним лет в этой модели не изменилось.

22. CMMI: 1, 2, 3 уровни зрелости. [вверх]

Уровень зрелости – это главный, итоговый показатель оценки по модели CMMI.

Уровень зрелости 1 (Беспорядок / кризис)

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

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

- Управление требованиями

- Планирование проекта

- Наблюдение за проектом и контроль

- Управление договоренностями с поставщиком

- Измерения и анализ

- Проверка процессов и продуктов на соответствие стандартам

- Конфигурационное управление

Уровень зрелости 3 (Стандартные процессы организации) – определенный уровень. В этом случае процессы определены. Установлены стандарты в пределах организации. На данном этапе процессы описаны не на уровне отдельного проекта, а на уровне всей организации. Присутствует более детальное описание всех процессов, в котором лучше раскрываются связи и зависимости, знание которых позволяет улучшить управление. На этом уровне – уровне 3 — становится видимой внутренняя сторона наших черных ящиков. Это внутренняя структура отражает способ, применения стандартного производственного процесса организации.

- Разработка требований

- Техническое решение

- Сборка и поставка продукта

- Проверка продукта на соответствие требованиям (верификация)

- Проверка продукта на соответствие предназначению (валидация)

- Фокусирование на процессах организации

- Определение процессов организации

- Организация обучения

- Комплексное управление проектом

- Управление рисками

- Управление объединенной командой

- Комплексное управление работой с поставщиком

- Принятие решений: оценка альтернатив

- Создание в организации условий для совместной работы

23. CMMI: 4, 5 уровни зрелости. [вверх]

Уровень зрелости – это главный, итоговый показатель оценки по модели CMMI.

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

- Установление показателей выполнения процессов организации

- Управление проектами на основе количественных показателей

Уровень зрелости 5 (Оптимизация / непрерывное совершенствование) – уровень постоянного улучшения (оптимизации) процессов. На данном этапе мы имеем точные характеристики оценки эффективности бизнес процессов, что позволяет нам постоянно и эффективно улучшать бизнес процессы путем развития существующих методов и техник и внедрения новых.

- Отбор и внедрение улучшений в организацию

- Анализ причин возникновения проблем и предотвращение их появления в будущем

24. SCRUM: Основные правила. [вверх]

- СКРАМ – это один из Agile процессов, который позволяет фокусироваться на поставке наиважнейших, с точки зрения бизнеса, ценностей в наикратчайшие сроки

- Он позволяет нам быстро и часто получать реально работающее программное обеспечение (от двух недель до месяца).

- Бизнес расставляет приоритеты. Команда сама организуется и определяет лучший путь, чтобы выпустить функции с высоким приоритетом.

- Каждые две недели/месяц все заинтересованные могут увидеть реальный работающий продукт и решить выпустить его либо продолжать улучшать в следующей итерации

Правила просты для озвучивания (но зачастую не так просты в реализации):

1. У вас должен быть один человек в проекте, который уполномочен принимать решения о том, какую фичу стоит разрабатывать раньше, какую позже. Его называют «Product Owner».

2. Product Owner поддерживает список требований-пожеланий к продукту. Этот список он сортирует (приоритезирует) по принципу «ценное сверху, менее ценное снизу». Такой список называется «Product Backlog».

3. Собираясь на планирование короткой фазы проекта (итерации или «спринта»), команда выбирает из Product Backlog ту верхнюю часть, которую они считают, что реально начать и закончить за этот короткий выделенный период.

4. По истечению оговоренного срока команда и заказчик встречаются для просмотра и обсуждения результатов. Это называется демонстрацией.

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

6. Во время спринта членам команды скорее всего придётся синхронизировать свои усилия и помогать друг другу для более слаженной работы и достижения общего результата. Хорошо это делать раз в день в течение 10−15 минут в присутствии всех членов команды. Это и называется Скрамом.

7. Во время подобного обсуждения члены команды могут пожаловаться на проблемы, которые они не в силах устранить. Эти проблемы помогает устранить так называемый ScrumMaster — человек, который понимает принципы и тонкости Скрама, командной работы и «нежного лидерства». Он делает всё, чтобы команда максимально эффективно общалась с заказчиком, между собой и достигла своих обещаний и целей.

Основные характеристики

- Самоопределяющаяся команда

- Продукт разрабатывается в процессе серии итераций-спринтов (sprints)

- Все требования записываются в виде единого списка (бэклог продукта -“product backlog”)

- Инженерные практики не являются частью Скрам методологии

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

- Один из “Agile” процессов

25. SCRUM: Понятие спринта. [вверх]

Спринт. Короткая фаза проекта (итерация или «спринт»).

- Проект разрабатывается в серии спринтов

- Типичная продолжительность – от 2-х недель до месяца с жестким ограничением по времени

- Постоянная продолжительность спринта привносит ритм в разработку

- Продукт проектируется, кодируется и тестируется на протяжении одного спринта

- В конце спринта – полностью готовая функциональность

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

26. SCRUM: Роли (владелец продукта, scrum-мастер, команда). [вверх]

Дата добавления: 2015-04-24