Soft

war

eCl

oud

Serv

ices

Стимул на качествоМетодики мотивации программистов и тестировщиков

Алексей БарганРуководитель отдела разработки ПО департаментаDeskWork и программных разработок

Чепурдеев АндрейРуководитель группы тестирования отдела разработки ПО департаментаDeskWork и программных разработок

Содержание

Что сейчас не так

Пути выхода Решение

Почему провалы это плохо?

Потерянное время тестировщика (проверять несколько раз один и тот же функционал)

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

Тестировщики не успевают за программистами (их ресурсов постоянно не хватает)

Низкое качество кода (зачем париться и отвечать за свой код если тестировщики все равно проверят)

Стремительная потеря доли рынка среди коробочных портальных решений

Почему провалы это плохо?

Какие еще проблемы? (Андрей)Приоритеты и степень важности задач - Необоснованное выставление и изменение приоритета и важности. Важные задачи теряются в большом кол-ве задач.Вариант решения: Четкий регламент по важности и приоритетам.

Верификация задач- Некоторые задачи нет возможности проверить достаточно компетентно или вообще невозможно по различным причинам. Такие задачи довольно быстро закрываются без должного внимания. Вариант решения: Назначение разных ответственных (проверяющих), кроме тестировщиков.

-Иногда непонятно что было сделано в той или иной задаче или пока каким то причинам сделано не так как просили (ничего плохого). Вариант решения: Комментирование выполненной задачи или написание краткого документа с освещением важных моментов (особенность работы и т.д)

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

Вывод по тому какие сейчас есть проблемы (Андрей)

Победитель: Его нет

Проигравший: Проект

Результат: выполненная задача (дефект/улучшение/новый функционал)

Победителем должен быть проект

Как же быть?Стоит ли сравнивать команды или отдельных программистов/тестировщиков для последующей выдачи премии или наказаний?

Главная задача не наказать и/или наградить, а понять существующую эффективность и состояние дел и попытаться исправить положение.

Решение проблемы

Никаких наказаний или упреков

Только поощрения в виде дополнительных денежных стимулов

Хуже не станет в любом случае

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

Виды поощренийБаллы = Живые Деньги

Поощрения программистам- Выполнена 8 часовая задача, при закрытии без провалов - 1 балл (мелкий провал на большой задаче не учитывается)- Разработал полезный класс/метод/библиотеку и рассказал про него доклад - 1 - 5 баллов- Помог коллеге с решением его проблемы 1 - 2 балла- Помог Косте с техподдержкой - 0.5 балла- Оставлять комментарий о номере ревизии (начиная с которой доступно исправление) в задаче перед изменением статуса с “В работе” или “Открыта” на “Выполнена”, если ранее она не была связана с каким-либо commit’ом. (+/- 0,5)- Исправление ошибок со сборкой новой версии в CCNet, если ошибку вызывает твой код. Нельзя оставлять ошибку на след. день. (-3)- Оставлять комментарий (с причиной) в задаче при изменении статуса с “Открыта” на “Запрос на отмену”. (+/- 0,5)- Не рекомендуется делать commit’ы в задачу которая находится в статусе “Выполнено”. Все необходимые изменения необходимо вносить в момент, когда выбран статус “В работе”. (-0,5 за commit)- Оставлять комментарий (с причиной) в задаче при изменении статуса с “Открыта” на “Закрыта”. (+/- 0,5)

Поощрения программистам- Статус задачи “Провалено”. Причины по-возможности будут рассматривается в каждом конкретном случае (некорректная постановка задачи, не внимательное изучение проблемы, не проверенное исправление или функционал и т.д ). (-0,5...-1 за каждый провал)- Добавление или редактирование (корректирование) статей в базе знаний по продукту (deskwork.ru).(+1)- Доклад на тему (новая технология, новая методика, улучшение существующих механизмов и т.д).(+2)- Доклад на тему внедрения методики, технологии в существующие процессы (Результаты за период, +/-, что мешает...).(+5)-(обсуждаемо, возможно только для тех кто и так работает из рук вон плохо) Учет времени присутствия на рабочем месте. (-0,5 ….-2)

Простые заповеди программистам (как можно начать работать на качество)

Проверка функционала перед изменением статуса задачи в “Выполнено”:

1. Корректная работа для пользователей с различными привилегиями на портале. Анонимные пользователи.2. Работа на дочерних и персональных узлах (возможность использования и т.д)3. Resources4. Проверка ссылок\переходов на “внешние” страницы (корневые\дочерние узлы\персональный сайт). При использовании альтернативного адреса для входа (настройка альтернативного доступа).5. Активация\Переактивация фичи.6. Проверка в различных браузерах (Приоритет в IE )

Простые заповеди тестировщикам (как можно начать работать на качество)

Правила работы (создание, шаблоны и т.д.) с задачами в Redmine

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

Основные моменты которые должны присутствовать в описании:1. В чем заключается проблема/улучшение2. Почему это проблема/ зачем необходимо улучшать3. Как воспроизвести проблему4. Ожидаемый результат после внесения изменений

Итоги

Как нужно разрабатывать чтобы получать премию:

Быстро закрывать задачи Без большого количество провалов Закрывать большие задачи (за них больше

очков) Помогать друг другу Думать об улучшении продукта

Вопросы?