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

[hakimus]

копирну свое письмо друзьям разработчикам:

А вот эта мысль мне в голову не приходила, спасибо!
Полезу посмотреть, что у нас в JIRA для этого можно использовать.

[SALar]

Перед тем, как тюнить джиру, напишите:

I. Проблема.
а) какую проблему вы хотите решить?
б) как ее можно решить другим способом?

II. Внедрение и использование.
а) Будет ли использоваться этот инструмент вашими сотрудниками?
б) каким именно образом?
в) какова точность информации?
г) кто и как будет использовать информацию?


-- ответы могут быть и такими:
I. Проблема.
а) какую проблему вы хотите решить? - понятия не имею.
б) как ее можно решить другим способом? - конечно, но мы будем решать ее самым неэффективным способом.

II. Внедрение и использование.
а) Будет ли использоваться этот инструмент вашими сотрудниками? - маловероятно
б) каким именно образом? - примерно таким же, каким мартышка использовала очки в басне Крылова.
в) какова точность информации? - как средняя температура по больнице.
г) кто и как будет использовать информацию? - с самого начала никто и не собирался этим пользоваться.

Profit!!!

[hakimus]

Перед тем, как тюнить джиру, напишите:

I. Проблема.
а) какую проблему вы хотите решить?
б) как ее можно решить другим способом?

II. Внедрение и использование.
а) Будет ли использоваться этот инструмент вашими сотрудниками?
б) каким именно образом?
в) какова точность информации?
г) кто и как будет использовать информацию?

Да, это здравые вопросы.

I. Проблема.
а) какую проблему вы хотите решить? - необходим живой инструмент расстановки оценок. Не пост-фактум, а сразу в процессе работы. Есть артефакт, есть работа, работа выполнена и оценена.
б) как ее можно решить другим способом? - выписывать номера артефактов в блокнотик с фамилиями, и вести реестр там. То есть, использовать неудобный инструмент.

II. Внедрение и использование.
а) Будет ли использоваться этот инструмент вашими сотрудниками? - подразумевается, что инструмент на первом этапе - для тимлида (поэтому оценка другими со стороны пока вторична). Тимлид будет: ему невозможно оценить качество выполнения мелких, но важных тактических работ пост-фактум через месяц, два, полгода.
б) каким именно образом? - пример: тимлид назначает на проверку исправления баг. Баг срочный и важный. Тестировщик справился с задачей. В баге отражена оценка этого "достижения". С помощью штатного инструментария (который и ищется) тимлид по истечении любого нужного ему времени собирает ранее зафиксированную информацию по всем таким "достижениям" в разрезе каждого тестировщика и оперирует ей сообразно своим целям разносторонних оценок.
в) какова точность информации? - высокая
г) кто и как будет использовать информацию? - частично ответ в II(б). Основная цель использования: дополнительный (не основной) критерий оценки деятельности тестировщика за период (термометр действительных поступков, а не аморфное и малопонятное "за период N достиг высоких показателей эффективности деятельности бла-бла-бла").

Как-то вкратце так.

[SALar]

I. Проблема.
а) какую проблему вы хотите решить? - необходим живой инструмент расстановки оценок. Не пост-фактум, а сразу в процессе работы. Есть артефакт, есть работа, работа выполнена и оценена.

Все. Больше ничего не надо. Когда в качестве цели пишется средство - проект нужно немедленно закрыть.
Один из методов верификации требований. О чем говорилось в моем докладе на SQADays.


Ищите цель. настоящую цель. Пока не найдете дальше двигаться не стоит.

[Sezam]

I. Проблема.
а) какую проблему вы хотите решить? - необходим живой инструмент расстановки оценок. Не пост-фактум, а сразу в процессе работы. Есть артефакт, есть работа, работа выполнена и оценена.

Все. Больше ничего не надо. Когда в качестве цели пишется средство - проект нужно немедленно закрыть.
Один из методов верификации требований. О чем говорилось в моем докладе на SQADays.


Ищите цель. настоящую цель. Пока не найдете дальше двигаться не стоит.

Сергей, а чем средство - плохо в качестве цели?
В качестве проблемы, я ещё могу понять так: Средство не может быть проблемой, оно для решения проблемы.

Говоря "цель проекта" - мы определяем что будет сделано, или для чего это делается?

Сообщение отредактировал Sezam: 14 декабря 2011 - 10:52

[hakimus]

Коллеги, это жонглирование словами. На мой взгляд проблема ясна из контекста. Причем, была ясна сразу. Нет инструмента - нужен инструмент.

[barancev]

Коллеги, это жонглирование словами. На мой взгляд проблема ясна из контекста. Причем, была ясна сразу. Нет инструмента - нужен инструмент.

Собственно, Сергей и задал вопрос -- зачем нужен инструмент? Это неясно из контекста.

[hakimus]

Собственно, Сергей и задал вопрос -- зачем нужен инструмент? Это неясно из контекста.

Инструмент нужен для оценки качества выполнения (хорошо/плохо) определенных ежедневных мелких (но важных) задач тестировщиком.

[barancev]

Инструмент нужен для оценки качества выполнения (хорошо/плохо) определенных ежедневных мелких (но важных) задач тестировщиком.

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

[hakimus]

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

Зачем - понимать количественно участие каждого тестировщика в решении описанных мелких задач за период. Решения на основе - корректировка распределения ресурсов (если нарисуется картина, грубо, "кто-то везде и с головой, а кто-то как бы и не участвует вовсе"), вклад каждого в этот фронт проектных работ.
Насколько точный хочется - это не основная оценка тестировщика, а дополнительная, поэтому инструмент может считать с погрешностями. Пусть пока хотя бы примерную картину сформирует.
Почему нельзя оценивать грубо - сейчас так и оценивается. Слишком много мелких задач и слишком много тестировщиков. При оценке грубо за период:
- выпадают детали
- сложно вспомнить все, что выполнено
- неоправданно трудоемко и слишком приблизительно

Как-то так.

[Vasiliy]

Это не жонглирование, это решение проблемы на разных уровнях и в разных ипостасях, имхо.

Вы уверены, что получив отклики от разработчиков вы сумеет сформировать адекватную оценку?

И, кстати. Тестировщики не оценивают баги, дабы разработчики тоже имели свою оценку?)

[SALar]

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

Зачем - понимать количественно участие каждого тестировщика в решении описанных мелких задач за период. Решения на основе - корректировка распределения ресурсов (если нарисуется картина, грубо, "кто-то везде и с головой, а кто-то как бы и не участвует вовсе"), вклад каждого в этот фронт проектных работ.
...

Для распределения ресурсов эта оценка точно не нужна.

Вероятнее всего проблемой является плохое описание багов тестировщиками.
Вместо того, чтобы тюнить трекер просто начните решать эту проблему. Это несложно. месяцев за шесть ситуацию вполне можно выправить.

[jjjzmey]

Мне необходимо составить критерии для оценки работы тестировщиков.

Все заинтересованные ставят в таблицу своё субъективное число от 1 до 10, из него выводится среднее, по среднему принимается решение о премировании\депремировании.
Следующим ходом идёт предложение распространить данную методику на оценку всех процессов, а не только одного тестирования.

[AlexeyBocharov]

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

Оценка может быть собрана лично. как и критерии в зависимости от проекта, команды и проч.
из разных параметров от качественного выполнения тестов, до качественности кода написанного программистом, например количество реопенов тоже критерий, но чем вызван реопен, некачественностью кода, или неправильным формулированием бага.
и так с каждым критерием.
Статичного инструмента не будет. Имхо. Каждый критерий требует причинно следственного анализа. опять же на статистике. и субьективных оценках.