Доклад обсуждает реалии разработки программного обеспечения с акцентом на методологии agile, включая внедрение Scrum и Kanban. Рассматриваются преимущества гибких методологий, такие как улучшение качества продукта и предсказуемость сроков, а также опыт внедрения и рекомендации по переходу на новые практики. Также упоминаются важные аспекты взаимодействия в команде и необходимости постоянных улучшений в процессе разработки.

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