Расскажите о гибких (agile) методах разработки. Положения Agile - манифеста. Экстремальное программирование.
«Гибкие» (agile) методы разработки ПО появились как альтернатива формальным и «тяжеловесным» методологиям, наподобие CMM и RUP. Талантливые программисты не желают превращения разработки ПО в рутину, хотят иметь максимум свобод и обещают взамен высокую эффективность. С другой стороны, практика показывает, что «тяжеловесные» методологии в значительном количестве случаев неэффективны. Основными положениями гибких методов, закрепленных в Agile Manifesto в 2007 году являются следующее:
· индивидуалы и взаимодействие вместо процессов и программных средств;
· работающее ПО вместо сложной документации;
· взаимодействие е с заказчиком вместо жестких контрактов;
· реакция на изменения вместо следования плану.
Фактически, гибкие методологии говорят о небольших, самоорганизующихся командах, состоящих из высококвалифицированных и энергичных людей, ориентированных на бизнес, то есть, например, разрабатывающих свой собственный продукт для выпуска его на рынок. У этого подхода есть, очевидно, свои плюсы и свои минусы.
Самым известным гибким методом являетсяЭкстремальное программирование (Extreme Programming). Он был создан талантливым специалистом в области программной инженерии Кентом Беком в результате его работы в 1996-1999 годах над системой контроля платежей компании “Крайслер”.
Модель процесса по XP выглядит как частая последовательность выпусков (releases) продукта, столь частых, сколь это возможно. Но при этом обязательно, чтобы в выпуск входила новая целиковая функциональность.
Что такое Sсrum? Схема процесса, роли, практики.
Более практичным «гибким» методом разработки является Scrum (1986, Япония). Метод Scrum позволяет гибко разрабатывать проекты небольшими командами (7 человек плюс/минус 2) в ситуации изменяющихся требований. При этом процесс разработки итеративен и предоставляет большую свободу команде. Кроме того, метод очень прост - легко изучается и применяется на практике. Схема метода:
В Scrum выделяют всего три вида ролей участников.
· Владелец продукта - это менеджер проекта, который представляет в проекте интересы заказчика. В его обязанности входит разработка начальных требований к продукту, своевременное их изменение требований, назначение приоритетов, дат поставки и пр. Важно, что он совершенно не участвует в выполнении самой итерации.
· Scrum-мастер - обеспечивает максимальную работоспособность и продуктивную работу команды - как выполнение Scrum-процесса, так и решение хозяйственных и административных задач. В частности, его задачей является ограждение команды от всех воздействий извне во время итерации.
· Scrum-команда - группа, состоящая из пяти-девяти самостоятельных, инициативных программистов. Важно, что команда сама участвует в постановке задачи и сама же ее выполняет. Здесь сочетается свобода и ответственность, подобно тому, как это организовано в MSF. Здесь же «просвечивает» дисциплина обязательств.
Расскажите об MSF. Основные принципы, история создания. Разновидности поддерживаемых процессов.
В 90-х годах компания Microsoft, стремясь достичь максимальной отдачи от реализации заказных IT-решений и в целях улучшения работы с субподрядчиками обобщила свой опыт по разработке, внедрению, сопровождению и консалтингу ПО, создав методологию MSF. В 2002 году вышла версия MSF 3.1, состоявшая из пяти документов-руководств:
· модель процессов (process model),
· модель команды (team model),
· модель управления проектами (project management),
· дисциплина управления рисками (risk management),
· управление подготовкой (readiness management).
·
Основными новшествами MSF является следующее: Акцент на внедрении IT-решения; Модель процесса, объединяющая спиральную и водопадную модели; Особая организация команды - не иерархическая, а как группа равных, но выполняющих разные функции (роли) работников; Техника управления компромиссами.
Перечислим основные принципы MSF.
1. Единое видение проекта.
2. Гибкость - готовность к переменам.
3. Концентрация на бизнес-приоритетах.
4. Поощрение свободного общения.
Модель команды в MSF.
Главная особенность модели команды в MSF является то, что она «плоская», то есть не имеет официального лидера. Все отвечают за проект в равной степени, уровень заинтересованности каждого в результате очень высок, а коммуникации внутри группы четкие, ясные, дружественные и ответственные.
Каждый ролевой кластер представляет уникальную точку зрения на проект, и в то же время никто из членов проектной группы в одиночку не в состоянии успешно представлять все возможные взгляды, отражающие качественно различные цели. В MSF следующие ролевые кластеры:
· Управление продуктом. Основная задача этого ролевого кластера - обеспечить, чтобы заказчик остался довольным в результате выполнения проекта.
· Управление программой - обеспечивает управленческие функции - отслеживание планов и их выполнение, ответственность за бюджет, ресурсы проекта, разрешение проблем и трудностей процесса, создание условий, при которых команда может работать эффективно, испытывая минимум бюрократических преград.
· Разработка. Этот ролевой кластер занимается, собственно, программированием ПО.
· Тестирование - отвечает за тестирование ПО.
· Удовлетворение потребителя. Дизайн удобного пользовательского интерфейса и обеспечение удобства эксплуатации ПО (эргономики), обучение пользователей работе с ПО, создание пользовательской документации.
· Управление выпуском - беспрепятственное внедрение проекта и его функционирование, сопровождениее, обеспечивая информированность членов проектной группы о последствиях их решений.
· Архитектура - организация и выполнение высокоуровневого проектирования решения, создание функциональной спецификации ПО и управление этой спецификацией в процессе разработки, определение рамок проекта и ключевых компромиссных решений.
·
Один сотрудник может объединять несколько ролей. При этом некоторые роли нельзя объединять (разработка+тестирование)