что не относится к критериям оценки задач

Практики планирования. Оценка задач

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

Эффективное планирование зависит от множества разных факторов: от качества оценки, проработки деталей решения, использованной методики планирования, правильной оценки рисков.

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

Итак, начнем с правил оценки.

Оцениваем задачи по единым правилам

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

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

Декомпозируем задачу

Зачастую разработчику гораздо проще сказать: «да там на пару недель работы». А менеджеру добавить в план задачу на 80 часов. Однако из-за такого подхода к планированию потом и возникают вопросы вида: «скажи, сколько процентов работы тебе осталось сделать» и другие способы понять, какой у разработчика прогресс по выполнению задаче.

Мы установили следующие ограничения: любая задача декомпозируется на подзадачи длительностью 0,5-3 дней. Каждая подзадача представляет собой законченную часть функционала.

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

Но по нашему опыту подзадачи более 3 дней:

Менее 0,5 дня тоже имеют недостатки:

При этом мы сразу нумеруем пункты декомпозиции (подзадачи) – так гораздо удобнее работать с ними в сетевой диаграмме (об этом ниже) и в плане.

Унифицируем подход к декомпозиции

Однажды мы столкнулись с такой ситуацией: оценка трудоемкости разработки другой команды оказалась на 25% меньше, чем наша. Эта ситуация очень заинтересовала руководство – расследование показало, что наши коллеги не включили в оценку проверку разработчиками результатов своей разработки (внутреннее дымовое тестирование).

Чтобы таких ситуаций не было, мы добавили в правила оценки еще пару пунктов:

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

Оцениваем зависимости задач

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

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

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

Учитываем ограничения

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

Оцениваем риски

Есть анекдот про менеджеров, которые умножают оценки разработчиков на некоторое эмпирическое число. Максим Дорофеев объясняет, почему не надо так делать.

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

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

На практике

На практике в нашей команде при выполнении оценки разработчик заполняет вот такую простую таблицу:

А также рисует сетевую диаграмму примерно такого вида:

Заключение

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

Источник

Критерии оценки решения задач

Выполнение практических заданий, в зависимости от сформулированной задачи, дает возможность оценить знания, умения и навыки по измеряемой компетенции.

Результаты текущего контроля отражаются в индивидуальном балльно-рейтинговом листе. Рейтинг подсчитывается дважды в семестр. В сумме за два блока студент может набрать максимально 60 баллов (первый блок – 25 баллов, второй – 35 баллов).

Промежуточная аттестация проводится в форме экзамена. Билет состоит из двух вопросов.Экзамен проводится в письменной форме, время подготовки 40 минут.

При оценивании работы студента используется балльно-рейтинговая система.

Всего за семестр студент может заработать по дисциплине до 100 баллов включительно:

— за работу в семестре – до 60 баллов включительно, в том числе, за выполнение работы в первом блоке студент может заработать до 25 баллов включительно, за работу во втором – до 35 баллов включительно;

— за сдачу экзамена студенту может быть начислено от 0 до 40 баллов включительно.

В рейтинг работы в течение семестра включаются оценки следующих видов работ студентов:

1) работана семинарских или практических занятиях;

2) посещение и работа на лекциях;

3) контрользнаний в течение семестра;

4) самостоятельная внеаудиторная работа.

За ответ при сдаче экзамена студенту начисляются баллы в соответствии с приведенной ниже шкалой.

Шкала начисления баллов за ответ на экзамене

Если студент при сдаче экзамена получил оценку «неудовлетворительно», то ему выставляется итоговая оценка «неудовлетворительно», независимо от количества баллов, заработанных студентом в течение семестра.

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

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

Шкала перевода баллов в итоговую оценку

Источник

Как научиться оценивать задачи, если не умеешь: 4 фактора сложности

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

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

В одной из команд, где я работал, мы придумали оригинальный метод для предварительной оценки задач. Метод синтезирует некоторые известные из литературы приёмы, но в приведённой форме, пожалуй, никем не описан. Концепция была следующей: объективность (связь с измеримыми показателями); интегрируемость с Agile; повторяемость; быстрота оценки (меньше 0.5% от объема задачи); доступность для начинающих разработчиков. Я буду рад обсудить нашу идею и не исключаю, что кому-то из Хабрааудитории она придётся по душе.

Четыре фактора сложности: анализ задачи

Итак, берём задачу (плохо поставленную, формально не описанную — всё как в жизни). Выполняем экспресс-анализ: а именно, собираем в голове (или на доске) интуитивное представление о том, какую функциональность нужно реализовать и как технически эта задача может быть выполнена.

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

Факторы сложности, они же проекции, условно называются так:

Поверхность в общем случае — это площадь соприкосновения нашей доработки с внешним миром. Например, для GUI компоненты следует составить некое количественное представление о будущем числе элементов интерфейса. Для библиотеки — о числе методов в публичном API. Для баг-фикса — об объеме затронутого кода. Для стейт-машины — о классах входящих событий. В случае, если у нас в задаче «и то, и другое, и третье», то надо задуматься, что из этого внешнее, а что, по сути, приватное, и именно публичную часть и оценивать.

Тестирование — это наше представление о количестве элементарных автоматических тестов, которые нам придётся написать для исполнения в стиле TDD. Это не обязательно предполагает, что мы будем разрабатывать через тестирование (говорят, настоящие ковбои вообще тестов не пишут), но для оценки сложности задачи нам нужно задуматься, какой объем тестов ей соответствует.

Требования — это наше представление об объёме того, что в классических подходах называется требования (requirements). Мы можем понимать этот фактор как размер спецификации, которую нам пришлось бы написать, если бы мы хотели полностью формально поставить задачу. Естественно, мы практически никогда не тратили время на составление подобных спецификаций — составление требований в наш процесс не входило — но имели представление о том, насколько объёмными подобные документы получаются. Выносим оценку в форме: «Чтобы формально это описать, потребовалось бы страниц 15» и идём дальше.

Технический риск — этот фактор отражает ожидания того, что придётся делать какое-то исследование, пробовать несколько подходов, или выбрасывать часть работы из-за того, что у нас что-то не срастётся. В теории, эту величину можно выразить числом от 0% до 100%, но на практике это наиболее субъективная из 4 величин. Можно действовать так: для оценки риска, придумываем все способы, как можно эту задачу завалить. Если в результате мы чувствуем депрессию и у нас появились серьезные сомнения, что мы в итоге cправимся в разумные сроки — то ставим оценку, близкую к максимальной.

Получившиеся 4 «проекции» образуют своего рода профиль задачи — становится понятным, что составляет её основную сложность. Одновременно при анализе задачи происходит валидация (проверка) её постановки: если вы, к примеру, осознаете, что вам неизвестно, как вы будете тестировать свою доработку, то скорее всего приступать к написанию кода нельзя. Некоторое значение имеет и соотношение проекций — большие показатели сразу по нескольким факторам намекают на то, что у задачи есть «скрытый объём» (что угрожает многократным превышением наших ожиданий), в то время как «плоские» задачи (задачи с одной доминирующей «проекцией») обычно легко просматриваются и делаются в ожидаемый срок. В том же случае, когда задача изначально казалась небольшой, и действительно оказалась небольшой по всем оценкам, время на размышления всё равно было потрачено не зря: как минимум, мы подтвердили, что у нас есть достаточное понимание того, что надо реализовать.

Такой экспресс-анализ проводится быстро, и даёт достаточно ясное представление о сложности и трудоёмкости задачи. Можно было бы и закончить на этом, ограничившись качественным подходом. Однако, мы на самом деле пошли намного дальше и синтезировали из этой концепции экспериментальную метрику.

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

Экспериментальная метрика

Как мы уже поняли, на начальном этапе 4 проекции выражаются примерно так: «в нашем компоненте ожидается штук пятьдесят методов, двести тестов; потребовалось бы 20 страниц описания, которого никогда не будет, и есть примерно 10% шансов все переделывать заново». Теперь, когда мы это всё оценили, нам потребуется эти количества агрегировать. Но просто так сложить тесты и шансы, конечно же, нельзя, поэтому наши оценки предстоит конвертировать в условные единицы сложности.

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

Формула

Для получения итоговой метрики суммируем все наши оценки в единицах сложности по четырём шкалам.

Однако, если в двух и более шкалах у нас получилось ≥2 — то два наибольших числа мы не складываем, а перемножаем.

Использование

Метрика сложности даёт представление об объёме интеллектуальной работы, явном и скрытом, и даже может быть конвертирована, почти механически, в пессимистическую оценку времени. Как это сделать, смотрите ниже, но сначала я рассмотрю несколько более легких сценариев использования. Некоторые из нижеизложенных способов вообще не привязаны к тому, как именно вы получили метрику — они просто показывают, как можно извлечь какую-то пользу из подобной числовой величины.

Выбор технического решения

Когда вы пишете большой и сложный проект, бывает, что у вас есть два-три приемлемых способа добавить некую функциональность, и вам нужно заранее предсказать, какой путь будет проще. Чтобы принять решение, вы можете оценить каждый из вариантов по 4 факторам и сравнить значения (правда, выбирая более простой путь, стоит задуматься, не добавляете ли вы технический долг).

Валидация задач

Метод обладает интересной способностью выявлять скрытую сложность задачи за счёт того, как в нём устроена арифметика и шкалы (тот самый скрытый объём; см. также раздел «опыт использования»). Если вы не ограничиваетесь качественным анализом, а вычисляете метрику, то вы можете сделать постановку задач лучше. Для этого, вводятся два критерия:

Составление бэклога

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

В начале итерации производится оценка того, что вообще возможно сделать за этот период времени и происходит уточнение задач, в результате чего получается некий перечень, аналогичный бэклогу из User Story и/или других форм описания задач.

Известное преимущество стандартного бэклога в формате User Story перед «планом работ на период» состоит в том, что его не обязательно точно оценивать, в силу своебразной «магии» скрама. Но здесь есть важный нюанс. Если задачи, как это происходит во многих командах, разбиты не в каноническом формате User Story, а более крупно, или более «архитектурно», то упомянутая «магия» легко ломается: качество оценки размера задачи в начале итерации начинает играть критическую роль. Это очень распространённая ситуация, в которой вам может потребоваться и набор исторических данных по прошлым задачам, и вычислимая метрика, которую вы используете в начале итерации как оценку размера для задач, вызывающих сомнения. Поскольку неправильно выбранный состав итерации наносит вред и продукту, и мотивации разработчика, прилагать усилия к адекватной оценке задач бывает более чем оправдано. Я бы рекомендовал это делать.

Boost your Scrum

Scrum-команды, как правило, выставляют оценку задачам в условных единицах (Story Point). Сделать это не всегда просто. Практикуются относительно сложные процедуры, такие как Planning Poker.

Применение метода в стиле Agile заключается в том, что мы считаем предлагаемую метрику в тех случаях, когда у нас есть сомнения относительно размера задачи или возможности её реализации. Поскольку для отдельной задачи все расчёты и оценки по этому методу можно проделать в уме, это проходит достаточно безболезненно и без больших методологических споров. Имеется также возможность «партизанского» применения этого метода — если задачу оцениваете вы один, как разработчик, и 4-х факторный метод у вас работает, то вам необязательно рассказывать на стендапе всю эту механику.

Нужен план?

Заранее прошу прощения у тех читателей, для которых «планирование» — это ругательное слово. Оставшуюся часть читателей хочу обрадовать, что из метрик выводятся и непосредственные временные оценки, если действовать аккуратно. Стратегически планировать так, наверное, не получится. Однако, одним из преимуществ метода является возможность предварительно оценивать довольно крупные блоки задач.

Планирование с метриками строится на предположении, что задачи по своему будущему фактическому объёму будут соотноситься как их метрика объёма. Конечно, сложность и объём — понятия не эквивалентные, ведь порой лишь часть усилий разработчика направлена на собственно решение задачи. Если вам, помимо программирования, приходится заниматься какой-то малоинтеллектуальной деятельностью, вроде написания тонн XML, ручного неэффективного тестирования или трудоёмкой процедуры деплоя; если вы вдобавок ведете переговоры с заказчиком и пишете манускрипты документации, и все такие занятия неравномерно распределены между задачами — я вам могу лишь посочувствовать. Вам придётся самим придумать, как оценить непрограммистскую и малоинтеллектуальную деятельность. Однако если такой работы немного, – а в хороших проектах её немного, – вполне можно себе позволить считать для целей планирования, что Объём == Сложность, и не вносить дополнительные поправки.

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

Альтернативно, если вы планируете для себя одного, можно поступать проще: вычислить исторически некоторый коэффициент «скорости» и механически вычислять прогноз времени, деля на коэффициент метрику очередной задачи. Но так планировать получается хуже, чем когда вы видите цельную картину. К тому же, калибровка подобного коэффициента — занятие не из приятных. Схожий подход со «скоростью» вполне работает в Scrum с его BurnDown диаграммами, но там он выглядит более эффективным и естественным. Можно сказать, что концепция Scrum Velocity представляет собой более тонко устроенный механизм, чем просто пропорция между объёмом и временем.

Опыт использования

Для небольшой задачи, как показывает практика, оценки и арифметика выполняются в пределах минуты в уме. Для больших компонент требуется чуть большее время, но всё равно метод может выглядеть как быстрый, устный расчёт, дающий приемлемый по точности результат — обычно, более точный, чем интуитивно озвученный прогноз в N дней. Бывали случаи, когда я эти цифры подсчитывал и складывал в уме на митинге, пока мои коллеги из других команд занимались настоящей работой — тайком закрашивали клеточки в Buzzword Bingo.

Едва ли можно назвать этот метод очень простым, но зато он отличается полезной способностью выявлять неявную сложность — даже такую, которая скрывается в плохих библиотеках и инструментах, в плохой архитектуре, в нелинейности трудозатрат, в техническом долге. Отчасти, этому способствует нелинейная арифметика, но в целом выявление скрытой сложности происходит скорее за счёт того, что шкалы оценки не вполне ортогональны: рассмотрите несколько вариаций реальной задачи, и вы заметите, что даже изменения, дающие прирост преимущественно по одной шкале, всё равно отчасти проявляются и в остальных. При этом характерно, что в одних случаях такой перенос проявляется сильно, а в других — слабо. И чем меньше выражен перенос, тем интуитивно проще и легче выглядит соответствующая доработка задачи, не так ли? Формула, действительно, использует то наблюдение, что разнообразные «подводные камни» никогда не проявляются преимущественно по отдельной шкале, но их наличие существенно поднимает вверх одновременно две-три проекции. Нелинейность формулы «ловит» этот эффект, создавая существенную прибавку к рассчитываемому значению.

Из-за этих анатомических деталей, 4-х факторная оценка, хоть и требует больше времени, но почти всегда получается лучше, чем простые оценки «по аналогии» или оценки на основе отдельного фактора.

Сам я практикую этот метод эпизодически уже несколько лет. Моя привязанность к нему вызвана несколькими причинами. Во-первых, при аккуратном применении он даёт заметно более точный прогноз, чем другие примитивные методы. Во-вторых, он достаточно гибко адаптируется к тем или иным методологиям разработки: с некоторой натяжкой его возможно применять и в «чистом» Agile окружении, и в гибридных проектах, и в условно «классическом» проектном менеджменте с Microsoft Project поверх команды программистов. Я также замечал в нём некую приятную масштабируемость — иногда возможно применять подобную оценку не только в малых (bug, story. ), но и в более крупных временных масштабах (блок функциональности, компонент). Наконец, метод помогает обучению оценивающего: всегда имеется возможность сравнить фактически состоявшиеся показатели (объем кода, сложность тестирования и т.д.) со своими ранними оценками, и сделать предметные выводы.

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

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

Источник