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

Семён Факторович (Noveo) рассказывает про методологии разработки и про то, что на самом деле скрывается за словами "scrum" и "agile".

Остальные доклады: http://techtalks.nsu.ru

Transcript

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 Joel Test”
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