Agile agile
 Скачать 13.17 Kb.
|
|
AGILE Agile – это гибкая методология разработки, в которой делают упор на непосредственное общение лицом к лицу. Она не включает практики, а определяет ценности и принципы. Идеи: люди и взаимодействие важнее процессов и инструментов; работающий продукт важнее исчерпывающей документации; сотрудничество с заказчиком важнее согласования условий контракта; готовность к изменениям важнее следования первоначальному плану. Принципы: наивысшим приоритетом признается удовлетворение заказчика за счет ранней и бесперебойной поставки ценного программного обеспечения; изменение требований приветствуется даже в конце разработки (это может повысить конкурентоспособность полученного продукта); частая поставка работающего программного обеспечения (каждые пару недель или пару месяцев с предпочтением меньшего периода); общение представителей бизнеса с разработчиками должно быть ежедневным на протяжении всего проекта; проекты следует строить вокруг заинтересованных людей, которых следует обеспечить нужными условиями работы, поддержкой и доверием; самый эффективный метод обмена информацией в команде – личная встреча; работающее программное обеспечение – лучший измеритель прогресса; спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок; постоянное внимание к техническому совершенству и хорошему проектированию увеличивают гибкость; простота как искусство не делать лишней работы очень важна; лучшие требования, архитектура и проектные решения получаются у самоорганизующихся команд; команда регулярно обдумывает способы повышения своей эффективности и соответственно корректирует рабочий процесс. Agile Modeling – набор понятий, принципов и приемов (практик), позволяющих быстро и просто выполнять моделирование и документирование в проектах разработки программного обеспечения, а также включает в себя проверку модели кодом. Основная цель: эффективное моделирование и документирование. Но не включает в себя детальную инструкцию по проектированию, не содержит описаний, как строить диаграммы на UML, не охватывает программирование и тестирование, не включает вопросы управления проектом, развертывания и сопровождения системы. SCRUM Scrum – методология управления проектами, а также может использоваться в работе команд поддержки программного обеспечения. Минимально необходимый набор мероприятий, артефактов, ролей, на которых строится процесс SCRUM-разработки, позволяющий за фиксированные небольшие промежутки времени (sprints), предоставлять конечному пользователю работающий продукт с новыми бизнес возможностями, для которых определён наибольший приоритет. Роли в методологии SCRUM: SCRUM-мастер – проводит совещания, следит за соблюдением всех принципов SCRUM, разрешает противоречия, следит чтобы ничего не мешало разработке, проводит совещания; Владелец продукта SCRUM – представляет интересы конечных пользователей и других заинтересованных в продукте сторон, это человек, который знает рынок, интересы всех сторон и что будет лучше для продукта; Команда разработчиков – кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей. Размер команды от 5 до 9 человек; SCRUM-команда – это собирательный образ всех ролей SCRUM. Совещание планирования спринта (Sprint Planning Meeting) – оно проводится в начале каждого спринта. Весь объем работ, который должен быть выполнен за время спринта планируется на этом совещании. В данном совещании принимает участие каждый из SCRUM-команды. Sprint Planning Meeting отвечает на такие вопросы: Какая цель этого спринта, или что можно сделать за этот спринт? Как именно будет достигнута цель спринта, чтобы получить инкремент продукта? Покер-планирование (Planning Poker) – техника оценки, основанная на достижении договоренности, главным образом используемая для оценки сложности предстоящей работы или относительно решаемых задач при разработки ПО. На нем составляется backlog для спринта и выявляется вес и сложность задач. Для проведения покера планирования необходимо подготовить список обсуждаемых функций (задач) и несколько колод пронумерованных карт. Обычно колода содержит карты, содержащие числа Фибоначчи, включая ноль: 0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89. В колоде могут быть также специальные карты: знак вопроса, означающий неуверенность; знак бесконечности, означающая, что обсуждаемая функция или принципиально не может быть реализована, или слишком велика, чтобы присваивать ей число; чашка кофе, означающая требование перерыва. Ранжирование задач: таск – небольшая задача для одного разработчика (например, кнопка или форма ввода данных для страницы авторизации); стори – большая задача, включающая в себя таски, которой занимается группа разработчиков (например, полностью страница авторизации); эпик – самая большая задача, включающая в себя стори (например, полностью реализованная авторизация и регистрация или это результат который должен быть достигнут в конце спринта). Спринт – промежуток времени, достаточный для выполнения запланированной совокупности операций SCRUM, целью которой является создание инкремента бизнес-продукта. Жёстко фиксирован по времени. Длительность одного спринта от 1 до 4 недель. Чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя. В backlog спринта не может быть добавлено новых задач. Для оценки предстоящего объёма работ на спринте чаще всего используются относительные оценки, и практика покера планирования (Planning Poker). Ежедневное SCRUM-совещание (Daily SCRUM) – такие совещания проводятся командой разработчиков, с возможным участием владельца продукта и SCRUM мастера, каждый день в одном и том же месте и в одно и то же время, за время не более 15 минут. На этих совещаниях команда разработчиков рассказывают, что они сделали за прошедший день и что планирует сделать на следующий рабочий день. Диаграмма сгорания – диаграмма, демонстрирующая количество сделанной и оставшейся работы относительно времени на разработку проекта. Журнал пожеланий (Project backlog) – он содержит в себе перечень требований к функциональности, упорядоченный по степени важности и порядку реализации. Бэклог открыт для редактирования для всех участников процесса SCRUM. Ответственный за ведение бэклога проекта – владелец продукта SCRUM. Журнал пожеланий спринта – он содержит функциональность, выбранную владельцем продукта из бэклога проекта. Все функции разбиты по задачам, каждая из которых оценивается на покер-планировании командой SCRUM. Обзор итогов спринта (Sprint review) – проводится в конце спринта, чтобы проверить инкремент продукта и, при необходимости, адаптировать бэклог. Во время обзора итогов спринта участвует SCRUM команда и все заинтересованные лица. Это неформальная встреча и презентация инкремента предназначена для получения обратной связи и развитии сотрудничества. Ретроспективное совещание (Sprint Retrospective) – цель данного совещания – это выработка предложений по совершенствованию процесса реализации проекта. В ходе ретроспективного анализа прошедшего спринта формируется план улучшений процесса реализации проекта для следующего спринта. Вопросы которые решаются на данном совещании: что было сделано хорошо? чтобы было сделано плохо? что сделать, чтобы улучшить разработку? KANBAN Канбан доска – это гибкий инструмент управления проектами, предназначенный для визуализации работы, ограничения незавершенной работы и максимизации эффективности. Канбан не имеет ролей и является непрерывным процессом. Основные принципы: Базирование на существующих методах разработки; Предварительная договоренность о проведении важных изменений; Уважение к существующему порядку, ролям и обязательствам; Поощрение инициативы. Столбцы распределяются на четыре основные: Backlog – карточки, которые нужно сделать; In process – карточки, которые находятся в разработке; Testing – карточки, которые находятся в тестировании; Done – карточки, которые выполнены. Канбан доски используют следующие компоненты: Визуальные сигналы – визуальные карточки (выделение карточки), стикеры, билеты и тд; Столбцы – Backlog, In process и тд; Лимиты незавершенного производства (WIP) – это максимальное количество карточек, которые могут находится в одном столбце в любой момент времени; Точка обязательства (приверженности) – это момент, когда очередная карточка перетаскивается с первого столбца (backlog) и над ней начинается работа; Точка доставки – это момент, когда карточка перетаскивается в финальный столбец (Done) и является готовой. |