2. Состав команды и еѐ
особенности
• 5 Менеджеров
• Распределенная команда:
– 3 центра разработки
– 11 разработчиков
• Разработчики имеют выраженную специализацию
• 1 тестировщик
1/27
5. Что-то пошло не так?!
• Тестирование «внезапно» стало сваливаться на
последние 4-5 дней итерации
• Резерв спринта не закрывался после планирования
• Митинги отнимают много времени
• Автоматизация отсутствует
4/27
6. Анализ проблем
• Неэффективное планирование.
• Система оценки времени на разработку
неэффективна
• Невозможно закрыть спринт после планирования
итерации
• В угоду скорости страдает качество кода,
накапливается технический долг
• Время тестировщика тратится на активности не
связанные с тестированием
5/27
10. Внутренне качество
1. Внедряем TDD
2. Сталкиваемся с проблемами на этапе внедрения
3. Отказываемся от TDD в пользу BDD
9/27
11. Проблемы планирования
• Члены команды разбиты на группы, поддерживающие
разные модули
• Разработчики используют разные языки
программирования
• Внутри групп используются различные по сложности
технологии
• Покер планирования не работает
10/27
12. Проблемы покера
• Каждый член команды имеет равный вес, что влечет за
собой возможность недооценки или переоценки
необходимого времени
• Время тестировщика оценивается всей командой
11/27
13. Что делать?
Переходим от покера планирования к методу взвешенных экспертных
оценок
1. В планировании участвуют только те кто будет разрабатывать
2. Вес голоса зависит от «релевантности» разработчика
3. Коэффициенты зависят от предыдущей эффективности
4. Обязательно вводим в планирование время на юнит тесты, не даем
оценок только по функционалу
5. Время на тестирование оценивается тестировщиком совместно с
ответственным разработчиком
6. Планирование нацелено на сокращение простоев тестировщика
12/27
14. Плюсы подобного подхода
• Оценки стали более точными, что позволяет рационально
планировать время тестировщика в спринте
• Оценки учитывают все аспекты разработки (BDD,
интеграционное тестирование)
13/27
15. Невозможность закрыть
резерв спринта
• Некоторые страны не успевают дать список задач до
начала планирования
• В любой момент может появиться «горящая» задача
14/27
16. Двух зайцев одним
выстрелом
1. Работаем с «горящими» задачами
При 10-дневном спринте каждый загружается на 9 дней.
В итоге каждый член команды имеет день в запасе на urgent задачи.
Как мы работаем с такими задачами:
• Если приходит задача емкость которой в человеко-часах больше, чем
наш резерв – задача переносится на следующий спринт
• Задачи меньшего размера берутся в работу лишь до того момента,
пока есть резерв
2. Уменьшаем технический долг
15/27
17. Технический долг
Внутренний бэклог проекта содержит такие задачи как:
• Рефакторинг
• Написание юнит- и компонентных тестов
• Написание автотестов по готовым сценариям
• Работа с to-do
16/27
18. Митинги
Проблема:
5 менеджеров в разных странах. Количество звонков порой
доходило до 5 в день.
Решение проблемы:
• Назначение ответственного за разработку задачи
• Ограждение обычных разработчиков от лишних
обсуждений
• Смена ответственных по окончании итерации
17/27
19. Стэндапы не нужны?
Перенос этой активности в Jira:
• Start Work – Stop Work
• Активность за день описывается в таске одним кратким,
но понятным комментарием.
18/27
21. Положительное влияние
«некрасивых тестов»
Плюсы таких тестов в начале проекта:
• Быстро создаются
• Предоставляют быструю обратную связь
• Помогают вовлечь разработчиков в тестирование
• Являются заготовками для будущих «красивых» тестов
20/27
22. SoapUI для сервисов
• Низкий порог вхождения
• Возможность быстро создать test suite для запуска
полного теста в один клик
• Тесты можно включить в CI
• Возможность разрабатывать тесты используя Mocks
параллельно с имплементацией
• Возможность создания Load и Security тестов
21/27
23. Вовлечение разработчиков:
демонстрация
Цель: «Подсадить» программистов на тестирование
1. Демонстрация работы автотестов и объяснение основого
смысла:
- Быстрая обратная связь
- Возможность быстро и самостоятельно
проверить качество перед коммитом
2. Демонстрация Selenium IDE
22/27
24. Вовлечение разработчиков:
обучение
1. Возвращаем «подсевших» на качество разработчиков в
родную стихию:
- Переход от IDE к RC или WebDriver
- Выделение времени на перевод старых тестов с
IDE на Java
2. SoapUI тесты для неподдатливых:
- Обучение созданию
- Расширение возможностей с Groovy
- CI
23/27
26. Заключение
• Гибкая методология может быть гибко приспособлена
под нужды команды
• Не стоит бояться экспериментов с техниками
• По настоящему высокого качества можно достигнуть
лишь тогда когда над этим работает вся команда.
• В команде должен быть человек, который недоволен
текущим процессом
25/27
Менеджмент со стороны заказчика распределен по странам, с командой одновременно работает 5 менеджеровКоманда распределена: 6 разработчиков в одном офисе и 3 в другомНекоторые члены команды имеют ярко выраженную специализацию1 тестировщик
Тестирование каждый раз «внезапно» стало сваливаться на последние 4-5 дней итерацииРезерв спринта не закрывался после планированияМного митингов отнимают много времени, единственный тестировщик должен присутствовать на всех нихОснова успеха быстрых процессов – комплексная автоматизация отсутствует из-за острой нехватки времени и плохого внутреннего качества проектаВ итоге мы поняли, что внедрили на проекте процесс направленный на скорость поставки, а не на обеспечение максимального качества
Анализ проблем указал на основные недостатки нашего подхода:Неэффективное планирование.Заказчик не понимает что такое Story Point и требует оценки в часах. Точной оценки.Закрыть спринт сразу после планирования итерации невозможно, ввиду того, что мы ведем не только разработку, но и поддержку старых версийВ угоду скорости страдает качество кода, накапливается технический долгМного времени тестировщика тратится на активности не связанные с тестированием
У нас было два пути:Пользуясь «гибкостью» аджайла создать свою методологию
Нами был выбран второй вариант. Мы остановились на методологии Crystal Clear.Какие её основные характеристики:“Human-powered” means that the focus is on achieving project success through enhancing the work of the people involved (other methodologies might be process-centric, or architecture-centric, or tool-centric, but Crystal is people-centric).“Ultralight” means that for whatever the project size and priorities, a Crystal-family methodology for the project will work to reduce the paperwork, overhead and bureaucracy to the least that is practical for the parameters of that project.“Stretch-to-fit” means that you start with something just smaller than you think you need, and grow it just enough to get it the right size for you (stretching is easier, safer and more efficient than cutting away)."Человек с питанием" означает, что акцент делается на достижении успеха проекта через повышение эффективности работы людей, вовлеченных (другие методологии может быть процесс-ориентированной, или архитектура-ориентированной, или инструмент-ориентированной, но Кристалл люди-ориентированной). "Ultralight" означает, что для любой размер и приоритетов проекта, методология Кристалл-семья для проекта будет способствовать снижению документы, накладные расходы и бюрократии мере, это практично для параметров этого проекта. "Растягивание к монтажу" означает, что вы начинаете с чем-то просто меньше, чем вы думаете, вам нужно, и вырастить его достаточно только, чтобы получить это правильный размер для вас (растяжение проще, безопаснее и эффективнее, чем срезая).
Решение этой проблемы начали со внедрения TDD, как самого популярного средства в подобных ситуациях.Однако внедрение затянулось и даже почти застопорилось. Почему?Фраза «напиши тест» действует на разработчик магическим образом, он перестает понимать чего от него хотят.Что является критерием достаточности теста для каждого отдельного случая?А может быть стоит писать юнит тесты по тестовым сценариям?Если да, то какие группы тестов использовать?А как быть, если разработка началась, но тестировщик не успел написать тестовые сценарии?Вместо TDD внедряем BDD (Behavior Driven Developement).Что это такое?Фактически это техника, с помощью которой можно научить разработчика критически оценивать свой код и писать тесты.Для составления достаточного количества тестов разработчику необходимо определить поведение системы в ситуациях прямо покрытых требованиями и покрыть тестами лишь эти ветви кода. (Пример вынес в Notes)Фрэнк: Что такое стек?Линда: Это структура данных, хранящая объекты в порядке «первым вошел, последним вышел» или «последним вошел, первым вышел». Обычно у этой структуры есть API с такими методами, как push() и pop(). Иногда присутствует метод peek().Фрэнк: Что делает метод push()?Линда: Метод push() принимает входной объект, например, foo и помещает его во внутренний контейнер, например, массив. Метод push() обычно ничего не возвращает.Фрэнк: Что будет, если передать методу push() два объекта, например, сначала foo, а потом bar?Линда: Второй объект bar должен оказаться наверху концептуального стека, содержащего по крайней мере два объекта, так что при вызове метода pop() объект bar должен быть извлечен первым, до первого объекта foo. Если метод pop() вызвать еще раз, должен быть возвращен объект foo и стек должен стать пустым (предполагается, что в нем ничего не было до того, как мы добавили эти два объекта).Фрэнк: Так метод pop() удаляет самый последний элемент, добавленный в стек?Линда: Да, метод pop() должен удалить верхний элемент, при этом предполагается, что в стеке есть элементы, чтобы их удалять. Метод peek() работает точно также, но при этом объект не удаляется. Метод peek() должен оставить верхний элемент в стеке.Фрэнк: Что будет, если вызвать метод pop(), когда в стек еще ничего не было добавлено?Линда: Метод pop() должен выдать исключение, показывающее, что в стек еще ничего не добавлялось.Фрэнк: Что будет, если выполнить команду push() null?Линда: Стек должен выдать исключение, так как null не является допустимым значением для метода push().
Вторая проблема – плохое планирование. И дело не в сложности оценки в часах, дело в том, что команда разбита на группы, которые занимаются различными модулями проекта, а также используют разные технологии.Что же в таком случае плохо в Planning Poker?Каждый член команды имеет равный вес (пример 1 в ноутах) что влечет за собой возможность недооценки или переоценки необходимого времени. В итоге недооценка грозит срывом планов тестировщика. Переоценка же позволяет разработчику «филонить» в начале спринта и сдать фичу только в конце, тем самым перегружая тестировщика в конце спринта.Время тестировщика оценивается всей командой. В связи с этим сложно обосновать такие активности как написание тест-кейсов или составление спецификации по business stories.
Каждый член команды имеет равный вес (пример 1 в ноутах) что влечет за собой возможность недооценки или переоценки необходимого времени. В итоге недооценка грозит срывом планов тестировщика. Переоценка же позволяет разработчику «филонить» в начале спринта и сдать фичу только в конце, тем самым перегружая тестировщика в конце спринта.Время тестировщика оценивается всей командой. В связи с этим сложно обосновать такие активности как написание тест-кейсов или составление спецификации по business stories.Пример 1:На планировании находятся 2 Java девелопера, 1 верстальщик, 1 тестировщик, 1 Flex/Flash разработчик, 1 JavaScript девелопер. На обсуждение выносится задача по разработке front-end приложения на Flex.Оценка флексера – 12 часов. Оценка тестировщика и верстальщика – 20 часов. Остальные оценивают в 4 часа, хотя тонкостей не знают. В итоге, даже обосновав правильность своей оценки основной разработчик уменьшает время в угоду остальным до 10 часов и в итоге не укладывается в него.То же самое с переоценкой времени, если никто не понимает как работает твой модуль, очень легко обосновать 40 часов вместо необходимых 12.Такой же пример будет для каждого пункта, их у меня из личной практики не одна сотня наберется.
Если разрабатывается функциональность затрагивающая один модуль приложения – участвуют только ответственные за эту часть разработчики веса их голосов равныЕсли затрагивается комплексная фича – каждый член команды, в зависимости от модуля и используемой технологии разработки получает вес голосаВведение персональных коэффициентов зависящих от предыдущей эффективности члена команды (пример в ноутах)Обязательно вводим в тестирование время на юнит тесты, не даем оценок только по функционалуВремя на тестирование оценивается тестировщиком совместно с непосредственно ответственным за разработку девелоперамПланирование ведется с учетом того, чтобы тестировщик начал работу в первый день спринта и не имел простоев в середине цикла и не был перегружен в конце (пример в ноутах)Пример:Разработчик 1 последние три спринта недооценивал время – даем ему повышающий коэффициент 1.2Разработчик 2 наоборот имеет склонность к переоценке времени – вводим понижающий коэффициент 0.7Пример 2: Идеальный цикл таков: Дни 1-2: Составление чеклистов по новым фичамДни 3-4: Начало тестирования, либо написание автотестов на фичи из предыдущих релизовДни 5-8: Тестирование по функциональностей по мере готовностиДень 9: Code freeze и полная регрессияДень 10: Поставка и UATТакже будет сопровождающая пояснения временная диаграмма
При планировании мы исходим из того, что при 10-дневном спринт мы берем из бэклога задач лишь на 9 дней.В итоге каждый член команды имеет день в запасе на urgent задачи.
Что делать, если срочных задач не появилось?Если кто-либо из команды не получил незапланированное задание, он берет первую по приоритету задачу из этого бэклога и занимается ей.
Каждый спринт выбирается член команды ответственный за каждую разрабатываемую фичу, в митингах участвует только он. Остальные занимаются работой.Ответственные меняются каждый спринт (если конечно функциональность не растянута на несколько спринтов, в таком случае смысла в смене человека нет).
Мы решили избавиться также от стэндап митингов.Почему?Зачем верстальщику, который пришел на работу в 8 утра и работающему над приложением А, знать что вчера делал разработчик. который пришел на работу в 12 и работает над приложением Б, которое не пересекается с А?А если нужно узнать статус?Мы перешли на Jira. Каждый день начиная работу над таском, разработчк жмет кнопку Start Work, уходя с работы делает Stop Work.Активность за день описывается в таске одним кратким, но понятным комментарием.
