Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Crystal Agile. Процесс
обеспечивающий качество.
Igor Bondarenko. Intetics Co.
Состав команды и её
особенности
• 5 Менеджеров
• Распределенная команда:
– 3 центра разработки
– 11 разработчиков
• Разраб...
Внедрение процесса
2/27
Артефакты
1.Резерв проекта
2.Резерв спринта
3.Планирование с игрой в покер
4.Ежедневные митинги
5.Диаграмма сгорания
3/27
Что-то пошло не так?!
• Тестирование «внезапно» стало сваливаться на
последние 4-5 дней итерации
• Резерв спринта не закры...
Анализ проблем
• Неэффективное планирование.
• Система оценки времени на разработку
неэффективна
• Невозможно закрыть спри...
Выбор средства решения
проблем
• Прогнуться под
процесс
• Своя методология
6/27
Crystal Agile
• Human-powered
• Ultralight
• Stretch-to-fit
7/27
Решение проблем
8/27
Внутренне качество
1. Внедряем TDD
2. Сталкиваемся с проблемами на этапе внедрения
3. Отказываемся от TDD в пользу BDD
9/27
Проблемы планирования
• Члены команды разбиты на группы, поддерживающие
разные модули
• Разработчики используют разные язы...
Проблемы покера
• Каждый член команды имеет равный вес, что влечет за
собой возможность недооценки или переоценки
необходи...
Что делать?
Переходим от покера планирования к методу взвешенных экспертных
оценок
1. В планировании участвуют только те к...
Плюсы подобного подхода
• Оценки стали более точными, что позволяет рационально
планировать время тестировщика в спринте
•...
Невозможность закрыть
резерв спринта
• Некоторые страны не успевают дать список задач до
начала планирования
• В любой мом...
Двух зайцев одним
выстрелом
1. Работаем с «горящими» задачами
При 10-дневном спринте каждый загружается на 9 дней.
В итоге...
Технический долг
Внутренний бэклог проекта содержит такие задачи как:
• Рефакторинг
• Написание юнит- и компонентных тесто...
Митинги
Проблема:
5 менеджеров в разных странах. Количество звонков порой
доходило до 5 в день.
Решение проблемы:
• Назнач...
Стэндапы не нужны?
Перенос этой активности в Jira:
• Start Work – Stop Work
• Активность за день описывается в таске одним...
Начало автоматизации
Наличие «некрасивого»
автотеста значительно
лучше, нежели его отсутсвие
19/27
Положительное влияние
«некрасивых тестов»
Плюсы таких тестов в начале проекта:
• Быстро создаются
• Предоставляют быструю ...
SoapUI для сервисов
• Низкий порог вхождения
• Возможность быстро создать test suite для запуска
полного теста в один клик...
Вовлечение разработчиков:
демонстрация
Цель: «Подсадить» программистов на тестирование
1. Демонстрация работы автотестов и...
Вовлечение разработчиков:
обучение
1. Возвращаем «подсевших» на качество разработчиков в
родную стихию:
- Переход от IDE к...
Agile?
24/27
Заключение
• Гибкая методология может быть гибко приспособлена
под нужды команды
• Не стоит бояться экспериментов с техник...
Что-то еще?
26/27
Вопросы
Email: bondarenko.ihar@yandex.ru
Skype: igor.bondarenko1
Upcoming SlideShare
Loading in …5
×

Crystal Agile, или как мы приспособили процесс разработки для обеспечения максимального качества

3,084 views

Published on

Published in: Education
  • Be the first to comment

Crystal Agile, или как мы приспособили процесс разработки для обеспечения максимального качества

  1. 1. Crystal Agile. Процесс обеспечивающий качество. Igor Bondarenko. Intetics Co.
  2. 2. Состав команды и её особенности • 5 Менеджеров • Распределенная команда: – 3 центра разработки – 11 разработчиков • Разработчики имеют выраженную специализацию • 1 тестировщик 1/27
  3. 3. Внедрение процесса 2/27
  4. 4. Артефакты 1.Резерв проекта 2.Резерв спринта 3.Планирование с игрой в покер 4.Ежедневные митинги 5.Диаграмма сгорания 3/27
  5. 5. Что-то пошло не так?! • Тестирование «внезапно» стало сваливаться на последние 4-5 дней итерации • Резерв спринта не закрывался после планирования • Митинги отнимают много времени • Автоматизация отсутствует 4/27
  6. 6. Анализ проблем • Неэффективное планирование. • Система оценки времени на разработку неэффективна • Невозможно закрыть спринт после планирования итерации • В угоду скорости страдает качество кода, накапливается технический долг • Время тестировщика тратится на активности не связанные с тестированием 5/27
  7. 7. Выбор средства решения проблем • Прогнуться под процесс • Своя методология 6/27
  8. 8. Crystal Agile • Human-powered • Ultralight • Stretch-to-fit 7/27
  9. 9. Решение проблем 8/27
  10. 10. Внутренне качество 1. Внедряем TDD 2. Сталкиваемся с проблемами на этапе внедрения 3. Отказываемся от TDD в пользу BDD 9/27
  11. 11. Проблемы планирования • Члены команды разбиты на группы, поддерживающие разные модули • Разработчики используют разные языки программирования • Внутри групп используются различные по сложности технологии • Покер планирования не работает 10/27
  12. 12. Проблемы покера • Каждый член команды имеет равный вес, что влечет за собой возможность недооценки или переоценки необходимого времени • Время тестировщика оценивается всей командой 11/27
  13. 13. Что делать? Переходим от покера планирования к методу взвешенных экспертных оценок 1. В планировании участвуют только те кто будет разрабатывать 2. Вес голоса зависит от «релевантности» разработчика 3. Коэффициенты зависят от предыдущей эффективности 4. Обязательно вводим в планирование время на юнит тесты, не даем оценок только по функционалу 5. Время на тестирование оценивается тестировщиком совместно с ответственным разработчиком 6. Планирование нацелено на сокращение простоев тестировщика 12/27
  14. 14. Плюсы подобного подхода • Оценки стали более точными, что позволяет рационально планировать время тестировщика в спринте • Оценки учитывают все аспекты разработки (BDD, интеграционное тестирование) 13/27
  15. 15. Невозможность закрыть резерв спринта • Некоторые страны не успевают дать список задач до начала планирования • В любой момент может появиться «горящая» задача 14/27
  16. 16. Двух зайцев одним выстрелом 1. Работаем с «горящими» задачами При 10-дневном спринте каждый загружается на 9 дней. В итоге каждый член команды имеет день в запасе на urgent задачи. Как мы работаем с такими задачами: • Если приходит задача емкость которой в человеко-часах больше, чем наш резерв – задача переносится на следующий спринт • Задачи меньшего размера берутся в работу лишь до того момента, пока есть резерв 2. Уменьшаем технический долг 15/27
  17. 17. Технический долг Внутренний бэклог проекта содержит такие задачи как: • Рефакторинг • Написание юнит- и компонентных тестов • Написание автотестов по готовым сценариям • Работа с to-do 16/27
  18. 18. Митинги Проблема: 5 менеджеров в разных странах. Количество звонков порой доходило до 5 в день. Решение проблемы: • Назначение ответственного за разработку задачи • Ограждение обычных разработчиков от лишних обсуждений • Смена ответственных по окончании итерации 17/27
  19. 19. Стэндапы не нужны? Перенос этой активности в Jira: • Start Work – Stop Work • Активность за день описывается в таске одним кратким, но понятным комментарием. 18/27
  20. 20. Начало автоматизации Наличие «некрасивого» автотеста значительно лучше, нежели его отсутсвие 19/27
  21. 21. Положительное влияние «некрасивых тестов» Плюсы таких тестов в начале проекта: • Быстро создаются • Предоставляют быструю обратную связь • Помогают вовлечь разработчиков в тестирование • Являются заготовками для будущих «красивых» тестов 20/27
  22. 22. SoapUI для сервисов • Низкий порог вхождения • Возможность быстро создать test suite для запуска полного теста в один клик • Тесты можно включить в CI • Возможность разрабатывать тесты используя Mocks параллельно с имплементацией • Возможность создания Load и Security тестов 21/27
  23. 23. Вовлечение разработчиков: демонстрация Цель: «Подсадить» программистов на тестирование 1. Демонстрация работы автотестов и объяснение основого смысла: - Быстрая обратная связь - Возможность быстро и самостоятельно проверить качество перед коммитом 2. Демонстрация Selenium IDE 22/27
  24. 24. Вовлечение разработчиков: обучение 1. Возвращаем «подсевших» на качество разработчиков в родную стихию: - Переход от IDE к RC или WebDriver - Выделение времени на перевод старых тестов с IDE на Java 2. SoapUI тесты для неподдатливых: - Обучение созданию - Расширение возможностей с Groovy - CI 23/27
  25. 25. Agile? 24/27
  26. 26. Заключение • Гибкая методология может быть гибко приспособлена под нужды команды • Не стоит бояться экспериментов с техниками • По настоящему высокого качества можно достигнуть лишь тогда когда над этим работает вся команда. • В команде должен быть человек, который недоволен текущим процессом 25/27
  27. 27. Что-то еще? 26/27
  28. 28. Вопросы Email: bondarenko.ihar@yandex.ru Skype: igor.bondarenko1

×