Сообщений в теме: 24

[IvanSIvan]

Добрый день!
Дано:
Небольшая команда из  25 веб. разработчиков, работа удаленная.
Самописная Система управления проектами (по методологии Scrum), баг трекер так же самописный.

Задача: Уменьшить задержку между статусами Выполнено и Проверено у таска.
Сейчас это в среднем 15 часов.
Какие у кого будут идеи?
Заранее Спасибо.


 

[Freiman]

Заставить тестировщиков работать ночью.

[IvanSIvan]

Заставить тестировщиков работать ночью.

Проблема действительно есть. Тестировщики могут, приступить к тестированию задачи на следующий день (при загрузке и через день), после выполнения таска, при выявлении ошибки/ошибок в таске, процесс разработки затягивается.
В итоге как улучшить мотивацию тестировщиков на результат?
 

[leftCh]

Предположим ваша программа работает с "тяжелыми" операциями по обновлению данных, помещая их в очередь, оттуда другой процесс/поток их берет и обрабатывает. На пиковых нагрузках ответ по тяжелой операции может прийти спустя, ну пусть, 5 минут. Как мотивировать сервер на результат, чтобы отклик не привышал 30 секунд при любых нагрузках?

 

Ах ну да, пользователей очереди не много, примерно 25

[Little_CJIOH]

Заставить тестировщиков работать ночью.

Проблема действительно есть. Тестировщики могут, приступить к тестированию задачи на следующий день (при загрузке и через день), после выполнения таска, при выявлении ошибки/ошибок в таске, процесс разработки затягивается.
В итоге как улучшить мотивацию тестировщиков на результат?

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

[SALar]

 

Проблема действительно есть. Тестировщики могут, приступить к тестированию задачи на следующий день (при загрузке и через день), после выполнения таска, при выявлении ошибки/ошибок в таске, процесс разработки затягивается.

В итоге как улучшить мотивацию тестировщиков на результат?

 

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

 

1) Согласен с Павлом. У тестировщиков должен быть 25% запас по мощности. Иными словами тестировщики 20-25% времени должны бездельничать.

2) Вложитесь в процесс передачи кода на тестовые стенды. Я видел фирму, где на разворачивание тестового стенда тратилась пара недель. Чтобы потом 15 мин потестить фичу.

 

И лучший способ демотивировать сотрудника - попытаться его мотивировать. 

[SALar]

Заставить тестировщиков работать ночью.

В "Стальной Крысе" приковывали к парте. Для мотивации сдачи экзамена. 

[Freiman]

 

Заставить тестировщиков работать ночью.

Проблема действительно есть. Тестировщики могут, приступить к тестированию задачи на следующий день (при загрузке и через день), после выполнения таска, при выявлении ошибки/ошибок в таске, процесс разработки затягивается.
В итоге как улучшить мотивацию тестировщиков на результат?

Как уже сказали, если уж вы хотите, чтобы задача мгновенно переходила в тестирование, то вам нужны "бездельничающие" тестировщики. Тогда они смогут взять задачу сразу же, в противном случае задача будет ставиться в очередь, т.к. все заняты текущими задачами.

 

Ну и про "ночью": если разработка завершена в 17:30, то, пожалуй, наивно думать, что задача будет протестирована в тот же день. 

[Freiman]

 

Заставить тестировщиков работать ночью.

В "Стальной Крысе" приковывали к парте. Для мотивации сдачи экзамена. 

Надо перечитать :) Что-то уже не помню этот момент.

[Vasiliy]

Да, кстати! Какая это часть, я тоже такого не помню)

[SALar]

 

 

Заставить тестировщиков работать ночью.

В "Стальной Крысе" приковывали к парте. Для мотивации сдачи экзамена. 

Надо перечитать :) Что-то уже не помню этот момент.

 

Это их дети рассказывали. По хронологии похоже на "Стальная Крыса спасает мир". Звиняйте хлопцы, читал с четверть века назад, а память у меня уже не та, что раньше была.

[Vasiliy]

Ну я Стальную Крысу тоже не вчера читал))

[IvanSIvan]

Всем спасибо, за ответы.
Момент: В ответах не учли что работа удаленная, и все держится только на доверии.
Тестировщик работает вечером, а программист днем "затык".
Тестировщики не верно растравляют приоритеты & рассчитывают время, не успевают сделать работу и "затык". и
тд.

 

[Vasiliy]

То есть виноваты только тестировщики?

[Little_CJIOH]

Всем спасибо, за ответы.
Момент: В ответах не учли что работа удаленная, и все держится только на доверии.
Тестировщик работает вечером, а программист днем "затык".
Тестировщики не верно растравляют приоритеты & рассчитывают время, не успевают сделать работу и "затык". и
тд.

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

[Vasiliy]

Ошибочное сообщение)

Сообщение отредактировал Vasiliy: 18 августа 2017 - 19:25

[leftCh]

С "бездельничающими" тестировщиками есть нежелательный побочный эффект. Если задач мало и тестировщик понимает, что успеет выполнить  все и еще время останется, он, видимо из-за своих человеческих слабостей , начинает работать медленнее. Мало-помалу он привыкает к новому расслабленному ритму и нормальная нагрузка начинает восприниматься как "перегруз" :) Так что, наверное, стоит воспринимать задержку при ручном тестировании как неизбежное зло. Выход - делать автотесты.

[Freiman]

Выход - делать автотесты.

После разработки фичи?

[leftCh]

TDD, автор, слабо?

Ожидания у автора неадекватные Ручное тестирование  - это не этап компиляции Проект они задерживают... А может проект задерживает низкое качество кода, который приходится пинать туда-сюда между тестировщиком и программистом?

[QuadBit]

Добрый день!
Дано:
Небольшая команда из  25 веб. разработчиков, работа удаленная.
Самописная Система управления проектами (по методологии Scrum), баг трекер так же самописный.

Задача: Уменьшить задержку между статусами Выполнено и Проверено у таска.
Сейчас это в среднем 15 часов.
Какие у кого будут идеи?
Заранее Спасибо.


 

Слишком мало информации. Если у вас есть тасктрекер - смотрите где именно происходит задержка процесса, с чего вы решили, что время в 15 часов это много? Почему не 40? Почему не 2? Пока это выглядит как попытки менеджера пинать ленивую скотинку, по его мнению ленивую, ведь всегда можно работать быстрее. Сообщение выглядит как "доктор, у меня что-то болит, но трогать меня не смейте и анализы я сдавать не пойду, лечите!".