http://techtalks.nsu.ru 15 марта 2012. Методологии разработки ПО (Семён Факторович и Алексей Сапожков, Noveo) «Семён Факторович (Noveo) рассказывает про методологии разработки и про то, что на самом деле скрывается за словами "scrum" и "agile"» Лекция прочитана в рамках проекта Tech Talks @NSU – серии открытых лекций о разработке ПО и карьере в IT, проводимых в Новосибирском государственном университете. Подробности: http://techtalks.nsu.ru

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

2. О чем сегодня пойдет речь
 Эволюция процессов разработки: от «сели
и наколбасили» до промышленных
стандартов
 Методологии разработки — что это такое?
 Что на самом деле скрывается под словами
scrum и agile.

3. Хранение исходного кода
 Удобнее всего, конечно работать над
проектом в одиночку
 Как только появляется второй
разработчик, сразу возникает проблема
передачи изменений в коде
 Всё уже придумано до нас: системы
контроля версий (SVN, CVS, git, Mercurial)

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

5. Системы контроля версий
 Без системы контроля версий разработка
более-менее серьезных проектов
немыслима
 Они совсем не лишние и для учебных и
собственных проектов

6. Системы контроля версий
 SVN: требует центрального сервера.
Можно поставить свой, а можно
воспользоваться code.google.com
 git, Mercurial: не требуют сервера, можно
пользоваться локально

7. Отслеживание задач
 Процесс разработки не всегда линеен
 Решения типа «продолжить делать новые
фичи или поправить дефекты в старых?»
 «Я нашел у себя в проекте 25 багов, в каком
порядке мне их делать? Как удержать их в
голове?»

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

9. Багтрекер

10. Багтрекер

11. Багтрекеры
 Нашли баг в программе? Заведите новый
тикет в багтрекере
 Укажите последовательность действий,
приводящую к ошибке, какое поведение
ожидалось, и что происходит на самом
деле

12. Багтрекеры
 Статусы тикетов (недавно открытый, в
прогрессе, закрытый…)
 Смена владельца тикета (разработчик,
тестировщик)

13. Багтрекеры
 Если вы хостите свой проект на
code.google.com или GitHub, то багтрекер
входит в комплект
 Бесплатный багтрекер можно поднять на
своем сервере (Trac, Bugzilla, Redmine)

14. Багтрекеры
 Как это ни смешно, есть компании, не
использующие ни багтрекеры, ни системы
контроля версий
 По возможности, избегайте их
 Joel Spolsky, “The JoelTest”

15. Ведение проекта — разноплановый
процесс
 Выяснение требований перед началом
разработки
 Очередность фич и представление
промежуточных релизов заказчику
 Процессы тестирования и code review
 Документирование написанного кода

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

17. Понятие методологии разработки
 Исторически разработка ПО считалась
разновидностью инженерных процессов
 Первые методологии разработки ПО (70-е
годы) напоминают производственные
инструкции

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

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

20. Классическая модель: waterfall
2. «Пока не закончим проектирование — реализацию не
начнем»

21. Недостатки waterfall
 Очень сложно адаптируема к проектам с
нечеткими требованиями
 Очень грустно, когда заказчик в середине
проекта придумывает что-то новое
 Первоначальное проектирование и
написание документации может занять
очень много времени (иногда больше, чем
создание первого прототипа)

22. Новое веяние:
agile methodologies
 «Гибкие методологии»
 Методологии, диктующие менее жесткие
правила разработки
 Начали появляться в середине 90-х,
окончательно оформились в 2001 в “Agile
Manifesto”

23. 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

24. Гибкие методологии, основные
принципы
 Разработка итерациями: сделали набор
функциональности, протестировали, показали
заказчику, перешли к следующему набору фич
 Меньший акцент на проектировании и
документировании
 Уход от жесткой организационной структуры
(команда может работать вообще без менеджера)

25. Гибкие методологии, основные
принципы
И что, сработало?

26. Плюсы для разработчиков
 Снижение уровня бюрократии (изменение
архитектуры или новую фичу не нужно
согласовывать)
 Значительно меньше документации
 «Садимся и делаем»

27. А с точки зрения бизнеса?
 Для слабо специфицированных проектов —
самое оно! (да и для всех остальных вполне
неплохо)
 Снижение затрат на документацию почти не
сказывается на качестве
 Команде разработчиков действительно не
нужно жесткое руководство

28. Интересные приемы из agile
 Экстремальное программирование
(Extreme Programming, XP) и, в частности,
парное программирование
 Test Driven Development,TDD: сначала
пишем юнит-тесты, и только потом код

29. Зрелые методологии на идеях agile
 Scrum, полноценная методология оценки и
ведения проектов
 Kanban, удобный способ организации
потока задач

30. Kanban