Scrum. Pivotal Tracker. Планирование спринта. Демонстрация результатов.

1. ПРАКТИКИ ГИБКОЙ
РАЗРАБОТКИ
и Гарри Поттер

2. ЧТОТАКОЕ SCRUM
 Методология гибкого управления проектом
 Ограничен горизонт планирования
 Взаимозаменяемые разработчики

3. SPRINT.
ИТЕРАЦИЯ
 Заказчик определяет,
какие задачи
наиболее важны на
ближайшее время
 Продолжительность
от 2 до 4 недель.
Фиксированная. У нас
- 2 недели
 В каждом спринте
есть регулярные
митинги

4. DAILY STANDUP MEETING.
ЕЖЕДНЕВНЫЙ СТАТУС
 По 5 минут на человека
 Что сделал. Более-менее подробно, а не "работал на задачей #1234"
 Что буду делать
 Что не получается
 Мы пишем просто в чат Slack сообщение с тэгом #status в 12:30 каждый день

5. PLANNING POKER.
ОЦЕНОЧНЫЙ МИТИНГ
 Каждый разработчик говорит, сколько задача
занимает в поинтах (1, 2, 3, 5, 8 - числа
Фибоначчи)
 Если оценка меньше или больше, чем у других, —
обосновывает
 Проясняются непонятные моменты

6. ЖИЗНЕННЫЙ ЦИКЛ ЗАДАЧИ
 Формулировка
 Оценка
 Выполнение
 Code review
 Деплой на стейджинг
 Тестирование
 Деплой на продакшен
 Демонстрация

8. ФОРМУЛИРОВКА ЗАДАЧИ
 Простыми словами или в виде пользовательской истории
 Простыми словами: <Глагол> <Ведущий к результату>. Добавить логотип
компании на главную страницу
 Пользовательская история: <Когда> <Роль>, то он <Получает
результат/Может сделать>[, <Чтобы что>]. Когда пользователь заходит на
главную, то он видит логотип компании, чтобы понимать, где он находится
 Критерии готовности

9. CODE REVIEW.
РЕВЬЮ КОДА
 Создаётся Pull Request на
GitHub
 Hound проверяет style guide
 Vexor проверяет юнит-тесты
 Два разработчика ставят палец
вверх
 Второй разработчик мёржит
задачу в ветку master
 Ветки develop у нас нет и это
сознательно

10. РАСПРЕДЕЛЕНИЕ ЗАДАЧ
 Разработчик берёт верхнюю задачу из Backlog и делает её
 Создаёт ветку в git: feature/short-description-1234, fix/short-description-1234,
chore/short-description-1234
 Если нужна специальная компетенция (frontend), помечаем тэгом. Её берёт
только тот, кто умеет
 Если задача может быть сделана только после другой, то пишем After #1234
(Task title)

11. КОГДА НАДО СРОЧНО
 Выписываете, что именно надо срочно
 Выписываете, кто есть в команде
 Распределяете объём работ по дням по каждому человеку
 Созываете совещание. Обрисовываете ситуацию, почему надо срочно
 Каждый день контролируете
 Не слишком часто (~1 раз в 2 месяца)

12. ТЕСТИРОВАНИЕ
 Разработчик, когда сделал задачу,
пишет доку "How to test". В Scrum -
"How to demo"
 Выкладывает на стейджинг
 Тестировщик тестирует и либо
принимает, либо пишет замечания и
отправляет на доработку

13. ДЕМОНСТРАЦИЯ
 Каждый понедельник созваниваемся в Hangouts с заказчиком
 Открываю список сделанных задач
 Шарю экран и демонстрирую в браузере
 Заранее проделываю это с утра сам с собой, чтобы успеть исправить, если
что-то не так

14. РЕТРОСПЕКТИВА
 Обзор результатов спринта
 Что было хорошо
 Что можно сделать лучше
(Замедляет работу команды или
мешает работе)
 Акцент на том, что затрагивает всю
команду

15. ВОПРОСЫ?
Спасибо
ПётрАдрианов
RubyTeam Lead
NTR Lab
28 апреля 2016
padrianov@ntrlab.com
peter.adrianov@gmail.com