"Гибкие" (agile) методы разработки

Начать. Это бесплатно
или регистрация c помощью Вашего email-адреса
Rocket clouds
"Гибкие" (agile) методы разработки создатель Mind Map: "Гибкие" (agile) методы разработки

1. Общее

1.1. Обзор

1.1.1. "Гибкие" (agile) методы разработки ПО появились как альтернатива формальным и "тяжеловесным" методологиям, наподобие CMM и RUP

1.2. 4 Основных положения закрепленных в Agile Manifesto

1.2.1. реакция на изменения вместо следования плану

1.2.2. индивидуалы и взаимодействие вместо процессов и программных средств

1.2.3. работающее ПО вместо сложной документации

1.2.4. взаимодействие с заказчиком вместо жестких контрактов

2. Extreme Programming

2.1. основные принципы организации процесса по XP

2.1.1. Планирование (Planning Game), основанное на принципе, что разработка ПО является диалогом между возможностями и желаниями, при этом изменятся и то и другое.

2.1.2. Метафора (Metaphor) – суть проекта должна умещаться в 1-2 емких фразах или в некотором образе.

2.1.3. Простой дизайн (Simple Design) – против избыточного проектирования.

2.1.4. Рефакторинг (Refactoring) – процесс постоянного улучшения (упрощения) структуры ПО, необходимый в связи с добавлением новой функциональности

2.1.5. Парное программирование (Pair Programming) – один программирует, другой думает над подходом в целом, о новых тестах, об упрощении структуры программы и т.д.

2.1.6. Коллективное владение кодом (Collective Ownership)

2.1.7. Участие заказчика в разработке (On-site Customer) – представитель заказчика входит в команду разработчика.

2.1.8. Создание и использование стандартов кодирования (Coding Standards) в проекте – при написании кода (создаются и) используются стандарты на имена идентификаторов, составление комментариев и т.д.

2.1.9. Тестирование – разработчики сами тестируют свое ПО, перемежая этот процесс с разработкой. При этом рекомендуется создавать тесты до того, как будет реализована соответствующая функциональность. Заказчик создает функциональные тесты.

2.1.10. Непрерывная интеграция. Сама разработка представляется как последовательность выпусков.

2.1.11. 40-часовая рабочая неделя

2.2. Обзор

2.2.1. Самым известным гибким методом является Extreme Programming (известное сокращенное название – XP). Он был создан талантливым специалистом в области программной инженерии Кентом Беком в результате его работы в 1996-1999 годах над системой контроля платежей компании "Крайслер".

3. Scrum

3.1. Роли

3.1.1. Scrum-мастера

3.1.1.1. обеспечивает максимальную работоспособность и продуктивную работу команды – как выполнение Scrum-процесса, так и решение хозяйственных и административных задач. В частности, его задачей является ограждение команды от всех воздействий извне во время итерации.

3.1.2. Владелец продукта

3.1.2.1. это менеджер проекта, который представляет в проекте интересы заказчика. В его обязанности входит разработка начальных требований к продукту (Product Backlog), своевременное их изменение, назначение приоритетов, дат поставки и пр. Важно, что он совершенно не участвует в выполнении самой итерации.

3.1.3. Scrum-команда

3.1.3.1. группа, состоящая из пяти–девяти самостоятельных, инициативных программистов. Первой задачей команды является постановка для итерации реально достижимых и приоритетных для проекта в целом задач (на основе Project Backlog и при активном участии владельца продукта и Scrum-мастера). Второй задачей является выполнение этой задачи во что бы то ни стало, в отведенные сроки и с заявленным качеством. Важно, что команда сама участвует в постановке задачи и сама же ее выполняет. Здесь сочетается свобода и ответственность, подобно тому, как это организовано в MSF. Здесь же "просвечивает" дисциплина обязательств.

3.2. Практики

3.2.1. Sprint Planning Meeting

3.2.1.1. Проводится в начале каждого Sprint. Сначала Produсt Owner, Scrum-мастер, команда, а также представители заказчика и пр. заинтересованные лица определяют, какие требования из Project Backlog наиболее приоритетные и их следует реализовывать в рамках данного Sprint. Формируется Sprint Backlog. Далее Scrum-мастер и Scrum-команда определяют то, как именно будут достигнуты определенные выше цели из Sprint Backlog. Для каждого элемента Sprint Backlog определяется список задач и оценивается их трудоемкость.

3.2.2. Daily Scrum Meeting

3.2.2.1. пятнадцатиминутное каждодневное совещание, целью которого является достичь понимания того, что произошло со времени предыдущего совещания, скорректировать рабочий план сообразно реалиям сегодняшнего дня и обозначить пути решения существующих проблем. Каждый участник Scrum-команды отвечает на три вопроса: что я сделал со времени предыдущей встречи, мои проблемы, что я буду делать до следующей встречи? В этом совещании может принимать участие любое заинтересованное лицо, но только участники Scrum-команды имеют право принимать решения. Правило обосновано тем, что они давали обязательство реализовать цель итерации, и только это дает уверенность в том, что она будет достигнута. На них лежит ответственность за их собственные слова, и, если кто-то со стороны вмешивается и принимает решения за них, тем самым он снимает ответственность за результат с участников команды. Такие встречи поддерживают дисциплину обязательств в Scrum-команде, способствуют удержанию фокуса на целях итерации, помогают решать проблемы "в зародыше". Обычно такие совещания проводятся стоя, в течение 15-20 минут.

3.2.3. Sprint Review Meeting

3.2.3.1. Проводится в конце каждого Sprint. Сначала Scrum-команда демонстрирует Product Owner сделанную в течение Sprint работу, а тот в свою очередь ведет эту часть митинга и может пригласить к участию всех заинтересованных представителей заказчика. Product Owner определяет, какие требования из Sprint Backlog были выполнены, и обсуждает с командой и заказчиками, как лучше расставить приоритеты в Sprint Backlog для следующей итерации. Во второй части митинга производится анализ прошедшего спринта, который ведет Scrum-мастер. Scrum-команда анализирует в последнем Sprint положительные и отрицательные моменты совместной работы, делает выводы и принимает важные для дальнейшей работы решения. Scrum-команда также ищет пути для увеличения эффективности дальнейшей работы. Затем цикл повторяется.

3.3. Обзор

3.3.1. Метод Scrum позволяет гибко разрабатывать проекты небольшими командами (7 человек плюс/минус 2) в ситуации изменяющихся требований. При этом процесс разработки итеративен и предоставляет большую свободу команде. Кроме того, метод очень прост – легко изучается и применяется на практике.

3.3.1.1. Общее описание