Слайд 2
Проблемы разработки ПО
Отсутствие эффективной методики разработки ПО ведет
к непредсказуемости, повторению одних и тех же ошибок и
пустой трате сил.
Заказчики недовольны постоянно переносимым графиком сдачи, растущим бюджетом и низким качеством.
Разработчики приходят в уныние от того, что приходится сидеть на работе все дольше, а продукт становится только хуже.
Слайд 3
Проблема №1
Написание софта – сложная задача
Слайд 4
Проблема №2
Очень мало успешных проектов
Standish Group CHAOS Report
http://findarticles.com/p/articles/mi_m0EIN/is_2003_March_25/ai_99169967/
Слайд 5
Проблема №3
Программа делает не то, что нужно пользователям
CHAOS
Chronicles v3.0
Слайд 6
Проблема №4
Сложно вносить изменения
Стоимость изменения
Время
Сбор требований
Тестирование Поставка
Традиционный проект
Agile
проект
Усилия /
Стоимость
Сложный дизайн
Поиск дефекта
Исправление дефекта
Деплой
Эволюционирующий дизайн
Меньше дефектов
Постоянное тестирование
Быстрая обратная связь
Слайд 7
Методологии
Waterfall
Spirale
Agile
Scrum
XP
Lean
…
Слайд 8
Водопад
Анализ требований
Дизайн
Разработка
Тестирование
Поддержка
Слайд 9
В чем проблема?
Единственный период, когда можно что-то узнать
о проекте – начало.
Тестирование откладывается на последнюю фазу, когда
уже поздно что-то менять
Обозначение проблемы становится проблемой
Избыточная специализация
«Это не моя проблема»
Слайд 10
Чего мы хотим?
Любое изменение, в любое время, в
любом порядке
Продуктивность, качество, низкая стоимость, высокая мораль
Реальный прогресс
Учиться на
ошибках как можно раньше
Меньше административной работы, больше работы, которая приносит пользу
Слайд 12
Организация Agile Alliance
http://agilemanifesto.org
Группа экспертов, назвавшаяся Agile Alliance (сообщество
профессионалов, занимающихся гибкими методологиями разработки), собралась в 2001 году,
чтобы обсудить ту шкалу ценностей и принципы, которые позволили бы коллективам программистов быстро вести разработку и оперативно реагировать на изменения.
Слайд 14
Agile Manifesto
Процессы и инструменты
Исчерпывающая документация
Обсуждение контракта
Следовать плану
важнее, чем
важнее,
чем
важнее, чем
важнее, чем
Слайд 15
Кому нужен этот ваш Agile?
Google
Microsoft
Yahoo
Philips
Siemens
Nokia
IBM
BBC
Яндекс
Рамблер
LinguaLeo
Adv
Red Keds
Luxoft
Deutsche Bank
Альфа банк
Слайд 16
Agile
Гибкий подход к разработке ПО.
Лучшие практики:
Scrum
XP
TDD, etc.
"Agility is not a technology, science, or product but
a culture" (Philippe Kruchten)
Слайд 17
Люди и их взаимоотношения
важнее процессов и инструментов
Люди –
важнейшая составная часть успеха.
Самый лучший процесс не спасет
проект от провала, если в команде нет сильных игроков.
Однако плохой процесс может сделать даже сильнейших игроков неэффективными.
Слайд 18
Работающая программа
важнее исчерпывающей документации (1)
Программа без документации –
это ужас. Код – не самое подходящее место для
описания назначения и структуры системы.
Команда обязана подготовить понятные человеку документы, в которых описывалась бы система и обосновывались принятые проектные решения.
Слайд 19
Работающая программа
важнее исчерпывающей документации (2)
Однако слишком много документации
хуже, чем слишком мало.
На создание огромных томов документации
уходит много времени и еще больше – на синхронизацию их с кодом.
Если же документация не соответствует коду, то становится большой и запутанной ложью и источником дезинформации.
Слайд 20
Первый закон документирования Мартина
Не создавайте документ, пока необходимость
в нем не станет очевидной и срочной.
Слайд 21
Плодотворное сотрудничество с заказчиком
важнее формальных договоренностей по контракту
(1)
Чтобы проект оказался успешным, необходимо регулярное и частое общение
с заказчиком.
Заказчик программы должен не полагаться на контракт или техническое задание, а плотно контактировать с командой разработчиков, регулярно высказывая свое мнение о том, что они сделали.
Слайд 22
Плодотворное сотрудничество с заказчиком
важнее формальных договоренностей по контракту
(2)
Самые лучшие контракты – те, что оговаривают способы взаимодействия
заказчика с разработчиками.
Слайд 23
Оперативное реагирование на изменения
важнее следования плану
Способность реагировать на
изменения часто определяет успех или провал программного проекта.
Строя планы,
необходимо следить за тем, чтобы они были гибкими и могли адаптироваться к изменениям в бизнесе и технологиях.
Ход работы над программным проектом нельзя планировать на длительный срок.
Слайд 25
Agile-манифест, 12 принципов
Основополагающие принципы
Agile-манифеста
Слайд 26
Agile-манифест, принцип №1
Удовлетворение потребностей заказчика, благодаря регулярной и
ранней поставке ценного программного обеспечения
Слайд 27
Agile-манифест, принцип №2
Изменение требований приветствуется, даже на
поздних стадиях
разработки
Слайд 28
Agile-манифест, принцип №3
Частая поставка
рабочего программного обеспечения
Слайд 29
Agile-манифест, принцип №4
Ежедневное общение заказчика с разработчиками
на
протяжении всего проекта
Слайд 30
Agile-манифест, принцип №5
Проектом занимаются мотивированные личности, которые обеспечены
нужными условиями работы, поддержкой и доверием
Слайд 31
Agile-манифест, принцип №6
Рекомендуемый метод передачи информации — личный
разговор
Слайд 32
Agile-манифест, принцип №7
Работающий продукт —
основной показатель прогресса
Слайд 33
Agile-манифест, принцип №8
Спонсоры, разработчики и пользователи должны иметь
возможность поддерживать постоянный темп
на неопределённый срок
Слайд 34
Agile-манифест, принцип №9
Внимание к техническому совершенству
и качеству
проектирования
Слайд 35
Agile-манифест, принцип №10
Простота —
искусство не делать лишней работы;
Слайд 36
Agile-манифест, принцип №11
Лучшие требования, архитектурные и технические решения
рождаются у самоорганизующихся команд.
Слайд 37
Agile-манифест, принцип №12
Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать стиль своей работы
Слайд 42
Ценности Agile
Гибкость и простота
Частые релизы
Самоорганизующаяся команда
Больше общения
Слайд 43
Гибкость и простота
Agile-процессы готовы к изменениям требований даже
на поздних этапах разработки.
Важна простота - искусство увеличения
объема работ, которых удалось избежать.
Слайд 44
Частые релизы
Наивысший приоритет -
удовлетворенность заказчика:
ранние и периодические
поставки ПО
ПО работающее и ценное для заказчика
Продолжительность каждой
итерации - от пары недель до пары месяцев.
Предпочтение - коротким интервалам.
Слайд 45
Самоорганизующаяся команда
Над проектом работают мотивированные люди.
Создаются все условия,
поддержка и полное доверие.
Самые лучшие архитектуры, требования и
дизайны систем создаются самоорганизующимися командами.
Команда сама организует оптимальный процесс.
Слайд 46
Больше общения
Потенциальные пользователи системы и разработчики должны работать
вместе
на протяжении всего проекта.
Самый действенный и эффективный
способ обмена информацией
как внутри команды разработчиков, так и
с внешним миром - непосредственное общение.
Слайд 47
Scrum
Наиболее распространенная практика разработки в Agile.
Ключевые термины:
Product backlog
User
story
Product owner
Sprint
Sprint backlog: tasks
Daily scrum
Scrum master
Taskboard
Слайд 48
Product Backlog
Содержит список функциональных единиц системы (“user stories”),
запланированных на след релиз
Слайд 49
Product Backlog
Product backlog один на весь релиз
Им владеет
менеджер продукта (“product owner”)
Он не статичен – записи можно
добавлять, удалять, менять им приоритет
Общедоступен, но поддерживается одним человеком
Слайд 50
Спринт (Sprint)
Фаза разработки состоит из нескольких итераций –
спринтов.
Обычно спринт длится 2-4 недели.
Этапы:
Планирование
Разработка
Демонстрация
Ретроспектива
Слайд 51
Sprint Backlog
Описывает задачи, запланированные командой на спринт
Задачи –
действия, необходимые для реализации запланированной на спринт функциональности
В описание
задачи входит ее оценка
Слайд 52
Планирование (Sprint Planning)
Проводится в начале спринта
Участвует вся команда
User
stories разбиваются на задачи и оцениваются членами команды
В результате
команда подписывается на ту функциональность, на которую хватает времени спринта
Слайд 53
Оценка
Для оценки выбирается единица – идеальный человеко-день…или зеленый
крокодил
Следует оценить помехи (например focus factor между 0 и
1) перед каждым спринтом
Результаты предыдущего спринта помогают лучше запланировать следующий
Слайд 54
Ежедневный скрам (Daily Scrum)
Проводится каждый день в фиксированное
время
Рекомендуется проводить стоя в течение 10-15 минут
Если что-то нужно
обсудить, назначается время после скрама
Слайд 55
Вопросы
Scrum Master спрашивает каждого:
Что ты делал?
Что ты собираешься
делать?
Какие были проблемы?
Слайд 57
Демонстрация (ревью)
В конце каждого спринта проводится ревью
Это демонстрация
реализованной функциональности
В ней может участвовать любой человек, задействованный в
проекте
В идеале после каждой демонстрации можно отправлять продукт заказчику
Слайд 58
Ретроспектива спринта
После каждого спринта (ревью)
Участвуют все члены команды
Цель
- осознать:
Что было хорошо?
Что могло бы быть лучше
Это обсуждение
процесса, а не технических сложностей
