Подборка из википедии.
Основные идеи Agile Software Development:
▪ Личности и их взаимодействия важнее, чем процессы и инструменты;
▪ Работающее программное обеспечение важнее, чем полная документация;
▪ Сотрудничество с заказчиком важнее, чем контрактные обязательства;
▪ Реакция на изменения важнее, чем следование плану.
Принципы, которые разъясняет Agile Manifesto:
▪ удовлетворение клиента за счёт ранней и бесперебойной поставки ценного ПО;
▪ приветствие изменений требований, даже в конце разработки (это может повысить конкурентоспособность полученного продукта);
▪ частая поставка рабочего ПО (каждый месяц или неделю или ещё чаще);
▪ тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта;
▪ проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы, поддержкой и доверием;
▪ рекомендуемый метод передачи информации — личный разговор (лицом к лицу);
▪ работающее ПО — лучший измеритель прогресса;
▪ спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределенный срок;
▪ постоянное внимание на улучшение технического мастерства и удобный дизайн;
▪ простота — искусство НЕ делать лишней работы;
▪ лучшие технические требования, дизайн и архитектура получаются у самоорганизованной команды;
▪ постоянная адаптация к изменяющимся обстоятельствам.
———————————————————————————-
Методологии Agile Software Development:
———————————————————————————-
Scrum
Scrum чётко делает акцент на качественном контроле процесса разработки.
Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные небольшие промежутки времени (спринты от 2 до 4 недель) предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго-фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.
Главные действующие роли в Scrum: ScrumMaster — тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего кроме корректного ведения самого Scrum-а, руководитель проекта скорее относится к Product Owner и не должен являться ScrumMaster); Владелец Продукта (Product Owner) — человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон; и кросс-функциональная Команда (Scrum Team), состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.
На протяжении каждого спринта, 15-30 дневного периода (длительность определяется командой), создаётся функциональный рост программного обеспечения.
Набор возможностей, которые реализуются в каждом спринте, происходят из этапа, называемого product backlog (документация запросов на выполнение работ), обладающего наивысшим приоритетом по уровню требований к работе, который должен быть выполнен. Запросы на выполнение работ (backlog items), определенных на протяжении совета по планированию спринта (sprint planning meeting), перемещаются в этап спринта. На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены. Тогда Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта. Во время спринта команда выполняет определенный фиксированный список заданий (т. н. sprint backlog). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (requirements) во время спринта.
Product backlog — это документ, содержащий список требований к функциональности, которые упорядочены по степени важности. Product backlog представляет собой список того, что должно быть реализовано. Элементы этого списка называются «историями» (user story) или элементами backlog’a (backlog items). Product backlog открыт для редактирования для всех участников Scrum-процесса.
Sprint Backlog — содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.
Burndown chart — показывает, сколько уже исполнено и сколько ещё остаётся сделать.
———————————————————————————-
Lean
Принципы
▪ Исключение затрат. Затратами считается всё, что не добавляет ценности для потребителя. В частности: излишняя функциональность; ожидание (паузы) в процессе разработки; нечёткие требования; бюрократизация; медленное внутреннее сообщение.
▪ Акцент на обучении. Короткие циклы разработки, раннее тестирование, частая обратная связь с заказчиком.
▪ Предельно отсроченное принятие решений. Решение следует принимать не на основе предположений и прогнозов, а после открытия существенных фактов.
▪ Предельно быстрая доставка заказчику. Короткие итерации.
▪ Мотивация команды. Нельзя рассматривать людей исключительно как ресурс. Людям нужно нечто большее, чем просто список заданий.
▪ Интегрирование. Передать целостную информацию заказчику. Стремиться к целостной архитектуре. Рефакторинг.
▪ Целостное видение. Стандартизация, установление отношений между разработчиками. Разделение разработчиками принципов бережливости. «Мыслить широко, действовать мало, промахиваться быстро; учиться стремительно».
———————————————————————————-
Extreme Programming, XP
Двенадцать основных приёмов экстремального программирования (по первому изданию книги Extreme programming explained) могут быть объединены в четыре группы:
▪ Короткий цикл обратной связи (Fine scale feedback)
▪ Разработка через тестирование (Test driven development)
▪ Игра в планирование (Planning game)
▪ Заказчик всегда рядом (Whole team, Onsite customer)
▪ Парное программирование (Pair programming)
▪ Непрерывный, а не пакетный процесс
▪ Непрерывная интеграция (Continuous Integration)
▪ Рефакторинг (Design Improvement, Refactor)
▪ Частые небольшие релизы (Small Releases)
▪ Понимание, разделяемое всеми
▪ Простота (Simple design)
▪ Метафора системы (System metaphor)
▪ Коллективное владение кодом (Collective code ownership) или выбранными шаблонами проектирования (Collective patterns ownership)
▪ Стандарт кодирования (Coding standard or Coding conventions)
▪ Социальная защищенность программиста (Programmer welfare):
▪ 40-часовая рабочая неделя (Sustainable pace, Forty hour week)
В XP особое внимание уделяется двум разновидностям тестирования:
▪ тестирование модулей (unit testing);
▪ приемочное тестирование (acceptance testing).
Разработчик не может быть уверен в правильности написанного им кода до тех пор, пока не сработают абсолютно все тесты модулей разрабатываемой им системы. Тесты модулей позволяют разработчикам убедиться в том, что их код работает корректно. Они также помогают другим разработчикам понять, зачем нужен тот или иной фрагмент кода и как он функционирует. Тесты модулей также позволяют разработчику без каких-либо опасений выполнять рефакторинг (refactoring).
Приемочные тесты позволяют убедиться в том, что система действительно обладает заявленными возможностями. Кроме того, приемочные тесты позволяют проверить корректность функционирования разрабатываемого продукта.
Для XP более приоритетным является подход называемый TDD (Test Driven Development), сначала пишется тест, который не проходит, затем пишется код, чтобы тест прошел, а уже после делается рефакторинг кода.
Друг дал ссылки на хорошие статьи по данной теме:
http://martinfowler.com/articles/newMethodology.html
