ЗАМЕТКИ
Бизнес-аналитик в IT. Команды и процессы.
Жизненный цикл разработки ПО
Исходные модели:
- Waterfall Model каскадная модель, или «Водопад»
- V-model V-образная модель, разработки через тестирование
- Incremental Model инкрементная модель
- Iterative Model итеративная (или итерационная) модель
- Spiral Model спиральная модель
- Chaos model модель хаоса
- Prototype Model прототипная модель
Публикация на habr.com — Ещё раз про семь основных методологий разработки ссылка или архив в pdf ссылка
PRINCE2 (PRojects IN Controlled Environments)
Cтруктурированный метод управления проектами, разработанный в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании. Как указывают сами авторы методологии, PRINCE2 создан на основе опыта, полученного из тысяч проектов, в центре внимания методологии – управленческие стороны проекта.
7 принципов в PRINCE2
1 Постоянная оценка целесообразности (Continued business justification)
Спонсор проекта (в русских договорных отношениях это чаще всего Заказчик, даже если он внутренний) должен быть постоянно уверен в необходимости реализации проекта, если такая необходимость отпала, то проект следует прекратить. Ожидаемые выгоды должны быть больше затрат и рисков.
2 Учет предыдущего опыта (Learn from experience)
Принцип призывает руководителей проектов постоянно анализировать и использовать извлеченные уроки других проектов, а также фиксировать собственный опыт в ходе своего проекта.
3 Определенные роли и обязанности (Defined roles and responsibilities)
В каждом проекте должна быть сформирована матрица ответственности в рамках проекта и его организационной структуре. Авторы PRINCE2 выделяют три заинтересованные стороны проекта: бизнес (определяет цели проекта и инвестирует его), пользователи (используют продукт проекта) и поставщики (предоставляют ресурсы).
4 Управления по стадиям (Manage by stages)
Проект должен планироваться, отслеживаться и контролироваться по стадиям, в конце каждой стадии должен обновляться план следующей стадии с учетом результатов завершающейся текущей стадии. Между каждой стадией должны присутствовать точки принятия основных решений.
5 Управление по исключениям (Manage by exception)
Руководство проектами следует осуществлять путем определения обязанностей и ответственности на каждом уровне проекта при помощи строгого делегирования полномочий. Такой способ управления позволяет экономить как время высшего руководства, спонсоров проекта, так и самого менеджера проекта. Допустимые отклонения должны быть определены для каждого уровня плана проекта.
6 Фокус на продукте (Focus on product)
Акцент в проекте должен быть на конечном продукте и его качестве. Процедура управления изменениями снижает увеличение скоупа проекта. Акцент на качестве и утвержденном описании продукта снижает неудовлетворенность пользователей (потребителей) конченного продукта проекта.
7 Адаптация к внешним условиям (Tailor to suit the project environment)
Проектная команда должна осознавать, каким образом происходит адаптация принципов PRINCE2 к внешним условиям проекта (корпоративные стандарты, корпоративная культура), подходит ли используемый метод для окружения проекта.
Rational Unified Process (RUP)
Недостатки каскадной модели — чем больше Проект, трудоемкость и сроки реализации, тем больше допущений закладывается в проект, которые могут оказаться как верными так и не верными. Самые критичные — это допущения связанные с бизнес-целями Проекта, если они оказываются не верными то все вложенные в проект ресурсы, деньги и время обесцениваются.
Методология RUP была целенаправленно разработана для разработки больших программных систем.
Rational Unified Process (RUP)
Разработка бизнес-сценария использования (Business Modeling), где будущая система представляет собою «чёрный ящик», который удовлетворяет все потребности Пользователя/Бизнеса. На его основе разрабатываются сценарии использования (Use Cases), описывающие функции системы (Requirements), которые будут поддерживать выполнение бизнес-сценария. На основе выделенных системных сценариев использования системы принимаются архитектурные решения и выделяются компоненты, которые будут поддерживать бизнес-сценарии (Analysis & Design). Каждый бизнес-сценарий разворачивается в системные сценарии использования. Каждый системный сценарий — в требования к интерфейсам, алгоритмам, данным и не функциональные (производительность, время доступности, скорость ответа…). На основе выделенных требований определяется будущая архитектура системы и её функциональные модули (сервисные подсистемы).
habr.com — Опыт перехода с Waterfall на методологию RUP для реализации больших ИТ проектов ссылка
Принципы RUP
- Ранняя идентификация и непрерывное (до окончания проекта) устранение основных рисков
- Концентрация на выполнении требований заказчиков к исполняемой программе
- Ожидание изменений в требованиях, проектных решениях и реализации в процессе разработки
- Компонентная архитектура, реализуемая и тестируемая на ранних стадиях проекта
- Постоянное обеспечение качества на всех этапах разработки проекта (продукта)
- Работа над проектом в сплочённой команде, ключевая роль в которой принадлежит архитекторам
Основная идея RUP выдать уже в первых итерациях прототип будущей системы с порцией готовых к использованию / применению бизнес-сценариев.
Сравнение SCRUM, KANBAN и WATERFALL
# | SCRUM | CANBAN | WATERFALL |
---|---|---|---|
Темп | Повторяемые спринты фиксированной продолжительности | Не прерывный процесс | Этап с ожидаемыми сроками |
Выпуск релиза | В конце каждого спринта после одобрения проектным менеджером (владельцем продукта) | Поток продолжается без перерывов или на усмотрение команды | По результатам этапа разработки |
Роли | Владелец продукта, Scrum-мастер, Dev-team и необходимые эксперты | Команда под руководством проджекта | Проектная команда |
Показатели | Скорость команды | Ведущее время | Сроки и требования |
Приемлемость изменений | В ходе спринта изменения не желательны, так как могут привесети к неверной оценке задачи | Изменения могут случиться в любой момент времени | Только в следующем цикле |
Техники декомпозиции требований
- Горизонтальная декомпозиция, задачи разбиваются по типу работы (функции), которую необходимо выполнить, по компонентам, которые задействованы в работе. В этом случае при разбиении общей большой задачи разработчику будет выделена одна часть, тестировщику другая, техническому писателю третья и так далее. Фактически каждая из частей не приводит к конечному результату сама по себе, чтобы выпустить готовый функционал, необходима реализация всей совокупности связанных задач всеми участниками процесса.
- Вертикальная декомпозиция напротив предполагает выделение более мелких задач, фич, функций таким, образом, что каждая такая пользовательская история может быть реализована и выпущена отдельно от остальных задач. При этом в разработку могут быть вовлечены различные роли, могут быть задействованы несколько модулей и систем.
Метод 1: По этапам\фазам бизнес процесса. В данном процессе необходимо выделить последовательную цепочку шагов , которые могут быть реализованы и выполнены независимо друг от друга. Большой бизнес процесс разбивается на составляющие его этапы. При этом этапы могут быть критичными и обязательными или опциональными.
Метод 2: По позитивным и негативным сценариям. Ожидаемые сценарий использования функционала и неправильные, но возможные и вероятные сценарии.
Метод 3: По правилам\условиям бизнес процесса. Декомпозиция процесса на логические ветки, возможные варианты отработки функционала. Определяется набор сценариев, по которым может выполняться процесс при выполнении тех или иных правил\условий.
Метод 4: По видам операций. Выделение операций позволит расставить для них приоритеты.
Метод 5: По типам платформы\ОС. Декомпозиция требований на составные части реализации одного и того же функционала для разных платформ, устройств, операционных систем.
Метод 6: По типам данных и параметрам. Декомпозиция требований\фич на ряд мелких пользовательских историй (User story), в рамках каждой из которых нужно реализовать работу только с каким-то одним типом данных.
Метод 7: По ролям\правам доступа. Каждая группа пользователей с определенной ролью и правами доступа, может выполнять только определенную часть функций из общего процесса.
Метод 8: По сценариям тестирования\тест-кейсам. Набор сценариев которые необходимо проверить и какие тесты выполнить, чтобы узнать, работает та или иная функция системы. Набор тест-кейсов, каждый из которых представляет собой отдельную задачу. Каждая задача должна быть реализована так, чтобы тестовый сценарий был успешно пройден.
Базовые принципы техник оценки в Agile1 Высокая скорость оценки2 Командная работа3 Относительные единицы измеренияМетоды оценки ссылка