Гибкая разработка

Катаев Денис

Тинькофф Банк

Выпускник ИВТ-08В

О себе

Python разработчик

Окончил БФ ПНИПУ в 2013 году

Переехал в Екатеринбург

Окончил магистратуру УрФУ в 2017

Сейчас аспирант в УрФУ и работаю в Тинькофф

AGILE - гибкий

Гибкая методология разработки

А зачем?

Что это дает?

ПРОЕКТЫ

Зачем вообще планировать?

УСПЕШНЫЙ ПРОЕКТ

1. В срок ⌛️

2. В бюджет 💰

3. В рамках спецификации 📝

4. Заказчик доволен 😀

Борьба со сложностью

Waterfall, картинка из 70-х

Кризис разработки

1965-1986 гг

• Срок разработки ПО ~3 года
• 10 летний пример OS/360 на которой работало 1000 программистов
• Плохая безопасность ПО
• Софт убивал: из-за ошибки в ПО рентген аппарата 

Agile Manifesto

2001 год

Люди и взаимодействие 

Работающий продукт

Сотрудничество с заказчиком

Готовность к изменениям

Процессы и инструменты

Исчерпывающая документация

Согласование условий контракта

Следование первоначальному плану

Ценности

Agile Manifesto

Принципы

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки. Agile процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый  процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Agile Manifesto

Практики

Scrum

Сущности в Scrum

1. Бэклог 
2. Планирование спринта: Что? Как?
3. Митинг: вчера, сегодня, проблемы
4. Демо: показываем что сделано, собираем об.связь
5. Ретроспектива: +, -, улучшения процесса разработки
6. Груминг: анализ бэклога, выкидываем устаревшее

1. Бэклог 
2. Планирование спринта: Что? Как?
3. Митинг: вчера, сегодня, проблемы
4. Демо: показываем что сделано, собираем об.связь
5. Ретроспектива: +, -, улучшения процесса разработки
6. Груминг: анализ бэклога, выкидываем устаревшее

1

2

3

1

4

5

6

Роли в Scrum

Команда (7±2 человек)

Scrum Мастер

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

Kanban

Kanban

Бизнес процесс

Система массового обслуживания

Kanban

Push VS Pull

Теория ограничений

Kanban

WIP лимиты

Kanban

Bottleneck

Kanban

Экономическая модель потерь

Операционные расходы

Координационные расходы

"Ошибочная" нагрузка

Kanban

Источники вариативности

Внутренние - случайные причины

Внешние - выявляемые причины

UserStories

Техническое задание

Почему бывают проблемы даже если оно ЕСТЬ

Документа мало. И N+1 документ тоже не поможет

Идеальный документ

ЕГО НЕ СУЩЕСТВУЕТ

Читают одно, но понимают по разному!

MVP

Разработка через исследование

User Story Map

Визуализация требований

Обсуждения проблем

Официант ⟶ Врач

1. Пишем ✍️

2. Проговариваем 🗣

3. Подтверждаем 📋

Передача на сторону не работает просто так:

Нужны не только "фотографии из отпуска"

Пользовательская история

Кто:___________

Что:___________

Почему: ________

Как проверить? Пограничные случаи?

Бизнес-ограничения?

Детали поведения? Какая польза для заказчиков?

Какие оценки по времени? Какие зависимости?

Риски? Статусы?

 

Scrum есть

Agile'а нет

Заключение

Рабочий софт в срок - реальность

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