Практики гибкой разработки. Пётр Адрианов
TRANSCRIPT
ПРАКТИКИ ГИБКОЙ РАЗРАБОТКИ
и Гарри Поттер
ЧТО ТАКОЕ SCRUM Методология гибкого управления проектом Ограничен горизонт планирования Взаимозаменяемые разработчики
SPRINT.ИТЕРАЦИЯ Заказчик
определяет, какие задачи наиболее важны на ближайшее время
Продолжительность от 2 до 4 недель. Фиксированная. У нас - 2 недели
В каждом спринте есть регулярные митинги
DAILY STANDUP MEETING.ЕЖЕДНЕВНЫЙ СТАТУС По 5 минут на человека Что сделал. Более-менее подробно, а не "работал на задачей
#1234" Что буду делать Что не получается Мы пишем просто в чат Slack сообщение с тэгом #status в
12:30 каждый день
PLANNING POKER.ОЦЕНОЧНЫЙ МИТИНГ Каждый разработчик говорит, сколько
задача занимает в поинтах (1, 2, 3, 5, 8 - числа Фибоначчи)
Если оценка меньше или больше, чем у других, — обосновывает
Проясняются непонятные моменты
ЖИЗНЕННЫЙ ЦИКЛ ЗАДАЧИ Формулировка Оценка Выполнение Code review Деплой на стейджинг Тестирование Деплой на продакшен Демонстрация
ФОРМУЛИРОВКА ЗАДАЧИ Простыми словами или в виде пользовательской истории Простыми словами: <Глагол> <Ведущий к результату>.
Добавить логотип компании на главную страницу Пользовательская история: <Когда> <Роль>, то он
<Получает результат/Может сделать>[, <Чтобы что>]. Когда пользователь заходит на главную, то он видит логотип компании, чтобы понимать, где он находится
Критерии готовности
CODE REVIEW.РЕВЬЮ КОДА Создаётся Pull Request на
GitHub Hound проверяет style
guide Vexor проверяет юнит-
тесты Два разработчика ставят
палец вверх Второй разработчик
мёржит задачу в ветку master
Ветки develop у нас нет и это сознательно
РАСПРЕДЕЛЕНИЕ ЗАДАЧ Разработчик берёт верхнюю задачу из Backlog и делает её Создаёт ветку в git: feature/short-description-1234, fix/short-
description-1234, chore/short-description-1234 Если нужна специальная компетенция (frontend), помечаем
тэгом. Её берёт только тот, кто умеет Если задача может быть сделана только после другой, то
пишем After #1234 (Task title)
КОГДА НАДО СРОЧНО Выписываете, что именно надо срочно Выписываете, кто есть в команде Распределяете объём работ по дням по каждому человеку Созываете совещание. Обрисовываете ситуацию, почему надо
срочно Каждый день контролируете Не слишком часто (~1 раз в 2 месяца)
ТЕСТИРОВАНИЕ Разработчик, когда сделал
задачу, пишет доку "How to test". В Scrum - "How to demo"
Выкладывает на стейджинг Тестировщик тестирует и либо
принимает, либо пишет замечания и отправляет на доработку
ДЕМОНСТРАЦИЯ Каждый понедельник созваниваемся в Hangouts с заказчиком Открываю список сделанных задач Шарю экран и демонстрирую в браузере Заранее проделываю это с утра сам с собой, чтобы успеть
исправить, если что-то не так
РЕТРОСПЕКТИВА Обзор результатов спринта Что было хорошо Что можно сделать лучше
(Замедляет работу команды или мешает работе)
Акцент на том, что затрагивает всю команду
