Гибкая разработка
Катаев Денис
Тинькофф Банк
Выпускник ИВТ-08В
О себе
Python разработчик
Окончил БФ ПНИПУ в 2013 году
Переехал в Екатеринбург
Окончил магистратуру УрФУ в 2017
Сейчас аспирант в УрФУ и работаю в Тинькофф
AGILE - гибкий
Гибкая методология разработки
А зачем?
Что это дает?
ПРОЕКТЫ
Зачем вообще планировать?
УСПЕШНЫЙ ПРОЕКТ
-
В срок ⌛️
-
В бюджет 💰
-
В рамках спецификации 📝
-
Заказчик доволен 😀
Борьба со сложностью
Waterfall, картинка из 70-х
Кризис разработки
1965-1986 гг
- Срок разработки ПО ~3 года
- 10 летний пример OS/360 на которой работало 1000 программистов
- Плохая безопасность ПО
- Софт убивал: из-за ошибки в ПО рентген аппарата
Agile Manifesto
2001 год
Люди и взаимодействие
Работающий продукт
Сотрудничество с заказчиком
Готовность к изменениям
Процессы и инструменты
Исчерпывающая документация
Согласование условий контракта
Следование первоначальному плану
Ценности
Agile Manifesto
Принципы
- Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.
- Изменение требований приветствуется, даже на поздних стадиях разработки. Agile процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.
- Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.
- На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.
- Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.
- Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.
- Работающий продукт — основной показатель прогресса.
- Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.
- Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.
- Простота — искусство минимизации лишней работы — крайне необходима.
- Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.
- Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.
Agile Manifesto
Практики
Scrum
Сущности в Scrum
- Бэклог
- Планирование спринта: Что? Как?
- Митинг: вчера, сегодня, проблемы
- Демо: показываем что сделано, собираем об.связь
- Ретроспектива: +, -, улучшения процесса разработки
- Груминг: анализ бэклога, выкидываем устаревшее
- Бэклог
- Планирование спринта: Что? Как?
- Митинг: вчера, сегодня, проблемы
- Демо: показываем что сделано, собираем об.связь
- Ретроспектива: +, -, улучшения процесса разработки
- Груминг: анализ бэклога, выкидываем устаревшее
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
Визуализация требований
Обсуждения проблем
Официант ⟶ Врач
-
Пишем ✍️
-
Проговариваем 🗣
-
Подтверждаем 📋
Передача на сторону не работает просто так:
Нужны не только "фотографии из отпуска"
Пользовательская история
Кто:___________
Что:___________
Почему: ________
Как проверить? Пограничные случаи?
Бизнес-ограничения?
Детали поведения? Какая польза для заказчиков?
Какие оценки по времени? Какие зависимости?
Риски? Статусы?
Scrum есть
Agile'а нет
