Сравнение каскадной и водопадной моделей жц.
SCRUM
Общее описание фреймворка SCRUM
Scrum - это методология управления проектами, относящаяся к Agile-методам, то есть гибким подходам к разработке программного обеспечения. О Scrum, как правило, говорят именно в IT-контексте, хотя применяться он может много где. Это фреймворк, то есть каркас, структура, и оплетать этот эффективный каркас индивидуальными особенностями проекта можно в разных областях, если по самой своей сути проект и Scrum «совместимы».
Scrum – это такой процесс, который помогает выявить настоящий процесс, структуру, режим работы, которые постоянно адаптируются под актуальный контекст и текущие обстоятельства. Scrum - это фреймворк, описывающий роли и правила, опираясь на принципы, которые содействуют и помогают людям выполнять свои задачи при минимуме предписаний.
Краткая характеристика артефактов фреймворка SCRUM
Основные артефакты:
burndown-диаграмма - диаграмма, демонстрирующая количество сделанной и оставшейся работы относительно времени на разработку проекта.
backlog проекта - список требований к функциональности проекта, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются пользовательскими историями (user story) или элементами беклога (backlog items). Журнал пожеланий проекта открыт для редактирования для всех участников скрам-процесса.
backlog спринта - содержит функциональность, выбранную владельцем продукта из журнала пожеланий проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой.
канбан-доска - должна состоять как минимум из трех колонок: «сделать» (англ. to-do), «в процессе» (in progress), «сделано»(done). При разработке ПО SCRUM канбан-доска обычно включает следующие колонки в соответствии со статусом задач: обсуждается (backlog), согласовано (ready), кодируется (coding), тестируется (testing), подтверждается (approval) и сделано (done).
цель спринта - это краткое описание бизнес-цели, ради которой выполняется данный спринт.
инкремент продукта - это готовый продукт в конце спринта. Показывают заинтересованным на демонстрации, чтобы собрать отзывы и решить, что делать с продуктом дальше.
история пользователя - требуемую бизнес-функциональность, которую добавляют в бэклог, часто называют историей. Зачастую история имеет следующую структуру: «Будучи пользователем <тип пользователя> я хочу сделать <действие>, чтобы получить <результат>».
очки за пользовательскую историю (story points) - абстрактная метрика оценки сложности истории, которая не учитывает затраты в человекочасах.
задачи истории спринта - добавляются к историям спринта. Выполнение каждой задачи оценивается в часах. Каждая задача не должна превышать 12 часов.
Краткая характеристика процессов фреймворка SCRUM
спринт - время, в течение которого выполняется работа над продуктом. По окончанию Sprint должна быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении все жизни продукта.
планирование спринта - производится перед началом каждого спринта, во время него производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте.
daily scrum (scrum-митинг) - производится каждый день, каждый член команды отвечает на вопросы «что я сделал вчера?», «что я планирую сделать сегодня?», «какие препятствия на своей работе я встретил?». Задача Daily Scrum — определение статуса и прогресса работы над Sprint, раннее обнаружение возникших препятствий, выработка решений по изменению стратегии, необходимых для достижения целей Sprint'а.
обзор спринта - проводится в конце спринта. Команда демонстрирует прирост инкремента продукта всем заинтересованным лицам. Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт). Нельзя демонстрировать незавершенную функциональность. Ограничена четырьмя часами в зависимости от продолжительности итерации и прироста функциональности продукта.
ретроспектива - проводится в конце спринта. Члены скрам-команды, скрам-мастер и продукт-оунер высказывают свое мнение о прошедшем спринте. Скрам-мастер задает два вопроса всем членам команды: Что было сделано хорошо в прошедшем спринте? Что надо улучшить в следующем? Выполняют улучшение процесса разработки (обсуждают варианты решения проблем, фиксируют удачные решения и вызвавшегося владельца продукта). Ограничена четырьмя часами для спринта любой длины.
груминг бэклога - скрам-команда и владелец могут добавить, убрать или разбить элементы бэклога продукта, уточнить или дать новые оценки, изменить порядок следования элементов бэклога продукта, обсудить и проявить требования.
Краткая характеристика ролей фреймворка SCRUM
скрам-мастер - проводит совещания (Scrum meetings) следит за соблюдением всех принципов скрама, разрешает противоречия и защищает команду от отвлекающих факторов, проводит фасилитацию митингов, отвечает за учет, хранение и выдачу SCRUM-инвентаря. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса.
скрам-владелец продукта - представляет интересы конечных пользователей и других заинтересованных в продукте сторон.
скрам-команда - кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды составляет от 5 до 9 человек. Команда является единственным полностью вовлеченным участником разработки и отвечает за результат как единое целое. Никто, кроме скрам-команды, скрам-мастера и владельца продукта не может вмешиваться в процесс разработки на протяжении спринта.
Отличия ролей владельца продукта от скрам-мастера на примере среды DEVPROM.
В среде Devprom владелец продукта не видит состава команды, в то время как скрам-мастер не только видит состав команды, но и может назначать задачи участникам проекта. Скрам-мастер отвечает за то, чтобы владелец продукта и команда правильно действовали при разработке продукта.
Понятие гибких методологий, используемых для разработки ПО.
Agile-методы - обобщающий термин для целого ряда подходов и практик, основанных на ценностях Манифеста гибкой разработки программного обеспечения и 12 принципах, лежащих в его основе.
Основные идеи:
люди и взаимодействие важнее процессов и инструментов;
работающий продукт важнее исчерпывающей документации;
сотрудничество с заказчиком важнее согласования условий контракта;
готовность к изменениям важнее следования первоначальному плану.
Принципы:
удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения;
приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще);
тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
работающее программное обеспечение — лучший измеритель прогресса;
спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок;
постоянное внимание улучшению технического мастерства и удобному дизайну;
простота — искусство не делать лишней работы;
лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
постоянная адаптация к изменяющимся обстоятельствам. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Принцип декомпозиции задач и его реализация в среде DEVPROM.
Принцип декомпозиции задач - это последовательное разбиение более крупных задач на более мелкие. В Devprom это реализовано следующим образом: крупные истории преобразуются владельцем продукта в эпики (самый верхний уровень декомпозиции), эпик состоит из некоторого количества пользовательских историй, в каждой пользовательской истории указаны задачи, выполнение которых необходимо для достижения цели истории.
Сравнение типов проектов поддерживаемых средой DEVPROM
Это из кр1) Основные типы:
Легковесные процессы разработки (поиск или создание продукта, развитие продукта, сопровождение продукта)
Процессы с предварительным проектированием (разработка по требованиям, разработка по ГОСТ)
Поддержка пользователей
Легковесные процессы предназначены для проектов с незначительными рисками, ориентированные больше на скорость поставки работающего продукта. Процессы с предварительным проектированием предназначены для проектов с повышенными рисками (много участников, высокая сложность, жесткие требования по срокам и т.п.), ориентированные на более глубокую проработку требований, перед их реализацией. Это позволяет лучше прогнозировать стоимость работ, меньше усилий тратить на программирование, создавать более качественный продукт.
Механизм оценки скорости разработки команды в среде DEVPROM с использованием фреймворка SCRUM
Burndown-диаграмма показывает текущее состояние итерации, исходя из общего объема запланированной на итерацию работы (в часах, желтая линия), выполненного объема работы (в часах, зеленая линия) и длины итерации. Красная линия показывает идеальную скорость, с которой должна работать проектная команда. Синяя линия показывает прогноз по сроку, к которому оставшийся объем работ по итерации будет выполнен, исходя из текущей скорости команды.
График скорости команды в devprom отображает скорость работы команды в разрезе спринтов проекта. Скорость вычисляется на основе суммарных плановых оценок пожеланий, выполненных в спринтах.
Принципы совместной работы по созданию документации в среде DEVPROM
Над созданием документации могут работать одновременно несколько участников команды. Над одним разделом (подразделом) в одно и то же время может работать только один человек. Удобнее всего назначать задачи на заполнение каждого раздела конкретному участнику, так можно избежать рассогласованности действий.
UP
Краткая характеристика UP проектирования.
Унифицированный процесс как процесс разработки программного обеспечения представляет собой методологию, содержащую детальное описание работ по созданию и внедрению ПО. Содержит описание: технологических процессов, видов деятельности, исполнителей, артефактов.