Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
Самое простое решение, не требующее управления, это метод очереди – кто раньше таск запостил, того тестеры и начинает проверять, выгрибая сделанные таски (с учетом приоритетов) из общего пула. Но здесь кроется проблема – тимы начинают конфликтовать под дивизом — «Почему не нас тестуют?»
Странно, если есть приоритеты и очередь, совершенно прозрачно же видно, кого и когда будут тестировать!
Как правило приоритеты тасков не более трех. 80% попадают в одну категорию. Таски стараются быть предельно мелкими — принцип Agile. В этом случае за 1 день каждая команда может сделать несколько тасков. В итоге тим тестеров получает десяток тасков за 1 день. Функциональное тестирование даже в «сером» варианте занимает не менее часа (подготовка среды и пр.)
И все становиться совсем не очевидным
И все становиться совсем не очевидным
Решали такую задачу в Kaiten.io
Есть клиент, у которого одна команда разработчиков, получает задачи от нескольких департаментов.
Если взять кейс из статьи, то выглядеть у нас это будет так:
Разработчики могут самостоятельно отправлять задачи в очередь на тестирование, но при этом должны соблюдать установленный лимит (на картинке разработчики из первой команды не могут отправить задачу в тестирование, а разработчики второй могут).
Тестировщики берут задачи из очереди в соответствии с FIFO-маркерами (цифры в квадратике в заголовке карты), которые проставляются в момент попадания задачи в очередь.
Есть клиент, у которого одна команда разработчиков, получает задачи от нескольких департаментов.
Если взять кейс из статьи, то выглядеть у нас это будет так:
Разработчики могут самостоятельно отправлять задачи в очередь на тестирование, но при этом должны соблюдать установленный лимит (на картинке разработчики из первой команды не могут отправить задачу в тестирование, а разработчики второй могут).
Тестировщики берут задачи из очереди в соответствии с FIFO-маркерами (цифры в квадратике в заголовке карты), которые проставляются в момент попадания задачи в очередь.
В принципе идея та же — дискритизировать задачи и ограничить их поступление к тестировщикам. Предложенное мною решение имеет, как мне кажется, преимущество — девелоперы делают таски, как обычно и заэмаиневают их на тим QA. Для них картина процесса не меняется. Используется обычная система TFS (например Jira или Microsoft). Тим QA выбирает каждый день таски с разными метками тимов.
Мне кажется технологически это проще. Хотя up to you
Мне кажется технологически это проще. Хотя up to you
разница в том, что не нужны выделенные дни — в тест можно брать когда удобно. Ну и разработка не прерывается, но это уже фишка канбана.
Ну да. Вот ещё хотел спросить:
1. Как решаются ситуации когда тестеры не успевают даже с учётом резервного дня?
2. Если тестеры всё успели, что они делают в резервный день?
1. Как решаются ситуации когда тестеры не успевают даже с учётом резервного дня?
2. Если тестеры всё успели, что они делают в резервный день?
Вопросы не простые.
У нас резервный день идет на:
— тесты для продакшен (но когда он наступает. то вообще все может рушиться и тимы берут Creative week, что бы не грузить тестеров)
— самообразование, например разделы автоматического тестирования
— документация, в часности создание новых тест кейсов
Если тестеры не успевают, тут та же проблема, что и не успевает тим в спринте. Во время планирования спринта задачи берутся с учетом времени на тестирование, так что это симтом плохого планирования спринта
У нас резервный день идет на:
— тесты для продакшен (но когда он наступает. то вообще все может рушиться и тимы берут Creative week, что бы не грузить тестеров)
— самообразование, например разделы автоматического тестирования
— документация, в часности создание новых тест кейсов
Если тестеры не успевают, тут та же проблема, что и не успевает тим в спринте. Во время планирования спринта задачи берутся с учетом времени на тестирование, так что это симтом плохого планирования спринта
Спасибо за ответы, интересно.
Имхо вы бы могли тестеров пересадить на канбан с хитрой очередью, а разработчики продолжили бы по скраму работать.
Имхо вы бы могли тестеров пересадить на канбан с хитрой очередью, а разработчики продолжили бы по скраму работать.
Выделение тестеров в отдельную модель по скраму или кабану мне не кажется перспективной. Дело в том, что главная задача закрыть спринты команд и сделанная девелоперами разработка не может просто повиснуть — ее надо закрыть тестами. Поэтому они не отьемлемая часть спринтов девелоперов.
Но честно методика еще в разработке — я не нашел оптимального решения и главная моя проблема — разный велосити на разработку и тестинг тасков
Но честно методика еще в разработке — я не нашел оптимального решения и главная моя проблема — разный велосити на разработку и тестинг тасков
А подходит ли скрам при такой организации производства?
Скрам предполагает работу кросс-функциональных команд, которые полностью отвечают за выполнения задачи, от её оценки и технической постановки до выпуска (подготовки) релиза. Здесь же получается, что команда зависит от отдела тестирования.
Тестировщики присутствуют на планировании и принимают участие в оценке задач?
Как команда разработчиков может взять обязательства на спринт, если она не управляет частью процесса? не знает сколько времени потребуется на тестирование и какова будет загрузка у тестировщиков?
Скрам предполагает работу кросс-функциональных команд, которые полностью отвечают за выполнения задачи, от её оценки и технической постановки до выпуска (подготовки) релиза. Здесь же получается, что команда зависит от отдела тестирования.
Тестировщики присутствуют на планировании и принимают участие в оценке задач?
Как команда разработчиков может взять обязательства на спринт, если она не управляет частью процесса? не знает сколько времени потребуется на тестирование и какова будет загрузка у тестировщиков?
Тестировщики присутствуют на спринтах и дают свою оценку, но это не меняет проблематику — приходиться уменьшать велосити.
Кажется, что у приведенной схемы есть немало других недостатков.
Например, необходимость синхронизации спринтов.
Неясно чем занимаются разработчики последние 2 дня спринта, когда основная активность — это тестирование
Добавление четвертой команды разработчиков разрушит всю стройность системы.
Команда не может управлять длительностью спринта. Что если кто-то захочет сократить её до недели, например при старте нового проекта когда важно получать быструю обратную связь.
Как вносить коррективы в случае праздников, больничных и отпусков
Например, необходимость синхронизации спринтов.
Неясно чем занимаются разработчики последние 2 дня спринта, когда основная активность — это тестирование
Добавление четвертой команды разработчиков разрушит всю стройность системы.
Команда не может управлять длительностью спринта. Что если кто-то захочет сократить её до недели, например при старте нового проекта когда важно получать быструю обратную связь.
Как вносить коррективы в случае праздников, больничных и отпусков
Простите, но вы не внимательно читали :(
Я писал, чем занимаются тимы последние 2 дня — баги из беклога
Что касается 4го, тима, то действительно придется увеличивать размер спринта. Это решение имеет ограничения. Работает в размере общей команды 20-30 человек
Изменения размеров спринта, действительно не предусмотрены, но это не является минусом, на мой взгляд.
Коррективы по праздникам вносятся просто — сдвиг. Остальные изменения моделью скрама не предусмотрены и на мой взгляд ведут к анархии
Я писал, чем занимаются тимы последние 2 дня — баги из беклога
Что касается 4го, тима, то действительно придется увеличивать размер спринта. Это решение имеет ограничения. Работает в размере общей команды 20-30 человек
Изменения размеров спринта, действительно не предусмотрены, но это не является минусом, на мой взгляд.
Коррективы по праздникам вносятся просто — сдвиг. Остальные изменения моделью скрама не предусмотрены и на мой взгляд ведут к анархии
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Time Division Multiplexing (TDM) в управлениии критическим ресурсом проекта