Архив рубрики: оценка

Planing Poker

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

К решению были предъявлены следующие требования:
1. Простота
2. До окончания оценки никто не видит оценок остальных участников.
3. Считать среднюю оценку.
Пункт два возник из-за того, что как только первый ставит оценку (мы до этого использовали для совместной оценки Skype), все остальные начинают под нее подстраиваться, особенно если этот первый программист с большим опытом.
Ну а пункт три это к вопросу о том, что в долгое время работающих в одном составе командах, оценки особо не нужны (подробнее писал ранее здесь).
Итак, что собой представляет приложение.
Для простоты оно состоит из вебсервиса (без базы данных и с отсутствующей персистентностью), который отвечает за взаимодействие клиентов и клиентского приложения, которое запускают у себя участвующие в оценке.
Вот так выглядит главное окно (картинки кликабельны):
При входе необходимо указать имя и с какой ролью входит участник. А дальше для ведущего есть возможность указывать номер оцениваемого требования и завершать оценку, для всех есть возможность перейти по ссылке (номер оцениваемого требования) в систему управления задачами и вторая доступная возможность поставить оценку. Ведущий и все участники оценки имеют возможность видеть кто уже оценил (минус - оценки еще нет, плюс - оценку участник уже поставил). Как только все оценили (оценку если что можно и менять в процессе обсуждения), ведущий нажимает кнопку показать результаты оценки:
Показывается кто как оценил и среднее. Если оценки очень сильно разняться, можно еще раз обсудить, но в  большинстве случаев можно сразу брать среднее и ставить его в требование.
Вот такое простенькое приложение нам немного облегчает жизнь каждые две недели.

Оценка требований по Кано

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



При первом приближении взятие в работу должно идти в следующем порядке: правая-верхняя четверть, левая верхняя четверть, правая нижняя. На левую нижнюю никогда не хватает времени. Про оценку сложности можно говорить очень много, и об этом в другой раз. Сегодня предлагаю обсудить оценку полезности, предложенную Нориаки Канов начале 80-х годов прошлого века. В рамках этой модели все требования (функции будущего продукта) разбиваются на 5 групп:
1.       Привлекательные характеристики. При наличии этих параметров пользователи будут испытывать удовлетворение. Однако, если этих функций в продукте не будет, к негативным эффектам это не приведет. Именно об этих характеристиках продукта будет рассказывать «сарафанное радио».
2.       Одномерные характеристики.  Эти характеристики вызывают удовлетворенность, если они есть, и неудовлетворенность, если их нет. К таким параметрам может относиться скорость работы приложения. При низкой скорости откликов – негатив, при высокой – удовлетворение.
3.       Обязательные характеристики. Их наличие считается обязательным, поэтому отсутствие вызывает негатив. К примеру, если ваш текстовый редактор не позволяет набирать текст, то вы его не продадите.
4.       Неважные характеристики. Пользователь к ним нейтрален. Например, для большинства пользователей того-же текстового редактора функция подсчета символов в тексте – нейтральная.
5.       Нежелательные характеристики. Это все то, что будет вызывать у пользователя раздражение. Как правило, эти характеристики возникают потому, что так было проще разрабатывать.
Для того, чтобы отнести требование к одной из этих групп, необходимо провести анкетирование пользователей. По каждому требованию задаются два вопроса:
1.       Насколько вам понравится наличие … в продукте?
2.       Как вы отнесетесь к отсутствию … в продукте?
На каждый вопрос  пользователь может выбрать один из пяти вариантов ответа:
1.       Мне это нравится
2.       Я ожидаю именно этого
3.       Мне все равно
4.       Я могу это терпеть
5.       Мне это не нравится
Для обработки полученных в опросе результатов применяется оценочная таблица следующего вида:

В нее заносится, сколько человек ответило именно так на положительный и отрицательный вопрос о требовании. Допустим, если вы анализируете требование «наличие двухфакторной авторизации», и  на положительный вопрос (наличие двухфакторной авторизации) пользователь ответил «Ожидаю», а на отрицательный (отсутствие двухфакторной авторизации) – «Могу терпеть», то его голос будет добавлен вот в эту ячейку:

В результате получим некоторые значения в зонах нашей таблицы. Если основная масса ответов о требовании пришлась на зону «Привлекательно», то, значит, эта функция может стать фишкой приложения. Когда основная масса находится в зоне «Обязательно», выбора нет, этот функционал должен быть реализован. Если лидирует зона «Нежелательно», будьте уверены, этот  функционал пользователи не оценят. Зона «Не важно» оставляет простор для выбора. И самая интересная зона - «Непонятно». Если в этой зоне много голосов, от опрашиваемые не поняли функцию, поскольку не может одновременно нравится и наличие этой функции, и ее отсутствие.
Пользуясь моделью Кано, необходимо понимать, что она не всегда применима. Например, она не может решить проблему, изложенную в теореме Эрроу. Да и Генри Форд говорил: «Если бы я слушал своих клиентов, мне бы пришлось дать им более быструю лошадь». Но если вас это не останавливает, то предложенная методика позволяет неплохо  ранжировать ценность требований в списке.
Для тех, кто захочет попробовать методику, но не готов в ручном режиме обрабатывать результаты, есть бесплатный сайт: http://www.kanosurvey.com/