Гибкая методология разработки ( Agile software development )

1. Гибкая методология разработки(Agile software development)  Подготовила студентка группы РИМ-130209, Ананина Елена

2. Что такое гибкая методология? Это серия подходов к разработке программного обеспечения, ориентированных на использование итеративной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности, известны как гибкие методики, экстремальное программирование, DSDM, Scrum. Основной метрикой agile-методов является рабочий продукт. Отдавая предпочтение непосредственному общению, agile-методы уменьшают объём письменной документации по сравнению с другими методами. Это привело к критике этих методов как недисциплинированных.

3. Что такое гибкая методология? Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки. Agile-методы делают упор на непосредственное общение лицом к лицу. Большинство agile-команд расположены в одном офисе. Как минимум, она включает и заказчиков» (эту роль может выполнять менеджер проекта, бизнес-аналитик или клиент). Офис может также включать тестировщиков, дизайнеров интерфейса, технических писателей и менеджеров.

4. История гибких методологий • В феврале 2001 в штате Юта США был выпущен Манифест гибкой методологии разработки программного обеспечения (Agile Manifesto). • Он являлся альтернативой управляемым документацией, «тяжеловесным» практикам разработки программного обеспечения, таким как Метод водопада (Waterfall), являвшимся золотым стандартом разработки в то время. Данный манифест был одобрен и подписан представителями различных методологий программирования. • Гибкая методология разработки использовалась многими компаниями и до принятия манифеста, однако именно после этого события произошло вхождение Agile-разработки в массы.

5. Основные тезисы Эти тезисы были сформулированы отцами-основателями гибких методологий в документе Agile Manifesto: • Люди и их взаимодействие важнее процессов и инструментов • Готовый продукт важнее документации по нему • Сотрудничество с заказчиком важнее жестких контрактных ограничений • Реакция на изменения важнее следования плану

6. Визуализация ценностей прописанных в манифесте • Полный текст манифеста (и его переводы) доступны на сайте http://agilemanifesto.org. • Для работы по гибкой методологии необходимо ориентироваться на достижение баланса между двумя чашами весов

7. Принципы гибких методологий Принципы гибкой методологии, которые разъясняет Agile Manifesto: • Удовлетворение клиента за счёт ранней и бесперебойной поставки ценного программного обеспечения • Приветствие изменений требований даже в конце разработки (это может повысить конкурентоспособность полученного продукта) • Частая поставка рабочего программного обеспечения (каждый месяц или неделю или ещё чаще) • Тесное, ежедневное общение заказчика с разработчиками на протяжении всего проекта • Проектом занимаются мотивированные личности, которые обеспечены нужными условиями работы поддержкой и доверием • Рекомендуемый метод передачи информации — личный разговор (лицом к лицу)

8. Принципы гибких методологий • Работающее программное обеспечение — лучший измеритель прогресса • Спонсоры, разработчики и пользователи должны иметь возможность поддерживать постоянный темп на неопределённый срок • Постоянное внимание улучшению технического мастерства и удобному дизайну; • Простота — искусство не делать лишней работы • Лучшие технические требования, дизайн и архитектура получаются у самоорганизованнойкоманды • Постоянная адаптация к изменяющимся обстоятельствам.

9. Некоторые гибкие методологии • Agile DataMethod • Dynamic Systems Development Method • Экстремальное программирование (Extremeprogramming, XP). • Feature driven development (FDD) • Scrum

10. Согласно исследованию AgileSurvey Распространение гибких методологий в мире

11. Основные понятия Scrum • Скрам— это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость. • Спринт — итерация в скраме, в ходе которой создаётся функциональный рост программного обеспечения. Жёстко фиксирован по времени. Считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Беклог (резерв) проекта — это список требований к функциональности, упорядоченный по их степени важности, подлежащих реализации. Элементы этого списка называются «пожеланиями пользователя» или элементами резерва. Резерв проекта открыт для редактирования для всех участников скрам процесса. • Беклог(резерв) спринта — содержит функциональность, выбранную владельцем проекта из резерва проекта. Все функции разбиты по задачам, каждая из которых оценивается скрам-командой. Каждый день во время скрам-митинга команда оценивает объем работы, который нужно проделать для завершения спринта.

12. Основные роли в Scrum • Скрам-мастер  — проводит митинги (совещания) следит за соблюдением всех принципов скрам, разрешает противоречия и защищает команду от отвлекающих факторов. Данная роль не предполагает ничего иного, кроме корректного ведения скрам-процесса. Руководитель проекта скорее относится к владельцу проекта и не должен фигурировать в качестве скрам-мастера. • Владелец продукта  — представляет интересы конечных пользователей и других заинтересованных в продукте сторон. • Скрам-команда — кросс-функциональная команда разработчиков проекта, состоящая из специалистов разных профилей: тестировщиков, архитекторов, аналитиков, программистов и т. д. Размер команды в идеале составляет 7±2 человека. Команда является единственным полностью вовлечённым участником разработки и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.

13. Общая схема Scrum

14. Критика • Один из повторяющихся пунктов критики: при agile-подходе часто пренебрегают созданием плана развития продукта, так как подход подразумевает возможность заказчика вдруг и неожиданно в конце каждой итерации выставлять новые требования, часто противоречащие архитектуре уже созданного и поставляемого продукта. Такое иногда приводит к катастрофическим «авралам» с массовым рефакторингом и переделками практически на каждой очередной итерации. • Кроме того, считается, что работа в agile мотивирует разработчиков решать все поступившие задачи простейшим и быстрейшим возможным способом, при этом зачастую не обращая внимания на правильность кода с точки зрения требований нижележащей платформы. Это приводит к снижению качества продукта и накоплению дефектов.

15. Спасибо за внимание!