--}}
Новая тема
Вы не можете создавать новые темы.
Т.к. вы неавторизованы на сайте. Пожалуйста назовите себя или зарегистрируйтесь.
Список тем

Agile scrum. Как там тестировщики успевают работать?

Серьёзная тема
785
23
С друзьями на NN.RU
В социальных сетях
Поделиться
Привет!
В конторе начинаем внедрять scrum. Опытных людей нет. Одни теоретике. Может здесь у кого есть опыт?

Есть у нас список задач. Берем их в работу на 2 недели. В конце второй недели мы реализовали задачи. Получили релиз. А когда тестировщикам тестировать?
Или надо планировать чтобы программисты написали код за неделю, а потом тестировщик тестировали 2 дня (эти два дня программисты отдыхают?) и три дня на исправление ошибок? Так?
Old voron
16.12.2018
Что значит когда тестировать, стори поинты закладываются в том числе и на тестирование, пока фича не протестирована, сторя не закрывается, какой в опу релиз.
256
17.12.2018
т.е. qa ждут пока программисты сделают работу. Затем программисты ждут пока тестеры сделают свою работу, так?
Old voron
17.12.2018
Не совсем, хотя большая доля правды в этом есть. QA могут заранее готвить тест кейсы, но не всегда это возможно. И естественно они должны протестировать фичу когда программист поставил ее в Джире в соответсвующий статус. На предпланировании и планировании спринта, естественно, закладываются стори поинты на тестирование. Ну а смок и регресс тоже никто не отменял если это релиз кастомерский. Код фриз и фикс багов. Но это, вроде, азбука. :)
Slepoi
17.12.2018
пока проги пишут код, тестировщики пишут тесты, если конечно у вас не макак тестирование
256
17.12.2018
не понял. можно подробней
Johnney
17.12.2018
Все гибкое это про команду. Команда определяет, что войдет в спринт ориентируясь, естественно, на потребности бизнеса и не забывая про то, что всегда есть технический долг и новые фичи не должны занимать 100% времени, долги надо закрывать. 2 недели есть на весь спринт а не только на разработку. Поэтому все начинается с митинга по планированию в котором участвует вся команда (ну можно не вся, можно лиды). Определились с скопом задач, решили что сделаете за две недели, разработчики начинают писать код, тестеры готовить покрытие и тестовые данные + еще должно остаться время на регресс. Вот и смотрите.
256
17.12.2018
Johnney писал(а)
Команда определяет, что войдет в спринт ориентируясь, естественно, на потребности бизнеса

Единственный ориентир это приоритет от продукт овнера

Johnney писал(а)
всегда есть технический долг и новые фичи не должны занимать 100% времени, долги надо закрывать.

это задачи с прошлого спринта?

Johnney писал(а)
разработчики начинают писать код, тестеры готовить покрытие и тестовые данные + еще должно остаться время на регресс.

не получается занять всех равномерно. получается что кто-то ожидает кого-то (тестер программиста или наоборот) - это простой.
Johnney
17.12.2018
Продакт вам озвучивает позицию бизнеса. Вы на планировании разбираете все хотелки, определеяете сколько команда сможет сделать за спринт с учетом всех работ. Еще раз - на планировании вся команда и продакт в том числе, он скорректирует приоритеты. Определились с объемом, разобрали фичи. QA не должны знакомиться с фичей уже после ее реализации это ведет к большим рискам. Пошли работать. Разработчики пишут код, тестировщики готовят кейсы - все параллельно, никто не простаивает. Задачи разработчики завершают не синхронно, к тому же всегда есть тот самый технический долг (да это может быть что-то с прошлых релизов, задачи с низким приоритетом, которые откладываются-откладываются копятся..но не исчезают же и т.д. долг он и есть долг). Закончил писать код - передал в тестирование, сколько там раз вернется на доработку это бабушка на двое. Протестировали все задачи из спринта, собрали билд, залили на предпрод - qa прогоняют функциональный тест (из тех самых кейсов, которые готовили и которые уже использовали при тестировании отдельных задач, но нужно и в билде это сделать, а то знаете ли мерж, туда-сюда, косяки запросто всплывают,) + регресс, в этот самый момент уже можно начинать планировать следующий спринт. Нет простоев. Кроме того у всех и всегда куча работы по оптимизации и поддержке. Если появилась свободная минута - потрать ее на поддержку кейсов (или автоматизацию регресса или поддержку автотестов) или на документацию - она, представьте себе, тоже нужна и то, что вы хотите скрам, не значит что документации не должно быть совсем. Почитайте манифест там нигде не говорится о том, что процессов совсем нет и документации совсем нет, все это тоже работа, которая требует времени. Кроме того если у qa появилось время (ну вдруг, ну вот вдруг оно появилось - хотя в реальной жизни это практически сказка), всегда можно заняться разными полезными вещами (тут не известно какие виды тестирования у вас проводятся и какие вам нужны и все ли вы успеваете - в общем много неизвестных). Откуда простоям браться - я не знай.
256
17.12.2018
Товарища попросил ответить за меня. Мне (Петр Петрович Иванов) - запретили здесь отвечать. Безобразие!
LukA
18.12.2018
Похоже у Вас полная каша в голове и процессах.
Прежде чем внедрять технологию было бы неплохо поизучать её и понять вообще она к вашему продукту и стилю разработки применима или нет.
Кто и зачем решил вводить скрам? И почему именно его? В аджайл есть и другие методики, многое зависит от продукта. Да и сам аджайл не идеален, он только манифест, не дающий готовых рецептов и гарантированных результатов.
Если нет денег на нормальный тренинг хотя бы для тимлидов, то хоть почитать, в сети полно информации.
LukA писал(а)
Прежде чем внедрять технологию было бы неплохо поизучать её и понять вообще она к вашему продукту и стилю разработки применима или нет.

"Это, сынок, фантастика!" (с)
кто же у нас перед внедрением технологии её изучает? никто!
LukA
18.12.2018
И инструкцию читают , в лучшем случае, когда что-то сломалось или пошло не так.
scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Russian.pdf

Если сами к этому не пришли (так или иначе), то не надо вам этот scrum. Если пришли, то не надо вам этот Guide.

Команда оценивает и планирует истории (User Story) из журнала (Sprint Backlog, составленный Product Owner (PO)) с аналитикой, QA и разработкой. Через пару-тройку спринтов набирается статистика и можно вводить SP (Story Point), до этого меряете в идеальных часах (коих в рабочем дне около 6, у крутых команд, у обычных 3-4). Команда - QA инженеры и программные инженеры (могут и лучше бы были кроссфункциональными). Так же может приписаться аналитик и/или эксперт предметной области. Закончить историю без регрессионного теста запрещено законом. Отсюда проступает важность хороших QA, которые могут в автоматизацию и православного CI/CD, которые могут осчастливить автоматизацией Delivery, хоть на TEST, хоть на UAT, хоть на PROD. Да и TDD никто не отменял.

Может не надо вас в IT? Каркасу SCRUM/scrum сто лет в обед. Уже гибридизация пошла давно. АГИЛ :)
256
21.12.2018
Спасибо за отличный документ и информацию!
Sergey Pravodelov писал(а)
Команда оценивает и планирует истории (User Story) из журнала (Sprint Backlog, ...

Путаете с Product Backlog, а Sprint Backlog уже в спринте если что.
256
21.12.2018
У нас есть список задач для реализации на две неделе, но через день появляются новые задачи. Некоторые из новых задач важнее все других, а некоторые нет. Если придерживаться плана и не брать новые очень важные задачи, то нарушаем принцип гибкой разработки и заказчик нас не поймет. Пихать эти новые важные задачи на самый верх списка задач, но тогда ломаем спринт и не достигаем цели спринта. Как здесь быть?
может быть вам канбан лучше подойдет?
www.atlassian.com/agile/kanban/kanban-vs-scrum
256
21.12.2018
в них разницы почти нет.
но канбан вроде то больше подходит ) Надо разобраться в нем хорошо, что посоветуете почитать?

Спасибо!
я, если честно, в процессы как самоцель, да еще и по книжкам, не верю (ну либо правильной книжки тоже не встречал) Ж)

весь вот этот вот догматизм - "у вас нет А - у вас не агиль" считаю что от лукавого

в моей практике - обычно не целиком теорию переносили, а какие-то элементы брали и затачивали под проект,
чтобы адресовать какие-то проблемные вещи - аля проблемы коммуникаций и недостаточную проработанность требований,
расширение крос-компетенций команды и распространение знаний, етс
kamorin
25.12.2018
Плюс. И про канбан, и про процессы ради процессов.
Интересно смотреть на команды, которым из раза в раз заказчик подсовывает новые требования и задачи в середине спринта, а разработчики потом на ретроспективе бьются головой об стол, что спринт профакаплен, потому что не все запланированные задачи сделаны. При этом заказчик доволен, а команда в печали:) Какой-то этот скрам не слишком гибкий. Да и разработчики.
Johnney
25.12.2018
Ни то и ни другое. Это не очень такие менеджеры, которые работают с бизнесом. Не умение планировать работу. Знаимаются исключительно тушением пожаров))
Slepoi
24.12.2018
или переносить срок релиза или выкидывать менее приоритетные задачи
Новая тема
Вы не можете создавать новые темы.
Т.к. вы неавторизованы на сайте. Пожалуйста назовите себя или зарегистрируйтесь.
Список тем
Универсальный фрезерный станок 6720В

Универсальный фрезерный станок 6720В Станки предназначены для горизонтального фрезерования цилиндрическими, дисковыми, фасонными...

Универсальный фрезерный станок FUS-32

Универсальный фрезерный станок FUS-32 Широкоуниверсальный фрезерный станок FUS-32 Размеры раб. поверхности стола : 950×450...

Горизонтально-фрезерный станок 6Р81

Горизонтально-фрезерный станок 6Р81 Размеры рабочей поверхности стола, мм 1000х250 Число Т-образных пазов стола 4 Ширина Т-образного...

Универсальный фрезерный станок ALG-100Е

Универсально-фрезерный станок ALG-100Е Главный шпиндель Количество скоростей шпинделя – 16 Числа оборотов шпинделя, об/мин...

Frontend-разработчик Profit Search
40000 -
50000 руб.
Стаж работы 3-5 лет, частичная занятость
Разработчик .net Profit Search
70000 -
100000 руб.
Неполное среднее образование, стаж работы 3-5 лет, полная занятость
Программист 1С НПП ПРО-М
от 110 000 руб.
Высшее образование, стаж работы 3-5 лет, полная занятость
Программист-разработчик Full-Stack ГК "Kolobox"
70000 -
100000 руб.
Высшее образование, стаж работы более 5 лет, полная занятость