Гибкие методологии разработки ПО в реальном мире
-
Upload
tech-talks-nsu -
Category
Education
-
view
230 -
download
3
Transcript of Гибкие методологии разработки ПО в реальном мире
Agile в реальном мире
Содержание доклада
● Зачем нужны модели и методологии разработки ПО?● Реалии разработки программного обеспечения● Обзор основных моделей разработки ПО● Опыт внедрения Scrum в команде● Бесплатные средства/сервисы для улучшения качества ПО
Зачем?
● Продукт должен быть завершен и должен соответствовать требованиям
● Продукт должен быть качественным● Сроки должны быть предсказуемы
Зачем программисту?
● Трезвая оценка своих сил● Удовольствие от достижения поставленных целей● Никаких меньше переработок, авралов, страданий● Повышение квалификации через взаимодействие с командой● Возможность всем говорить, что у вас Scrum, XP,
$METHODOLOGY_NAME
Реалии разработки ПО
Самый плохой вариант
Cowboy koding
Заказчик принимает проект
В итоге
● Заваленные сроки● Баги, тысячи их● Переработки● Упадок мотивации● Злые шутки про программистов
Модели процесса разработки ПО
Модель предсказывает поведение систем
Водопад (каскадная модель)
Спиральная
Итеративная
Методологии разработки ПО
Методология разработки ПО - это набор рекомендаций и правил, направленных на то, чтобы система функционировала.
Гибкие (Agile) методологии разработки ПО
Гибкие методологии ориентируются на:
● Взаимодействие внутри группы● Готовность к изменениям требований● Эволюционное развитие продукта
Agile-манифест
● Люди и взаимодействие важнее процессов и инструментов● Работающий продукт важнее исчерпывающей документации● Сотрудничество с заказчиком важнее согласования условий
контракта● Готовность к изменениям важнее следования
первоначальному плану
http://agilemanifesto.org/iso/ru/
Методологии, основанные на Agile
● Экстремальное программирование (XP)● Kanban● Scrum● ...
10th Annual State of Agile Survey – VersionOne
XP
● Большое внимание уделяется тестированию● Непрерывная интеграция/доставка● KISS (Keep It Simple Stupid)● Парное программирование● Короткие итерации● Тесное взаимодействие с заказчиком● Частый и простой рефакторинг (п. 1)
Kanban
● Визуализация производства (конвейер)● Ограничение одновременного количества задач● Отсутствие спринтов● Нет как такового планирования
Kanban
Scrum
● Итерации (спринты)● Бэклог проекта/спринта● Планирование● Scrum-митинги● Демо● Ретроспектива
Плюсы Scrum
● Предсказуемый результат● Задачи отсортированы по приоритету● Рабочий продукт (новый функционал) каждую итерацию● Вся команда вовлечена в процесс
Scrum board
Основные роли в Scrum
Product owner (владелец продукта)
● Представляет интересы пользователей
● Формирует требования● Решает какой функционал
включать в релиз
Scrum master
● Проводит ежедневные митинги● Следит за правилами● Технически подкован● Принимает участие в Scrum of
Scrums
Development team (команда)
● Разработка● Тестирование● Автономная самодостаточная
команда● Все вовлечены в процесс● Включает в себя все основные
роли
Опыт внедрения Scrum
● Отрицание● Гнев ● Торг ● Депрессия● Принятие● …● PROFIT!
Основные техники
Немного о проекте и требованиях
● Является частью большого Enterprise проекта● Проект является фреймворком (используется разработчиками)● Необходимы относительно частые релизы (2-4 раза в месяц)● Требуется высокая стабильность и предсказуемость● Необходимо взаимодействие с пользователями фреймворка
Рекомендации по переходу
● Гибкая методология - гибкий переход● Нужно понимать для чего тот или иной артефакт методологии● Переходить желательно постепенно, поочередно внедряя те или
иные практики● Scrum - не цель, а средство
1. Приоритет задач
2. Итерации
● Короткие, 1-3 недели● Начало в один и тот же день недели● Итерации выровнены по командам на всем проекте
3. Совещания (Meetings)
● Короткие 10-15 минут● Без технических подробностей● Что сделали с последнего совещания, что сделаем к
следующему, какие есть трудности
4. Планирования итераций
● Производится каждую итерацию● Занимает 1-2 часа
5. Ретроспективы
● Результат итерации● Обзор успехов/сложностей итерации● Что продолжаем делать, что прекращаем делать, что попробуем
в следующей итерации● Работа над ошибками
6. Демо
● Демонстрация результатов● Все принимают участие● Демонстрируется только готовый функционал
Burndown
Модификация Scrum
● Гибкая методология - гибкие правила● Scrum - не религия● Scrum можно сделать удобнее добавляя/удаляя артефакты● Использовать практики необходимо с умом● Люди и взаимодействие важнее процессов и инструментов
● Planning Poker бесполезен в случае, если команда состоит из одного разработчика и тестировщика
● TDD, Code Review и некоторые другие элементы не нужны на прототипах
● Планирование не имеет смысла, если программист занимается ТОЛЬКО багфиксами
● Story Points (те самые попугаи) неприменимы в командах в случае если члены команды не равны по квалификации. Клиент/ПМ просит оценку в часах
● Метрики производительности команды сводят работу больше к набору очков, чем к выполнению задач
Что добавили?
● Непрерывная интеграция● Многоуровневое тестирование ● Коллективное владение кодом● Рефакторинг● Brainstorming
Что убрали?
● Покер планирования● Очки скрама● Дополнительные роли
Что делать с багами?
● Вводить резерв на багфиксы 10-25%● Организовывать систему по примеру стека (при добавлении чего
то более важного в спринт, что-то менее важное выпадает)
А с тестированием?
● QA как разделяемый ресурс● QA как часть команды● QA отсутствует
Когда Agile НЕ работает
● Медицинское, военное, космическое ПО● Исследовательская работа● Гос-заказы● Если нет цели создавать качественное ПО в разумные сроки● Все остальные случаи, когда ничего не поможет, такие как низкая
квалификация, отсутствие бюджета, нереальные сроки
Контроль версий, инспекция кода (Code review)
https://github.com
https://bitbucket.org
Непрерывная интеграция
https://jenkins.io
https://jetbrains.com/teamcity
https://travis-ci.org
Вспомогательные средства
https://trello.com
https://draw.io
https://slack.com
https://quiz.xored.com
Спасибо!
Контакты:Антон Демин (докладчик): [email protected]Ольга Краснянская (HR): [email protected]