Comments 17
Любил я этот момент, когда читал проектное управление на втором высшем. Лекция по оценкам сроков. Сидят, слушают - устали, вечер уже. Подкидываю невинный вроде бы вопросик:
- Когда ваш начальник спрашивает, сколько времени займет у вас задача, с какой вероятностью вы укладываетесь по срокам в данный вами ответ?
Пауза, все думают, потом с разных столов прилетает "90%", "60%", "10%". Я сижу, улыбаюсь, а они глазами друг на друга в наступившей тишине - хлоп-хлоп. Потом начинается галдеж минут на пять. Вроде же учатся вместе второй год, и вот тебе на...
Тут-то я им и рассказываю про методику оценок Джоэла Спольски, которую раскрывает эта статья. Очень хорошо заходит тема. Понимают, что люди бывают разные, очень разные.
Всегда поражался как люди молятся на эти SP, при этом все понимают что есть коэффициент перевода SP в реальные дни, но все равно вся scrum-бухгалтерия должна быть в SP.
Или вера в то что замена арабских цифр на римские что-то меняет - как по мне, так это просто насмехательство того кто это придумал над разработчиками.
при этом все понимают что есть коэффициент перевода SP в реальные дни
Я подозревал это и поставил у себя 1 SP = 1 день (задач меньше чем 0.5 SP практически нет).
замена арабских цифр на римские что-то меняет - как по мне, так это просто насмехательство того кто это придумал над разработчиками.
Когда-то видел запись римскими цифрами вещественных чисел, в другой сфере разве что.
Коэффициент индивидуален для конкретной команды, и высчитывается после нескольких итераций оценок.
ну ок, ну высчитали один раз этот коэффициент, дальше-то зачем использовать SP? По факту происходит следующее: люди оценивают в днях, ошибаются, вычисляется коэффициент ошибки и люди могли бы сами умножать на этот коэффициент, но нет же, придумали магическую сущность SP, которая будто бы решает какие-то проблемы (спойлер: не решает, кроме разве что психологических - особо тревожным стыдно что они ошиблись в днях, а так можно всегда сказать что просто изменился коэффицент перевода из SP в дни)
Что это не оценка, а что исполнитель обязуется сделать за X дней.
Сразу вопросы идут подтверждающие взятие обязательства — точно сделаешь, сам ведь сказал, тебя никто за язык не тянул?..
(тянул конечно, это работа менеджера тянуть за язык и брать обязательства, иначе зачем он нужен если не управляет командой)
Наблюдал это всегда — так удобно считать руководителю — все подчиненные взяли обязательства.
А оценка в сторипоинтах остается ОЦЕНКОЙ, хоть и прямо пересчитывается в дни.
Чем-то это напоминает у.е. в 90ых. Все знают что у.е. это доллар, но не называют его долларом.
Вообщем SP это некий самообман осталось только понять ради чего. Типа чтобы не ругать разработчиков за большие промахи в оценках, ну не ругайте их за промахи в днях.
Кстати, я напоминаю, что в этих ваших скрамах нет такой роли как менеджер
Все равно есть руководитель который нанимает, увольняет.
И решает вопросы состава команды — вот он и руководитель.
Или кто это делает в скрамах?
в ванильном скраме есть заказчик (внутренний или внешний). а вопросы найма и прочая бытовуха ванильным скрамом не описываются, кстати
А так-же бюджетом — в проекте же не бесплатно кодят для души:?)
Ты входишь в проект потому, что тебя на него нанял ЛПР — менеджер.
И уходишь из проекта потому что не понравился менеджеру.
Либо менеджер тебе не понравился(.
Решение об оплате каждого платежа и его суммы принимает менеджер.
Все кто в проекте прошли этот путь.
И на этом крючке.
И скрамом не описывается)
А что тогда описывает скрам?
Розовых поней?
SP больше предназначены для организации диалога команды о реализации задачи, чем для сбора реальной статистики и итоговой оценки времени реализации задачи в часах/днях. Во время покера не интересны средние оценки, интересны крайние оценки. Один говорит: 1, другой 100500. Вот это интересно, так как тот, кто оценивает задачу простой, может знать о уже реализованном функционале ("немного допилим и переиспользуем"), второй знает о каких-то траблах, о которых никто другой не в курсе ("нам там интегрироваться нужно с продуктом Х, а у них неделю назад ушёл последний разработчик, есть только менеджер, который ещё на испытательном и не набрал экспертизы").
А так, в целом, согласен. Из гибких подходов разработки слепили религию Agile с массой сект, вроде Scrum, и священниками в лице скрам-мастеров и им подобных, многие из которых ни строчки кода не написали (был у нас один такой диджей с радио, Антон, привет!)
Но в общем случае SP не пересчитываются в дни. Допустим, у нас есть спринт в 10 рабочих дней и статистика говорит, что мы успеваем сделать 5 задач по 2SP. Означает ли это, что 1SP = 1 день и первая задача будет готова к третьему рабочему дню? Нет, потому что в реальности разработчик будет её пилить два дня, потом день советоваться с соседом, потом ещё пол-дня её будут гонять в тестах, день разбираться с упавшим тестовым стендом и день фиксить найденные баги. К концу спринта она будет готова и другие 4 такие же задачи тоже. Но если кто-то в начале скажет "эта задача займёт 2 рабочих дня", то очень скоро выяснится, что заказчик/менеджер/ребята-смежники ждут её к среде.
Ещё из моего описания может показаться, что 5 задач так не успеть. Но работает-то несколько людей. И пока тестировщик тестирует одну, разработчик обсуждает с дизайнером дизайн другой и начинает писать третью. Ну и разработчиков обычно более одного.
Поэтому утверждение "мы текущим составом команды успеваем 10SP за спринт" приносит пользу, а "вот такую задачу делать два дня" нет.
Оценки в часах работают вполне приемлемо.
Для вероятностных оценок в часах неплохо работает метод PERT, который Дядька Боб описывает в книжке «Идеальный программист».
Статистика - это про большие числа. Вряд ли у вас есть статистика "мы сделали 1000 интергаций с Apple pay и в среднем это занимало Х часов"
Так-то да, но вряд ли бы эти оценки вообще работали, если бы для точной оценки требовались минимум 1000 итераций одной фичи. (а может, они и не работают вовсе?)
Возможно, спасает тот факт, что одна оценка - это некое среднее значение оценок каждого члена команды. Эти оценки субъективно начинают быть более-менее точными уже после нескольких итераций, хотя я не считал СКО, и оно, возможно, принимает дикие значения.
Почему абсолютные оценки задач не работают и как тогда планировать?