Softwa re Cloud Servic es Стимул на качество Методики мотивации программистов и тестировщиков Алексей Барган Руководитель отдела разработки ПО департамента DeskWork и программных разработок Чепурдеев Андрей Руководитель группы тестирования отдела разработки ПО департамента DeskWork и программных разработок
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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. Ожидаемый результат после внесения изменений