Гибкие методологии разработки ПО в реальном мире

http://techtalks.nsu.ru

Гибкие методологии разработки ПО в реальном мире (Антон Дёмин, Xored)

На этой лекции мы рассмотрим классические модели управления проектами, поговорим о реалиях разработки и о наиболее частых проектных проблемах, с которыми сталкиваются разработчики и менеджеры.

Среди прочего мы рассмотрим гибкие методологии; как в общем, так и на примере их конкретных представителей (Scrum, XP, Kanban). Также будет рассказано о процессе перехода на Scrum на примере крупного проекта для одного из клиентов компании.

Кроме того, поскольку гибкие методологии подразумевают гибкие правила, мы прямо на лекции попробуем модифицировать одну из хрестоматийных методологий под нужды конкретного проекта, а именно — немного доработаем Scrum путем добавления в него артефактов из других методологий.

Подробности: http://techtalks.nsu.ru

Transcript

1. Agile в реальном мире
2. Содержание доклада • Зачем нужны модели и методологии разработки ПО? • Реалии разработки программного обеспечения • Обзор основных моделей разработки ПО • Опыт внедрения Scrum в команде • Бесплатные средства/сервисы для улучшения качества ПО
3. Зачем? • Продукт должен быть завершен и должен соответствовать требованиям • Продукт должен быть качественным • Сроки должны быть предсказуемы
4. Зачем программисту? • Трезвая оценка своих сил • Удовольствие от достижения поставленных целей • Никаких меньше переработок, авралов, страданий • Повышение квалификации через взаимодействие с командой • Возможность всем говорить, что у вас Scrum, XP, $METHODOLOGY_NAME
5. Реалии разработки ПО
6. Самый плохой вариант
7. Cowboy koding
9. Заказчик принимает проект
10. В итоге • Заваленные сроки • Баги, тысячи их • Переработки • Упадок мотивации • Злые шутки про программистов
11. Модели процесса разработки ПО Модель предсказывает поведение систем
12. Водопад (каскадная модель)
13. Спиральная
14. Итеративная
15. Методологии разработки ПО Методология разработки ПО - это набор рекомендаций и правил, направленных на то, чтобы система функционировала.
16. Гибкие (Agile) методологии разработки ПО Гибкие методологии ориентируются на: • Взаимодействие внутри группы • Готовность к изменениям требований • Эволюционное развитие продукта
17. Agile-манифест • Люди и взаимодействие важнее процессов и инструментов • Работающий продукт важнее исчерпывающей документации • Сотрудничество с заказчиком важнее согласования условий контракта • Готовность к изменениям важнее следования первоначальному плану http://agilemanifesto.org/iso/ru/
18. Методологии, основанные на Agile • Экстремальное программирование (XP) • Kanban • Scrum • ...
19. 10th Annual State of Agile Survey – VersionOne
20. XP • Большое внимание уделяется тестированию • Непрерывная интеграция/доставка • KISS (Keep It Simple Stupid) • Парное программирование • Короткие итерации • Тесное взаимодействие с заказчиком • Частый и простой рефакторинг (п. 1)
21. Kanban • Визуализация производства (конвейер) • Ограничение одновременного количества задач • Отсутствие спринтов • Нет как такового планирования
22. Kanban
23. Scrum • Итерации (спринты) • Бэклог проекта/спринта • Планирование • Scrum-митинги • Демо • Ретроспектива
24. Плюсы Scrum • Предсказуемый результат • Задачи отсортированы по приоритету • Рабочий продукт (новый функционал) каждую итерацию • Вся команда вовлечена в процесс
26. Scrum board
27. Основные роли в Scrum
28. Product owner (владелец продукта) • Представляет интересы пользователей • Формирует требования • Решает какой функционал включать в релиз
29. Scrum master • Проводит ежедневные митинги • Следит за правилами • Технически подкован • Принимает участие в Scrum of Scrums
30. Development team (команда) • Разработка • Тестирование • Автономная самодостаточная команда • Все вовлечены в процесс • Включает в себя все основные роли
31. Опыт внедрения Scrum • Отрицание • Гнев • Торг • Депрессия • Принятие • … • PROFIT!
32. Основные техники
33. Немного о проекте и требованиях • Является частью большого Enterprise проекта • Проект является фреймворком (используется разработчиками) • Необходимы относительно частые релизы (2-4 раза в месяц) • Требуется высокая стабильность и предсказуемость • Необходимо взаимодействие с пользователями фреймворка
34. Рекомендации по переходу • Гибкая методология - гибкий переход • Нужно понимать для чего тот или иной артефакт методологии • Переходить желательно постепенно, поочередно внедряя те или иные практики • Scrum - не цель, а средство
35. 1. Приоритет задач
36. 2. Итерации • Короткие, 1-3 недели • Начало в один и тот же день недели • Итерации выровнены по командам на всем проекте
37. 3. Совещания (Meetings) • Короткие 10-15 минут • Без технических подробностей • Что сделали с последнего совещания, что сделаем к следующему, какие есть трудности
38. 4. Планирования итераций • Производится каждую итерацию • Занимает 1-2 часа
39. 5. Ретроспективы • Результат итерации • Обзор успехов/сложностей итерации • Что продолжаем делать, что прекращаем делать, что попробуем в следующей итерации • Работа над ошибками
40. 6. Демо • Демонстрация результатов • Все принимают участие • Демонстрируется только готовый функционал
41. Burndown
42. Модификация Scrum • Гибкая методология - гибкие правила • Scrum - не религия • Scrum можно сделать удобнее добавляя/удаляя артефакты • Использовать практики необходимо с умом • Люди и взаимодействие важнее процессов и инструментов
45. • Planning Poker бесполезен в случае, если команда состоит из одного разработчика и тестировщика • TDD, Code Review и некоторые другие элементы не нужны на прототипах • Планирование не имеет смысла, если программист занимается ТОЛЬКО багфиксами • Story Points (те самые попугаи) неприменимы в командах в случае если члены команды не равны по квалификации. Клиент/ПМ просит оценку в часах • Метрики производительности команды сводят работу больше к набору очков, чем к выполнению задач
46. Что добавили? • Непрерывная интеграция • Многоуровневое тестирование • Коллективное владение кодом • Рефакторинг • Brainstorming
47. Что убрали? • Покер планирования • Очки скрама • Дополнительные роли
48. Что делать с багами? • Вводить резерв на багфиксы 10-25% • Организовывать систему по примеру стека (при добавлении чего то более важного в спринт, что-то менее важное выпадает)
49. А с тестированием? • QA как разделяемый ресурс • QA как часть команды • QA отсутствует
50. Когда Agile НЕ работает • Медицинское, военное, космическое ПО • Исследовательская работа • Гос-заказы • Если нет цели создавать качественное ПО в разумные сроки • Все остальные случаи, когда ничего не поможет, такие как низкая квалификация, отсутствие бюджета, нереальные сроки
51. Контроль версий, инспекция кода (Code review) https://github.com https://bitbucket.org
52. Непрерывная интеграция https://jenkins.io https://jetbrains.com/teamcity https://travis-ci.org
53. Вспомогательные средства https://trello.com https://draw.io https://slack.com
54. https://quiz.xored.com
55. Спасибо! Контакты: Антон Демин (докладчик): anton.demin@xored.com Ольга Краснянская (HR): olga.krasnyanskaya@xored.com