Tech Talks @NSU: Методологии разработки ПО. Что на самом деле скрывается за словами "scrum"и "agile"
- 2. О чем сегодня пойдет речь Эволюция процессов разработки: от «сели и наколбасили» до промышленных стандартов Методологии разработки — что это такое? Что на самом деле скрывается под словами scrum и agile.
- 3. Хранение исходного кода Удобнее всего, конечно работать над проектом в одиночку Как только появляется второй разработчик, сразу возникает проблема передачи изменений в коде Всё уже придумано до нас: системы контроля версий (SVN, CVS, git, Mercurial)
- 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-е годы) напоминают производственные инструкции
- 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