Agile. Scrum. Шигапова Ксения,

Agile Гибкий подход к разработке ПО. Лучшие практики: Scrum XP TDD, etc. "Agility is not a technology, science, or product but a culture" (Philippe Kruchten)

Agile манифест Люди и их взаимодействие важнее чем процессы и средства Работающее ПО важнее чем исчерпывающая документация Сотрудничество с заказчиком важнее чем обсуждение условий контракта Реагирование на изменения важнее чем следование плану

Ценности Agile Гибкость и простота Частые релизы Самоорганизующаяся команда Больше общения

Гибкость и простота Agile-процессы готовы к изменениям требований даже на поздних этапах разработки. Важна простота - искусство увеличения объема работ, которых удалось избежать.

Частые релизы Наивысший приоритет - удовлетворенность заказчика: ранние и периодические поставки ПО ПО работающее и ценное для заказчика Продолжительность каждой итерации - от пары недель до пары месяцев. Предпочтение - коротким интервалам.

Самоорганизующаяся команда Над проектом работают мотивированные люди. Создаются все условия, поддержка, и полное доверие. Самые лучшие архитектуры, требования и дизайны систем создаются самоорганизующимися командами. Команда сама организует оптимальный процесс.

Больше общения Потенциальные пользователи системы и разработчики должны работать вместе на протяжении всего проекта. Самый действенный и эффективный способ обмена информацией как внутри команды разработчиков, так и с внешним миром - непосредственное общение.

Может не сработать fixed price большие, распределенные команды длинный формальный цикл подтверждения результатов нет коммуникации с пользователями, отсутствие экспертизы у команды недостаточно квалификации, зрелости, готовности к изменениям.

Экстремальное программирование (XP) Короткий цикл обратной связи Разработка через тестирование Игра в планирование Заказчик всегда рядом Парное программирование Непрерывный, а не пакетный процесс Непрерывная интеграция Рефакторинг Частые небольшие релизы

Экстремальное программирование (XP) Понимание, разделяемое всеми Простой дизайн Метафора системы Коллективное владение кодом или выбранными шаблонами Стандарт кодирования Социальная защищенность программиста 40-часовая рабочая неделя

TDD (test-driven development) Модульные тесты пишутся ДО реализации функциональности Сначала тест падает Test first? Test oriented development?

TDD how to 1. Все тесты проходят 2. Добавляется новый тест: новое поведение или ошибка 3. Проходят все тесты, кроме нового 4. Быстро чинится новый тест 5. Все тесты проходят 6. Рефакторинг 7. Все тесты проходят

TDD - упражнение Нужно реализовать регистрацию в интернет-магазин Недопустимы одинаковые логины и пароли меньше 6 символов При вводе промокода во время регистрации на счет зачиляется 20$

Парное программирование Один программист управляет компьютером думает над кодированием в деталях. Другой программист сосредоточен на картине в целом непрерывно просматривает код, Роли меняются (~каждые полчаса)

Преимущества Повышение дисциплины Лучший код Коллективное владение кодом Командный дух Высокое качество дизайна Обратная связь Непрерывность проверки кода Обучение

Scrum Product backlog User story Product owner Sprint Sprint backlog: tasks Daily scrum Scrum master Taskboard

Product Backlog Содержит список функциональных единиц системы (user stories), запланированных на след релиз IDВажнНазвани е ОписаниеКак показать 24875Заставка (splash screen) Как пользователь я хочу видеть заставку пока приложение открывается. 1. Запустить приложение – заставка показ. до появления главного окна

Product Backlog Product backlog один на весь релиз Им владеет менеджер продукта (product owner) Он не статичен – записи можно добавлять, удалять, менять им приоритет Общедоступен, но поддерживается одним человеком

Спринт (Sprint) Фаза разработки состоит из нескольких итераций – спринтов. Обычно спринт длится 2-4 недели. Этапы: Планирование Разработка Демонстрация Ретроспектива

Sprint Backlog Описывает задачи, запланированные командой на спринт Задачи – действия, необходимые для реализации заплан. на спринт функциональности В описание задачи входит ее оценка

Планирование (Sprint Planning) Проводится в начале спринта Участвует вся команда User stories разбиваются на задачи и оцениваются членами команды В результате команда подписывается на ту функциональность, на которую хватает времени спринта

Оценка Для оценки выбирается единица – идеальный человеко-день…или зеленый крокодил Следует оценить помехи (например focus factor между 0 и 1) перед каждым спринтом Результаты предыдущего спринта помогают лучше запланировать следующий

Ежедневный скрам (Daily Scrum) Проводится каждый день в фиксированное время Рекомендуется проводить стоя в течение минут Если что-то нужно обсудить, назначается время после скрама

Вопросы Scrum Master спрашивает каждого: Что ты делал? Что ты собираешься делать? Какие были проблемы?

Sprint whiteboard

Демонстрация (ревью) В конце каждого спринта проводится ревью Это демонстрация реализованной функциональности В ней может участвовать любой человек, задействованный в проекте В идеале после каждой демонстрации можно отправлять продукт заказчику

Ретроспектива спринта После каждого спринта (ревью) Участвуют все члены команды Цель - осознать: Что было хорошо? Что могло бы быть лучше Это обсуждение процесса, а не технических сложностей

Обзор активностей АктивностьПроводитУчастни ки Артефакты ПланированиеСкрам- мастер КомандаProduct, Sprint backlog Ежедневный скрам Скрам- мастер КомандаSprint whiteboard, backlog Ревью спринтаСкрам- мастер ВсеРаботающее ПО РетроспективаСкрам- мастер КомандаЗаписи

Пример из жизни До Agile: Тонны спецификаций Каждый сам по себе Перерасход бюджета Непрозрачность для заказчика После внедрения Agile: Сплоченная команда Рост эффективности Прозрачность и взаимодействие

Ссылки velopment velopment

Вопросы?