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

Спасибо!

Контакты:Антон Демин (докладчик): anton.demin@xored.comОльга Краснянская (HR): olga.krasnyanskaya@xored.com