С сегодняшнего мероприятия про #agile

Подписка на #agile

Agile в Пенсионном фонде Самарской области

Артем а можно посмотреть на график велосити за 4-6 мес. ?

https://docs.google.com/spreadsheets/d/10Ds0ECA4_SYyiCFeH8SaASjLz_PxcGxSYKLTrN0rAsg/edit#gid=0 Отвлекли немного, сразу скажу почему не в jira - тестеры истории закрывают часто уже после фактического закрытия в жире спринта и она счиатает их не закрытыми. Барьер между делаем и сделали не поулчается пока всегда в рамках спринта переходить.

прикольно. спринт - 2 недели?

если все ок, то да. Если проблема с беклогом или просят что-то срочно, то неделя

похоже на скрам

https://docs.google.com/spreadsheets/d/10Ds0ECA4_SYyiCFeH8SaASjLz_PxcGxSYKLTrN0rAsg/edit#gid=0 Отвлекли немного, сразу скажу почему не в jira - тестеры истории закрывают часто уже после фактического закрытия в жире спринта и она счиатает их не закрытыми. Барьер между делаем и сделали не поулчается пока всегда в рамках спринта переходить.

У вас DoD по историям не включает в себя тестирование и выкатку 😱😱😱 ???

я не знаю что такое DoD )

Agile в Пенсионном фонде Самарской области

Взяли набор гибких инструментов и сделали под себя. Замечательно

я не знаю что такое DoD )

Definitions of Done

я не знаю что такое DoD )

В Скрам Гайде целый раздел про это

я не читал скрам гайд )

А, ну получается так, выкатка в 2 клика делается, тут нечего включать, Критерии приемки нууу не идеальные, но есть, показываются на демо. А вот отношение тестеров к задаче получается не включено, да.

А если тестеры найдут баги, а вы уже закрыли историю?

Истории закрывают тестеры, на баги всегда берется определенный запас на следующую итерацию. Другими словами тестировани и выкладка результатов спринта Х происходят во время Х+1 спринта.

Ну точнее не так, тестирование историй идет в рамках спринта, они первоначально просматриваются, по итогам спринта все улетает на тестовый сервак.

А вот все что нашли уже там правится в следующем.

похоже на скрам

А еще у нас ретро нет =) так что на скрам пока не похоже, но мы лезем на свет

А что у всех прям к концу спринта законченные выполненные протестированные и принятые истории получаются? (

Протетсированные истории получается только в продакшене когда их пользователь попробует

так что не парьтесь

тестер не пользователь продукта, он вообще функцию свою вполнить не может, если это не библиотека приклданая разрабатывается

Протетсированные истории получается только в продакшене когда их пользователь попробует

а протестированные тестировщиками?

это просто деньги слитые

или нежелание нанять несколько программистов на автоматиацию :)

программист делает задачу ц е л и к о м

это не для всех, так что не парьтесь

программист делает задачу ц е л и к о м

то есть в вашей системе координат тестировщики в принципе не нужны? программист делает задачу пишет тесты, а остальное клиенты потестят? просто интересно

нет, тестят ux специалисты и менеджеры, потому что они ближе к клиенту

тестировщик которые не умеет ux, программирование или какую-то другую часть, которую в продукте может сам реализовать - оторван от продукта

возьмите автопром, кого вы позовете машину тестировать :) а двигатель?

тестировщик пойдет найдет 25 багов которые пользователь никогда не найдет, и убедит разработчиков их поправить

тестировщик пойдет найдет 25 багов которые пользователь никогда не найдет, и убедит разработчиков их поправить

тестировщик находит 25 багов, менеджер их приоритезирует и чтото отдает на доделку, чтото откладывает на пофиксить когдато потом, а чтото выкидывает вообще

ну деньги можно просто есть

такой же эффект

тестировщик пойдет найдет 25 багов которые пользователь никогда не найдет, и убедит разработчиков их поправить

DoD решает вопрос, как договорились, так и правильно ;), важно же нанести пользу

ну вы просто предлагаете тратить на тестирование время обычно более дорогих сотрудников чем тестировщики

Ну это не противоречит :)

это не проедание денег?

я не предлагаю :)

ну и дешевые специалисты это последние люди, которые должны что-то тестировать

это не проедание денег?

если не гнаться за локальными оптимизациями, то может быть это и неважно

это мнение

Я же говорил про команду

Понятно, что командны. Но команда состоит из людей, а понятие сложности у всех разное. Предельный случай. Команда из двух человек, один ямокопатель, который умеет чуть-чуть красить, другой покрасчик слонов, который немного умеет копать (t-shaped ребята, все как надо). Есть 2 задачи, на рытье ямы и покраску слона. И вот как должна решать команда, какая из них проще, а какая сложнее, если одному сложно одно, а другому - другое?

Хорошо, допустим они договорились, что если каждый из них будет делать то, в чем он лучше и у них эти задачи займут примерно одинаковое время, то будем считать их [задачи] одинаковыми по сложности. Хотя это уже привязка ко времени и ни разу не фен-шуйно. Потому мы для слоника купил пульверизатор и покраска его станет в 2 раза легче. Тогда получается, что у нас SP по одним задачам будут в два раза легче SP других задач.

это мнение

а какой по вашему должен быть идеальный состав команды? я так понял тестировщиков мы исключаем)

Я просто считаю, что проверять работу людей может только тот, кто ее может делать (хотя бы частично). :)

А кто там в команде нужен чтобы хорошо делать от ситуации зависит.

👍

Профессия "тестировщик" в вебе существует в основном в СНГ

В западных вакансиях это обычно -инженер.

а QA?

Угу

qa developer

Баг, найденный тестировщиком, намного дешевле бага, найденного пользователем.

проверяли?

ну вы просто предлагаете тратить на тестирование время обычно более дорогих сотрудников чем тестировщики

Когда вы пишете "дорогие специалисты" - имеете в виду более опытные или если чувак получает больше бабла, ему не положено баги фиксить?

Я бы не хотел, чтобы баг ПО на атомной станции нашел оператор.

я надеюсь баги в ПО атомных станций ищут не тестировщики без инженерного бэкграунда :))

я надеюсь баги в ПО атомных станций ищут не тестировщики без инженерного бэкграунда :))

А как это связано с изначальным вопросом? Тестировщики это не только "кликеры".

я надеюсь баги в ПО атомных станций ищут не тестировщики без инженерного бэкграунда :))

😂

Когда вы пишете "дорогие специалисты" - имеете в виду более опытные или если чувак получает больше бабла, ему не положено баги фиксить?

тут скорее имеется ввиду более опытные, и если они тратят свое время на банально понажимать по кнопкам и посмотреть все ли работает корректно во всех кейсах то это добавляет меньше value чем если бы они пилили код например

тестировщик которые не умеет ux, программирование или какую-то другую часть, которую в продукте может сам реализовать - оторван от продукта

Я думаю в этом причина недопонимания. Если в ваших продуктах главное UX, то да, вполне возможно баги там не критичны.

:D

БЛЯТЬ ВО ВСЕХ ПРОДУКТАХ UX ЭТО ГЛАВНОЕ

у меня все

потому что это переводится как USER EXPERIENCE.

Я думаю в этом причина недопонимания. Если в ваших продуктах главное UX, то да, вполне возможно баги там не критичны.

я думаю тут путаница с UI

Не во всех. Иногда это вообще не главное, и на пользователей этого ПО всем забить.

Пользователи вообще часто не главное в ПО

Пример - любая банковская программа. Главное, чтобы транзакции быстро, правильно и надежно проходили. А удобство операционисток - дело десятое.

Я же говорю, проблема в том, что все занимаются продуктами разного плана.

Пример - любая банковская программа. Главное, чтобы транзакции быстро, правильно и надежно проходили. А удобство операционисток - дело десятое.

на плохом продукте операционистка проведет вам грубо 100 транзакций за день, на хорошем 200

Пример - любая банковская программа. Главное, чтобы транзакции быстро, правильно и надежно проходили. А удобство операционисток - дело десятое.

это сказывается на их удовлетворенности как минимум.

на плохом продукте операционистка проведет вам грубо 100 транзакций за день, на хорошем 200

define “плохой”

на плохом продукте операционистка проведет вам грубо 100 транзакций за день, на хорошем 200

Если их этих 200, 150 будут фейлиться - пусть уж лучше 100 делает

Я же говорю, дело в приоритетах