|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
|
|
Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Методологии Rational Unified Process: сущность и области применения.
Ведущей методологией, в которой инструментально поддерживаются все этапы жизненного цикла разработки ПО, является методология Rational Unified Process (RUP). Она опирается на проверенные практикой методы анализа, проектирования и разработки ПО, методы управления проектами. RUP обеспечивает прозрачность и управляемость процесса и позволяет создавать ПО в соответствии с требованиями заказчика на момент сдачи ПО, а также в соответствии с возможностями инструментальных средств поддержки разработки. Уровень формализации процесса разработки ПО в рамках этой методологии, позволяет определить и понять, кто должен участвовать в разработке, каковы его функции в этом процессе и на каких этапах. По концепции RUP любой проект состоит из мини проектов (выпусков) для появления на свет каждого из которых (как и самого проекта) необходимо выполнить ряд параллельных потоков работ в совокупности называемых жизненным циклом: 1) Определение требований; 2) Анализ требований и проектирование; 3) Выполнение (реализация); 4) Тестирование; 5) Внедрение (развертывание); В зависимости от распределения интенсивности работ на разных этапах или их наборе процесс разработки в целом также условно делят на фазы: 1) Начало 2) Уточнение 3) Конструирование 4) Выпуск По мере хода потоков работ пик в распределении трудозатрат на каждый из них наступает поочередно. Сначала основные затраты идут на сбор и определение требований к разрабатываемой системе. Когда основная доля требований определена, интенсивность работ плавно переходит на анализ собранных требований и проектирование системы на основании этих требований и анализа и т.д. Таким образом каждый этап цикла выполняясь параллельно с остальными, опирается на результат предыдущих этапов и циклов. Такой итеративный подход позволяет улучшать понимание проблемы через последовательные усовершенствования системы при учете того, что основной каркас (архитектура) системы разрабатывается (проектируется) в самом начале и в дальнейшем происходит лишь наполнение (уточнение). Разбиение процесса разработки программ на итерации позволяет выполнять в первую очередь те части проекта, реализация которых подвержена наибольшему риску, и как следствие - снизить или устранить этот риск или в случае невозможности преодолеть, отказаться от разработки на ранних стадиях, когда потрачено не так много сил и средств. Кроме того такой подход позволяет контролировать и управлять ходом работы, поскольку при этом видно что сделано, что делается и что осталось сделать и, при необходимости, перерасперделять силы на более важные части. Итак, RUP - это контролируемый и управляемый процесс, с четкой регламентацией ролей разработчиков, позволяющий разрабатывать ПО максимально точно в соответствии с меняющимися в ходе разработки требованиями и в достаточно предсказуемые сроки.
Рисунок: Распределение усилий при выполнении проекта: В ходе жизненного цикла проекта распределение усилий проектной команды между дисциплинами постоянно меняется. Например, как правило, в начале проекта большая часть усилий затрачивается на анализ и дизайн, а ближе к завершению – на реализацию и тестирование системы. Однако в общем случае задачи из всех девяти дисциплин выполняются параллельно. Для полноценного внедрения RUP организация должна затратить значительные средства на обучение сотрудников. При этом попытка обойтись своими силами скорее всего будет обречена на неудачу – необходимо искать специалиста по процессам (process engineer) с соответствующим опытом или привлекать консультантов.
3.Гибкие методологии разработки программного обеспечения. Их сущность, примеры и области применения. Гибкие методологии разработки (англ. Agile software development) Большинство гибких методологий нацелены на минимизацию рисков, путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре, и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, кодирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации, команда выполняет переоценку приоритетов разработки Agile-методы делают упор на непосредственное общение лицом к лицу. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объем письменной документации, по сравнению с другими методами. Это привело к критике этих методов, как недисциплинированных. Многие руководители проектов, работающие в традиционных методологиях вроде «водопада», критикуют agile-методы. Один из повторяющихся пунктов критики: при agile-подходе часто пренебрегают созданием «дорожной карты» развития продукта, равно как и управлением требованиями, в процессе которого и формируется такая «карта». Гибкий подход к управлению требованиями не подразумевает далеко идущих планов (по сути управление требованиями просто не существует в данной методологии), а подразумевает возможность заказчика вдруг и неожиданно, в конце каждой итерации, выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации. Кроме того, считается, что работа в agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы (подход — «работает, и ладно», при этом не учитывается, что может перестать работать при малейшем изменении или же дать тяжёлые к воспроизводству дефекты после реального развёртывания у клиента). Это приводит к снижению качества продукта и накоплению дефектов. Наиболее известные методики: + Экстрема́ льное программи́ рование (билет 4) + Методология SCRUM (билет 5) + Microsoft Solutions Framework (MSF) методология разработки программного обеспечения, предложенная корпорацией Microsoft. MSF опирается на практический опыт Microsoft и описывает управление людьми и рабочими процессами в процессе разработки решения. Модель проектной группы MSF (MSF Team Model) описывает подход Майкрософт к организации работающего над проектом персонала и его деятельности в целях максимизации успешности проекта. В соответствии с моделью MSF проектные группы строятся как небольшие многопрофильные команды, члены которых распределяют между собой ответственность и дополняют области компетенций друг друга. Это дает возможность четко сфокусировать внимание на нуждах проекта. Проектную группу объединяет единое видение проекта, стремление к воплощению его в жизнь, высокие требования к качеству работы и желание самосовершенствоваться. MSF включает в себя ряд основных принципов. Вот те из них, которые имеют отношение к успешной работе команды: 1. Распределение ответственности при фиксации отчетности 2. Наделяйте членов команды полномочиями 3. Концентрируйтесь на бизнес-приоритетах 4. Единое видение проекта 5. Проявляйте гибкость — будьте готовы к переменам 6. Поощряйте свободное общение +Канбан - система организации производства и снабжения, позволяющая реализовать принцип «точно в срок». Бережливое производство. Разница между Канбан и SCRUM: · В Канбан нет таймбоксов ни на что (ни на задачи, ни на спринты) · В Канбан задачи больше и их меньше · В Канбан оценки сроков на задачу опциональные или вообще их нет · В Канбан “скорость работы команды” отсутствует и считается только среднее время на полную реализацию задачи Например, общеизвестная проблема SCRUM - это большие издержки от обсуждений, встреч и большие потери времени на стыках спринтов (когда как минимум день уходит на закрытие одного спринта, а потом день на открытие нового. И если спринт - 2 недели, то 2 дня из 2 недель - это 20%, чертовски много). В итоге чуть ли не 30-40% времени при применении SCRUM тратится на поддержание самого процесса - на ежедневные митинги, на 5% workshop, на спринт ретроспектив и т.п. 30%! Канбан разработка отличается от SCRUM в первую очередь ориентацией на задачи. Если в SCRUM основная ориентация команды - это успешное выполнение спринтов (надо признать, что это так), то в Канбан на первом месте задачи. Спринтов никаких нет, команда работает над задачей с самого начала и до завершения. Деплоймент задачи делается тогда, когда она готова. Презентация выполненной работы - тоже. Команда не должна оценивать время на выполнение задачи, ибо это имеет мало смысла и почти всегда ошибочно вначале. Если менеджер верит команде, то зачем иметь оценку времени? Задача менеджера - это создать приоритизированный пул задач, а задача команды - выполнить как можно больше задач из этого пула. Всё. Никакого контроля не нужно. Всё, что нужно от менеджера - это добавлять задачи в этот пул или менять им приоритет. Именно так он управляет проектом. Команда для работы использует Канбан-доску. Например, она может выглядеть так
Цели проекта: Необязательный, но полезный столбец. Сюда можно поместить высокоуровневые цели проекта, чтобы команда их видела и все про них знали. Например, “Увеличить скорость работы на 20%” или “Добавить поддержку Windows 7?. Очередь задач: Тут хранятся задачи, которые готовы к тому, чтобы начать их выполнять. Всегда для выполнения берется верхняя, самая приоритетная задача и ее карточка перемещается в следующий столбец. Проработка дизайна: этот и остальные столбцы до “Закончено” могут меняться, т.к. именно команда решает, какие шаги проходит задача до состояния “Закончено”. Например, в этом столбце могут находиться задачи, для которых дизайн кода или интерфейса еще не ясен и обсуждается. Когда обсуждения закончены, задача передвигается в следующий столбец. Разработка: Тут задача висит до тех пор, пока разработка фичи не завершена. После завершения она передвигается в следующий столбец. Или, если архитектура не верна или не точна - задачу можно вернуть в предыдущий столбец. Тестирование: В этом столбце задача находится, пока она тестируется. Если найдены ошибки - возвращается в Разработку. Если нет - передвигается дальше. Деплоймент: У всех проектов свой деплоймент. У кого-то это значит выложить новую версию продукта на сервер, а у кого-то - просто закомитить код в репозиторий. Закончено: Сюда стикер попадает только тогда, когда все работы по задаче закончены полностью. В любой работе случаются срочные задачи. Запланированные или нет, но такие, которые надо сделать прямо сейчас. Для таких можно выделить специальное место (на картинке отмечено, как “Expedite”). В Expedite можно поместить одну срочную задачу и команда должна начать ее выполнять немедленно и завершить как можно быстрее. Но может быть только одна такая задача! Если появляется еще одна - она должна быть добавлена в “Очередь задач”. А теперь самое важное. Видите цифры под каждым столбцом? Это число задач, которые могут быть одновременно в этих столбцах. Цифры подбираются экспериментально, но считается, что они должны зависеть от числа разработчиков в команде. Что нового и полезного дает такая доска с лимитами? Во-первых, уменьшение числа параллельно выполняемых задач сильно уменьшает время выполнения каждой отдельной задачи. Нет нужды переключать контекст между задачами, отслеживать разные сущности, планировать их и т.д. - делается только то, что нужно. Нет нужды устраивать спринт планнинги и 5% воркшопы, т.к. планирование уже сделано в столбце “очередь задач”, а детальная проработка задачи начинается ТОЛЬКО тогда, когда задача начинает выполняться. Во-вторых, сразу видны затыки. Например, если тестеры не справляются с тестированием, то они очень скоро заполнят весь свой столбец и программисты, закончившие новую задачу, уже не смогут переместить ее в столбец тестирования, т.к. он заполнен. Что делать? Тут время вспомнить, что “мы - команда” и решить эту проблему. Например, программисты могут помочь тестерам завершить одну из задач тестирования и только тогда передвинуть новую задачу на освободившееся место. Это позволит выполнить обе задачи быстрее. В-третьих, можно вычислить время на выполнение усредненной задачи. Мы можем помечать на карточке дату, когда она попала в очередь задач, потом дату, когда ее взяли в работу и дату, когда ее завершили. По этим трем точкам для хотя бы 10 задач можно уже посчитать среднее время ожидания в очередь задач и среднее время выполнения задачи. А из этих цифр менеджер или product owner может уже рассчитывать всё, что ему угодно. Весь Канбан можно описать всего тремя основными правилами: 1. Визуализируйте производство - Разделите работу на задачи, каждую задачу напишите на карточке и поместите на стену или доску. - Используйте названные столбцы, чтобы показать положение задачи в производстве. 2. Ограничивайте WIP (work in progress или работу, выполняемую одновременно) на каждом этапе производства. 3. Измеряйте время цикла (среднее время на выполнение одной задачи) и оптимизируйте постоянно процесс, чтобы уменьшить это время. Всего 3 правила! Например, в SCRUM - 9 базовых правил. В XP - 13, а в классическом RUP - аж более 120. Почувствуйте разницуJ Приблизительная сравнительная таблица
|
Последнее изменение этой страницы: 2017-03-15; Просмотров: 895; Нарушение авторского права страницы
Структуру жизненного цикла проекта, выполняемого по технологии RUP удобно рассматривать на координатной плоскости. При этом по горизонтальной оси отложено время, а по вертикальной — основные деятельности, которые обычно выполняются в ходе любого проекта, претендующего на статус успешного.
Столбцы слева направо: