Tech Talks @NSU: Методологии разработки ПО. Что на самом деле...

Post on 14-Apr-2017

49 views 0 download

transcript

Методологии разработки ПО

О чем сегодня пойдет речь

Эволюция процессов разработки: от «сели и наколбасили» до промышленных стандартов

Методологии разработки — что это такое?

Что на самом деле скрывается под словами scrum и agile.

Хранение исходного кода

Удобнее всего, конечно работать над проектом в одиночку

Как только появляется второй разработчик, сразу возникает проблема передачи изменений в коде

Всё уже придумано до нас: системы контроля версий (SVN, CVS, git, Mercurial)

Системы контроля версий

Системы контроля версий

Без системы контроля версий разработка более-менее серьезных проектов немыслима

Они совсем не лишние и для учебных и собственных проектов

Системы контроля версий

SVN: требует центрального сервера. Можно поставить свой, а можно воспользоваться code.google.com

git, Mercurial: не требуют сервера, можно пользоваться локально

Отслеживание задач

Процесс разработки не всегда линеен

Решения типа «продолжить делать новые фичи или поправить дефекты в старых?»

«Я нашел у себя в проекте 25 багов, в каком порядке мне их делать? Как удержать их в голове?»

Отслеживание задач

Багтрекер (bugtracker), система отслеживания дефектов

Багтрекер

Багтрекер

Багтрекеры

Нашли баг в программе? Заведите новый тикет в багтрекере

Укажите последовательность действий, приводящую к ошибке, какое поведение ожидалось, и что происходит на самом деле

Багтрекеры

Статусы тикетов (недавно открытый, в прогрессе, закрытый…)

Смена владельца тикета (разработчик, тестировщик)

Багтрекеры

Если вы хостите свой проект на code.google.com или GitHub, то багтрекер входит в комплект

Бесплатный багтрекер можно поднять на своем сервере (Trac, Bugzilla, Redmine)

Багтрекеры

Как это ни смешно, есть компании, не использующие ни багтрекеры, ни системы контроля версий

По возможности, избегайте их

Joel Spolsky, “The Joel Test”

Ведение проекта — разноплановый процесс

Выяснение требований перед началом разработки

Очередность фич и представление промежуточных релизов заказчику

Процессы тестирования и code review

Документирование написанного кода

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

Методология — алгоритм разработки программных проектов

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

Исторически разработка ПО считалась разновидностью инженерных процессов

Первые методологии разработки ПО (70-е годы) напоминают производственные инструкции

Классическая модель: waterfall

Классическая модель: waterfall

1. «Пока не зафиксируем все требования — дальше не пойдем!»

Классическая модель: waterfall

2. «Пока не закончим проектирование — реализацию не начнем»

Недостатки waterfall

Очень сложно адаптируема к проектам с нечеткими требованиями

Очень грустно, когда заказчик в середине проекта придумывает что-то новое

Первоначальное проектирование и написание документации может занять очень много времени (иногда больше, чем создание первого прототипа)

Новое веяние: agile methodologies

«Гибкие методологии»

Методологии, диктующие менее жесткие правила разработки

Начали появляться в середине 90-х, окончательно оформились в 2001 в “Agile Manifesto”

Agile Manifesto

We value:

Individuals and interactions over processes and tools

Working software over comprehensive

documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

Гибкие методологии, основные принципы

Разработка итерациями: сделали набор функциональности, протестировали, показали заказчику, перешли к следующему набору фич

Меньший акцент на проектировании и документировании

Уход от жесткой организационной структуры (команда может работать вообще без менеджера)

Гибкие методологии, основные принципы

И что, сработало?

Плюсы для разработчиков

Снижение уровня бюрократии (изменение архитектуры или новую фичу не нужно согласовывать)

Значительно меньше документации

«Садимся и делаем»

А с точки зрения бизнеса?

Для слабо специфицированных проектов —самое оно! (да и для всех остальных вполне неплохо)

Снижение затрат на документацию почти не сказывается на качестве

Команде разработчиков действительно не нужно жесткое руководство

Интересные приемы из agile

Экстремальное программирование (Extreme Programming, XP) и, в частности, парное программирование

Test Driven Development, TDD: сначала пишем юнит-тесты, и только потом код

Зрелые методологии на идеях agile

Scrum, полноценная методология оценки и ведения проектов

Kanban, удобный способ организации потока задач

Kanban