а если не мерить, то пофиг что юзать

Не знаю к чему отнести наш тип работы, ресерч есть, но есть и много рутинных тикетов.

прекрасно метрики меряются , вид представления никае не влияет ни на что

берндаун чарты, ганта диаграммы и прочее

прекрасно метрики меряются , вид представления никае не влияет ни на что

они меряются, дело не в представлении

а в том что у тебя условно в одной итерации есть пул задач рутинных и вы сделали 300 тикетов

канбан - это представление. только и всего

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

визуализация того же самого процесса

мы работали по аджайлу - у нас не было итераций :)

я к тому, что для визуализации процесса разработки есть вещи получше канбана

у нас был постоянный подфид канбана задачами

мы работали по аджайлу - у нас не было итераций :)

эджайл вообще не это

он про ценности, он никак не регламентирует наличие или отсутствие итераций

есть процессы получше чего-то под чем людей ограничивают по итерациям :)

вотева

не, не вотева

не надо путать фреймворки с эджайл манифестом

:)

ты кому хочешь что доказать, Никит? :)

себе что пора пойти домой

вот реально, вовзращаясь к дефолтной теме

я удивился, что QA работают по канбану) я не говорю, что это плохо, просто есть более оптимальные практики которые признаны сообществом

я ж не топлю что вы все плохо делаете

если подходит и работает, значит хорошо)

Иногда у нас qa лезут прям на живой релиз тестировать, приходится им кричать "астанавитесь"

Там все разломано и они на каждый чих создают тикеты лавинообразно

какие они у вас забавные

:3

Если руководство устраивает - значит они не видят в этом проблем\рисков\убытков.

Если руководство устраивает - это не значит ровным счётом ничего. Люди действуют иррационально. Об этом даже Дорофеев говорит.

Если руководство устраивает - это не значит ровным счётом ничего. Люди действуют иррационально. Об этом даже Дорофеев говорит.

Если руководство устраивает и они не внемлят аргументации - значит компании это не нужно. The end.

Это не про категории "правильно"\"не правильно".

> The end. То есть вот так просто взять сдаться или уволиться?

Начать обычную серую офисную жизнь?

Стать таким же безликим тестером как все??

опечаточка?

Псевдоним?

Это? Это ващи жизненные ценности??? ?

Нет, можно в девопсы уйти и заниматься пиком бесполезной работы.

Девопсы же полезные

Нет, можно в девопсы уйти и заниматься пиком бесполезной работы.

ээээээээээээээээээээ

Все полезные работы ) ну или почти )

проходим мимо, не агримся

захожу сюда раз в месяц чтобы прочитать какое-то очень странное утверждение

проходим мимо, не агримся

Евгений,здпавствуйте )

захожу сюда раз в месяц чтобы прочитать какое-то очень странное утверждение

заведи топ по людям, которые странные утверждения публикуют :)

за 12 месяцев наберется топчик

"12 месяцев очень странных утверждений, или новые приключения Шу-рика"

это пять!

"12 месяцев очень странных утверждений, или новые приключения Шу-рика"

Паша, давай вот без этих фамильярностей.

ээээээээээээээээээээ

Не обращайте внимания, девопс это вообще процессы, а не должность.

ой такая вечная дискуссия

о_о

если уж называют людей девопсами, пусть уже будет должность

Людей и не такими словами называют, что уж.

девопс - это самый дружелюбный айтишник в отделе.

девопс - это самый дружелюбный айтишник в отделе.

двачую

девопс - это самый дружелюбный айтишник в отделе.

девопс - не человек

А fullstack это не тот кто умеет фронтенд и бэкенд, я знаю :)

девопс - это самый дружелюбный айтишник в отделе.

повезло вам=)

Всем, утра доброго. Вопрос есть. Как доказать начальнику отдела бизнес анализа, разработки, что чем лучше описано ТЗ, а точнее чем детальнее описано ТЗ тем лучше будет разработано, протестировано и меньше будет вопросов к аналитику?

Ну да, чем зеленее трава и выше деревья тем красочней детство)

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

А ещё круче когда разработчик реализует через 5 точку, а потом приходится обивать пороги аналитиков, начальников и говорить, что это какашка и тратить на разбор полетов больше времени, чем бы это потребовалось для описания детальной спецификации

ERROR: S client not available

Всем, утра доброго. Вопрос есть. Как доказать начальнику отдела бизнес анализа, разработки, что чем лучше описано ТЗ, а точнее чем детальнее описано ТЗ тем лучше будет разработано, протестировано и меньше будет вопросов к аналитику?

попробуй конкретизировать и перевести в цифры. вместо эмоциональных аналоговых "быстрее, выше, сильнее" пиши прям в конкретных цифрах и примерах. Если ты можешь что-то измерить - ты можешь этим управлять. Касательно требований: если тебе прям принципиален весь этот вопрос, то берешь кусок ТЗ и декомпозируешь его на запчасти. Разбираешь на короткие утверждения, потом показываешь, какие варианты работы твоего продукта в этом конкретном месте остались не описаны. Это займет время, но когда ты дашь своему менеджеру такой разбор ТЗ, где на 1 задокументированное утверждение приходится 7 незадокументированных и именно в этих семи возможны такие и вот такие разночтения и потому аналитик, разработчик и тестировщик расценивают по-разному, то менеджер увидит конретную проблему, которую можно решить. а все эти эмоции про более зеленую траву воспринимаются только как нытье на пустом месте.

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

а зачем тестировщику что-то делать ? можно бегать и стучать себя "пяткой в грудь" и тратить время, силы и нервы. Можно все залогировать: оставить комменты в задаче и прочее, что тестировщик выполнил работу - и отдать "как есть": Заказчик раз получит не то что хочет, два получит не то что хочет - и сам намекнет руководству группы разработки, что что-то тут не так.

Тестирование требований проводите и изначально вопросы возникнут на более ранней стадии к полноте документации. Как вариант обоснования - это экономит средства на разработке, Т.к. Меньше вопросов у разработчика к аналитику, а потом у тестировщика к разработчику. Помогает отловить баги ещё на стадии документации

Тестирование требований проводите и изначально вопросы возникнут на более ранней стадии к полноте документации. Как вариант обоснования - это экономит средства на разработке, Т.к. Меньше вопросов у разработчика к аналитику, а потом у тестировщика к разработчику. Помогает отловить баги ещё на стадии документации

???

Ок, спасибо. Уже набралось заданий таких с оценкой, вчера тыкнул лида своего и аналитика в задачи в которых максимум можно было потратить часа 4 на разработку/тестирования, а на выходе вышло 2 дня. Посмотрим как дальше пойдет

Если очень сложное начальство, поищите в интернете про тестирование требований, составьте статистику сколько багов/времени/душевных сил команды было затрачено из-за недопониманий по документации и топайте к начальству со статистикой и красивой речью о том как вы все это вылечите дай вам только флаг в руки на тестирование требований и раздачу ц.у. Аналитикам

Ок, спасибо. Уже набралось заданий таких с оценкой, вчера тыкнул лида своего и аналитика в задачи в которых максимум можно было потратить часа 4 на разработку/тестирования, а на выходе вышло 2 дня. Посмотрим как дальше пойдет

?

Всем, утра доброго. Вопрос есть. Как доказать начальнику отдела бизнес анализа, разработки, что чем лучше описано ТЗ, а точнее чем детальнее описано ТЗ тем лучше будет разработано, протестировано и меньше будет вопросов к аналитику?

Странно,что это вообще нужно доказывать

Хай всем )

А у нас сделали проще. Просто нет ТЗ и прогер иногда пишет как тестить то, что он написал.))

Странно,что это вообще нужно доказывать

Это конечно да, что странно. Я тоже удивляюсь. Просто у нас аналитики не IT, а те кто работал на прямую с продуктом. Есть один аналитик который из IT и его спеки крутые.

у нас обычно пишут, на что стоит обратить особое внимание, т.к. это с точки зрения разработчика могло сломаться

А у нас сделали проще. Просто нет ТЗ и прогер иногда пишет как тестить то, что он написал.))

А вот это же маразм.

Прикинь пишет заказчик что он хочет, может программист его не поймет и реализует по своему. Напишет, что надо тестировать тестироввщику, потом отдается продукт, а заказчик имелл ввиду совсем другое

И начинаем все сначала

А вот это же маразм.

Нет ничего плохого в том, что реализовав фичу, разработчик укажет самые слабые части на которые нужно обращать внимание. У нас это было частой практикой

Нет ничего плохого в том, что реализовав фичу, разработчик укажет самые слабые части на которые нужно обращать внимание. У нас это было частой практикой

Ну если фича мелкая то с этим я согласен. А если там перепи целого модуля, который на сем повязан

Вот тогда все какашки на верх и всплывают

Часто разработчик может к таске даже свой собственный чеклист приложить. Нет никакой разницы, кто это сделает первым, при условии, что все равно каждое слово критически осмысливается

Ну если фича мелкая то с этим я согласен. А если там перепи целого модуля, который на сем повязан

Не вижу в такой постановке проблемы вину чеклиста от разработчика. Это проблема в целом декомпозиции таска тогда, а не чеклиста

А у нас таски очень просто пишутся. аналитик пишет поверхностное ТЗ, а потом лиды в таске пишут: Необходимо реализовать п.1 ТЗ и ссылка на ТЗ.

А я смотрю нас все больше и больше

13

13

?

А вот это же маразм.

Это одна из причин почему у меня сегодня последний день в компании)

Это одна из причин почему у меня сегодня последний день в компании)

Ник в тему

Гг)

А у нас сделали проще. Просто нет ТЗ и прогер иногда пишет как тестить то, что он написал.))

Успех

Три года живу без ТЗ, никакого маразма.