Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.
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
Prochain SlideShare
Chargement dans…5
×

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

731 vues

Publié le

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

Publié dans : Technologie
  • Identifiez-vous pour voir les commentaires

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

×