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: процесс
обеспечивающий качество
Состав команды
• 5 Менеджеров
• Распределенная команда:
– 3 центра разработки
– 11 разработчиков
• Разработчики имеют выра...
Внедрение процесса
Артефакты
1.Резерв проекта
2.Резерв спринта
3.Планирование с игрой в покер
4.Ежедневные митинги
5.Диаграмма сгорания
Что-то пошло не так?
• Тестирование «внезапно» стало сваливаться на
последние 4-5 дней итерации
• Резерв спринта не закрыв...
Анализ проблем
• Неэффективное планирование.
• Система оценки времени на разработку
неэффективна
• Невозможно закрыть спри...
Что дальше?
Лучше.Хуже
Время
col1
Выбираем решение
• Прогнуться под
процесс
• Своя методология
Crystal Agile
• Human-powered
• Ultralight
• Stretch-to-fit
Решение проблем
Внутреннее качество
1.Внедряем TDD
2.Сталкиваемся с проблемами на этапе
внедрения
3.Отказываемся от TDD в пользу BDD
Проблемы планирования
• Члены команды разбиты на группы,
поддерживающие разные модули
• Разработчики используют разные язы...
Проблемы покера
• Каждый член команды имеет равный вес,
что влечет за собой возможность
недооценки или переоценки необходи...
Что делать?
Переходим от покера планирования к методу взвешенных
экспертных оценок
1. В планировании участвуют только те к...
Плючы подхода
• Оценки стали более точными, что
позволяет рационально планировать время
тестировщика в спринте
• Оценки уч...
Спринт не резиновый
• Некоторые страны не успевают дать список
задач до начала планирования
• В любой момент может появить...
Двух зайцев одним
выстрелом
1. Работаем с «горящими» задачами
При 10-дневном спринте каждый загружается на 9 дней.
В итоге...
Технический долг
Внутренний бэклог проекта содержит такие
задачи как:
• Рефакторинг
• Написание юнит- и компонентных тесто...
Митинги
Проблема:
5 менеджеров в разных странах. Количество звонков порой
доходило до 5 в день.
Решение проблемы:
• Назнач...
Стендапы не нужны?
Перенос этой активности в Jira:
• Start Work – Stop Work
• Активность за день описывается в таске
одним...
Внедряем автоматизацию
Наличие
«некрасивого»
автотеста
значительно лучше,
нежели его
отсутсвие
Плюсы «некрасивых»
тестов
Плюсы таких тестов в начале проекта:
• Быстро создаются
• Предоставляют быструю обратную связь
•...
Сервисы?
• Низкий порог вхождения
• Возможность быстро создать test suite для запуска полного
теста в один клик
• Тесты мо...
Резработчики: привлекаем
внимание
Цель: «Подсадить» программистов на тестирование
1. Демонстрация работы автотестов и объя...
Разработчики: обучение
1. Возвращаем «подсевших» на качество разработчиков в родную
стихию:
- Переход от IDE к RC или WebD...
Agile?
Заключение
• Гибкая методология может быть гибко приспособлена под
нужды команды
• Не стоит бояться экспериментов с техник...
+375-44-751 75
99
Вопросы
Igor.bondarenko@neklo.com
Upcoming SlideShare
Loading in …5
×

QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного на максимальное качество продукта

614 views

Published on

В своем докладе я расскажу о том, как мы адаптировали процесс разработки, в команде, где упор делался на максимальное качество и при этом был всего 1 тестировщик.
Доклад будет состоять из двух частей. В первой я расскажу как взяв за основу методологию Crystal Agile мы скомпоновали набор из необходимых нам практик, отсекая все лишнее и получили процесс полностью устраивающий команду, направленный на обеспечение максимального качества.
В этой части будут подниматься следующие вопросы: •Какие практики наиболее ценны с точки зрения тестировщика
•Как безболезненно добавить практики XP и Kanban в Scrum процесс
•Как не отсечь лишнего -Как превратить скомпонованный набор практик в работающий подход
Вторая часть доклада будет посвящена непосредственно тому, как облегчить жизнь единственного тестировщика на большом проекте, в частности будут рассмотрены такие вопросы? •Как научить заказчика писать требования
•Быстрое создание и поддержка тестовой документации, миф или реальность?
•Быстрое внедрение автоматизации
•Тестирование нефункциональных требований

Published in: Technology
  • Be the first to comment

QA Fest 2014. Игорь Бондаренко. Agile crystal. Создание процесса нацеленного на максимальное качество продукта

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

×