Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов
Комментарии (4)
10 июня 2017 в 16:27
0↑
↓
Вы не корректно используете терминологию.
Waterfall не методолгия, это не фреймворк и не best-practice. Это МОДЕЛЬ. https://en.wikipedia.org/wiki/Waterfall_model
Почитайте Ройса или вот маленькая цитата из той же вики:Royce presented this model as an example of a flawed, non-working model;
Сравнивать «Waterfall» и всякие Agile/Rup/whatever нас научили продавцы этих фреймворков/методологий — консультаты, тренера и иже с ними.
Не вводите себя и других в заблуждение.
Locolind
10 июня 2017 в 16:36 (комментарий был изменён)
0↑
↓
Согласен с вами.Каскадная модель — это парадигма.
За ней скрывается фреймворк, который детально описан в стандарте PMI (PMBoK).
К сожалению для него нет другого названия, которое было бы общепринятым, кроме как Waterfall.
Поэтому в статье используется оно.RUP — это методология, которая относится к Инкрементальным и Итеративным моделям (парадигмам).
Lofer
10 июня 2017 в 16:57 (комментарий был изменён)
0↑
↓
За ней скрывается фреймворк, который детально описан в стандарте PMI (PMBoK).
В PM Book ничего не расписано, никаких frameworks там нету.
Там только набор «Best Practice» и первым абзацем там написано:Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту1.1 Цель Руководства PMBOK®
Повсеместное признание, которое завоевывает управление проектами, является показателем того, что применение соответствующих знаний, процессов, навыков, инструментов и методов может иметь решающее значение для проекта. Руководство PMBOK® выделяет ту часть Свода знаний по управлению проектами, которая обычно считается хорошей практикой. «Обычно считается» означает, что описываемые знания и практики применимы к большинству проектов в большинстве случаев, причем относительно их значения и пользы существует консенсус. «Хорошая практика» означает, в целом существует согласие относительно того, что правильное применение этих знаний, навыков, инструментов и методов способно повысить вероятность успеха для широкого диапазона различных проектов. «Хорошая практика» не означает, однако, что описываемые знания должны всегда одинаковым образом применяться ко всем проектам; организация команда управления проектом самостоятельно определяет применимость этих знаний к тому или иному проекту.А фазы, что вы указали для RUP присутсвуют в любом проекте, вопрос в каком виде.
Вам повезло, что заказчик уже побегал по граблям и согласился на вменяемый бизнес-анализ, что позволило вам адекватно оценить риски и принять меры к их понижению (через грамотное планирование, в первую очередь).
RUP тут, играл такую же весомую роль, как бумага на которой печатался контракт :)Поэтому рекомендую освоить нотации IDEFx на основе Structured Analysis and Design Technique (книга на русском).
IDEFx штука не плохая, но… несколько неудобная и ракообразная, на мой взгляд.-
Locolind
10 июня 2017 в 17:26
0↑
↓
В PM Book ничего не расписано, никаких frameworks там нету.
В пятой версии начиная со страницы 417 «Приложение А1 Стандарт управления проектом»А фазы, что вы указали для RUP присутствуют в любом проекте.
А вы не путаете фазы проекта с типами работ?В классическом представления каждая фаза проекта соответствует одному типу работ. В парадигме RUP в каждой фазе проекта могут быть выполнены все типы работ: Сбор требований, Анализ, Проектирование, Разработка, Тестирование и Внедрение, — и не по одному разу, если фаза содержит более одной итерации.
Поэтому указанные типы работ действительно присутствуют во всех проектах, а вот Фазы не всегда используются. Это должен быть осознанный выбор и их практикование Руководителем проекта.
Вам повезло, что заказчик уже побегал по граблям и согласился на вменяемый бизнес-анализ
Это так, я Заказчиков, с которыми не везёт, не беру. Но в данном случае мой Заказчик по граблям не бегал, у нас с ним была история успешного сотрудничества, поэтому был высокий кредит доверия, что мне видней как лучше это сделать.Про вменяемый бизнес-анализ скажу, что для того, чтобы его сделать, нужно знать что такое «вменяемый бизнес-анализ», уметь его делать и трассировать в техническую постановку.
Благодарю что оценили наше грамотное планирование.
Вдохновлялись книгой Ivar Jacobson «The Unified Software Development Process»
