Комментарии 25
Было заявлено три подхода, но по факту всё про один - относительная оценка задач с корректировкой соотношений через статистику. Который нужно собирать через сервис, который вы рекламируете, так?))
Правильно ли я понимаю, что оценки каждой задачи дают все члены команды?
Что бы оценить сложность задачи, нужно как минимум ее хорошо понять. Это требует времени. Если в команде, например, 5 разработчиков, то изучение задач может сильно затянуться.
Еще вы говорите про сложность задач. Как раз время на выполнение задачи напрямую не связана с ее сложностью, если под сложностью понимать именно сложность. То есть задача может требовать нешаблонного решения, но если решение будет найдено, то реализация может быть быстрой.
Еще стоит разделять время, требуемое на реализацию задачи и время на ее тестирование, так как есть задачи, которые можно быстро сделать, но тестирование может потребовать много времени, а может быть и наоборот.
основная типовая проблема - это баланс времени, потраченного на оценку и реализацию. Глубокая оценка с проработкой зачастую - это 80 процентов времени и успеха задачи. Так тратить их заранее только для того, чтобы решить, ехать ли в спринт или нет - кощунство, ведь задач в хорошем продукте куда больше, чем людей, они имеют тенденцию устаревать, меняться, отпадать - и жалко как-то потратить время и не сделать
Отсюда и вырастает процедура экспресс-оценки в попугаях, которая дается для того, чтобы просто взвесить задачу на предмет профит/трудозатраты относительно других задач и выстроить приоритеты.
Совершенно очевидно, что любая задача может оказаться быстрее или медленнее, чем планировалось. Но это нивелируется в обе стороны другими задачами спринта, так как в одну задачу ты по факту недозаложил 3чд, в другой сделал на эти же 3чд быстрее. Если исполняется 90 процентов запланированого - значит планирование эффективно. Главное себе не врать и не оценивать овермного или овервпритык. Именно честная оценка, + чуть перезакладываться ведет к успеху (так как тогда ты можешь не сделать 1 задачу, ставшую из Mки XLкой, но сделав вместо этого 7XSок). Бизнес-заказчик это вполне поймет и одобрит, ну и рассматривать лишь 1 задачу, вышедшую по срокам с конкретными объяснениями просто и понятно.
Если же ситуация, что задачи сделаны, а время осталось... ну техдолг, задачи по приоритетам из след.спринта и все такое - легко найти занятость, короч. Как итог - команда не выгорает на переработках, планы исполняются, прогнозируемы, релизы ожидаемы, сроки и бюджеты бьются, премии лутаются и командой и бизнесом, все в срок, все путем.
Для этого нужен адекватный рук.команды/лид, который отстаивает объем спринта (что-то добрать=что-то выкинуть), не планирует оверсайз, и умеет объяснить и договориться с бизнесом, почему так и столько без торгов на рынке "делайте быстрее" или "ну позязя, еще вот это", и при этом система гроу разделена от системы поддержки и эксплуатации (дежурные в команде/дежурная команда на инциденты, а не овертаймить, чтобы что-то починить и переключать контексты). Ну и продакт/бизнес, который учится быстро/уже умеет в адекватные приоритеты и на связи с командой тесно.
Вот, собственно, и вся разработка 2000-2025. Проводи своевременно оценки/грумминги, планирования, мутите ретры, чтобы высказывать друг другу и решать проблемы, как делать лучше, тусуйтесь и относитесь к продукту, как к своему, отстаивайте свои интересы, но иногда в обе стороны прогибайтесб под потребности, делитесь между бизнесом и разработкой планами, цклями и проблемами и вместе ищите способы их преодолеть - и успешный успех IT-разработки достигнут.
абсолютные оценки в часах не работаю
Какое сильное утверждение.
А T-Shirt оценка работает?
То есть если новая команда (или новый человек в команде) скажет, что это L-задача - мы сразу получим точную оценку в отличие от того? если тот же человек скажет - примерно 5 дней?
В статье было про сбор статистики. И про то, что "zero-shot" не слишком достоверен. Потому оценку в часах-стори-поинтах-размерах надо корректировать при помощи статистики, собираемой на протяжении не нулевого времени. И, внезапно, при статистической корректировке "абсолютные оценки в часах" на удивление заработают.
Но это ж скучно? T-Shirt звучит круча часов? И явно ж открывает принципиально новую реальность и позволяет легче себя/методику продать... Ну а там кто проверять будет, что под капотом. Не правда ли?
Интересная точка зрения. Согласен почти со всем кроме некоторых моментов:
Абсолютные оценки в часах не работают
Но постойте, как же Принцип Доказательного Планирования от Joel Spolsky? Я думаю, оценивать в реальных часах конкретными людьми для последующего анализа - это нормально. Подробнее изложил здесь, если интересно - там есть идеи как вычислить, насколько обманет конкретный разраб, который сказал "Это на пару часов".
С этим тоже не могу согласиться:
если за последние три месяца 80% задач размера M выполнялись в течение 5–7 дней, то с высокой вероятностью новая задача аналогичного размера займет примерно столько же времени.
А если процессы совершенствуются с течением времени? Мой контраргумент коротко: разные люди работают с разной комфортной скоростью, в любой момент времени статистика конкретного исполнителя может удивить - люди развиваются и деградируют, и это надо иметь ввиду.
Согласен с тем, что необходимо вводить абстрактные критерии оценки сложности фичи (попугаи, пятибалльная система, футболки и т.д.) - зачастую сложность определяет комфортную скорость работы.
Если совершенствуются, вы увидите с течением времени. Статистику нужно смотреть по месяцам, и как раз отслеживать тренд.
я наверное явно не указал в статье, но лично я всегда делаю фокус на метриках целиком на фичу, а не конкретном исполнителе. Потому что важно понимать возможности всей команды статистически а не отдельного участника.
Опять очередное откровение от «помогателя в налаживании процессов». И опять про «майки».
Когда на очередном промежуточном контроле заказчик или руководитель спросит про причины отставания на месяц, заметьте - на месяц, а не на пару трусов с вышитыми крестиком числами Фибоначчи, автор ему тоже начнет втирать про то, что думали обойтись тремя маленькими майками, а среди них затесалась одна большая и вот упс...? Нет, перейдет на такие сермяжные дни и недели.
Ни один из этих профессиональных суетологов не смог мне объяснить, почему после 3-5 спринтов оценка в майках становится удовлетворительно точной (ха-ха - в майках и точной), а оценка в днях - нет. И уж тем более не признался, что вся эта ерунда ему нужна только для того, чтобы несколько месяцев его не могли вышибить пинками на мороз по причине внезапно открывшейся непригодности к реальной работе.
Кстати, для 7 лет на этом «швейном» производстве у автора довольно длинный послужной список. Пришло что-то в голову, что пора перестать явление под названием «чес» относить исключительно к шоубизу.
Ну тогда расскажите почему оценка в часах лучше?
для меня - не важно в чем вы оцениваете по большому счету, важно то что вы смотрите статистически и уже берете факты за основу, а не прогнозы пальцем в небо, тем самым обманывая своего заказчика и перенося сроки из раза в раз.
Да пожалуйста...
Живете в реальном мире? Время на ваших часах не в носках или колготках показывается? Вышестоящие руководители сроки выполнения работ не в пеленках или памперсах устанавливают? А прогноз о сроках сдачи проекта требуют в днях-месяцах, а не еще в какой-нибудь мануфактуре?
Вы же профи! Гуру! Так имейте смелость выдать всем участникам процесса вменяемые оценки в реальных единицах времени. И от исполнителей "налаживаемых процессов" требуйте того же. Вводите коррекцию с учетом статистики по данной команде, можете даже попускать пыль в глаза "фибоначчами" и "покером". Но - говорите о реальных сроках по каждому спринту, по каждой фиче, по каждой задаче. И отвечайте именно за эти сроки. Принимая покорно плюхи за возможное непопадание в прогноз.
Понимаю, это сложно. Работать - всегда сложно. И "помогать налаживать процессы" - тоже сложно. Но зато если сдюжите...
Так те же оценки попугаев они все равно переводятся так или иначе в сроки. Мы лишь статистически знаем какой обьем работы команда выполняет за спринт. За 2 недели, и можем прогнозировать следующие периоды. Но не просто часы которые кто то потратил, а сколько целиком команда завершила фичей в спринт. Именно завершила, а не просто поработала работу.
Либо мы знаем что задачи категории S завершаются в 85% случаев до 5 дней например в таком составе команды.
Ну и зачем тогда совершенно лишняя промежуточная сущность, если все равно все переводится "так или иначе в сроки"? Наукообразие для придания хоть какого-то смысла своему занятию поднять на ровном месте? Чтобы на голубом глазу заявлять, что мы, мол, научились исключительно точно измерять сложность работ в АйТи в майках и носках?
Вакуумная статья. В продукте мудрые продакты/овнеры покивают головами, и сначала спросят, когда будет готово, а потом когда начнет подгорать станут выжимать календарный план и подписанную кровью оценку.
В аутсорсе наверно в лучшем случае покрутят пальцем у виска, но скорее всего пройдут мимо, чтобы не связываться.
А так все красиво, по Agile. И задачи, конечно, от проекта к проекту одни и те же. В принципе можно еще посчитать среднее количество времени, требуемое на ctrl-c/ctrl-v переноса кода из файла в файл.
С этими оценками задач в предметах одежды, сторипоинтах и тому подобному замечен еще такой момент: в итоге это все сводиться к часам, но при этом всем приходится делать лишние приседания с конвертацией в уме.
Банально даже тут в статье пример и ты волей-неволей будешь это конвертировать:
Задача A (1 SP) занимает 2 дня.
Задача B (3 SP) обычно занимает 5–6 дней.
Задача C (8 SP) может растянуться на 2–3 недели.
Кажется, что оценки в майках служат совсем другим целям
абсолютные оценки в часах не работают
А потом:
Задача A (1 SP) занимает 2 дня.
Это то же самое, что сказать "оценки в сантиметрах не работают, поэтому будем оценивать в дюймах".
Разработчик говорит: «Это на пару часов». Проходит день, потом два, и выясняется, что в процессе работы всплыли интеграционные проблемы, тестировщики нашли баги, а кто‑то еще ждет согласования. В итоге задача, которую оценили в несколько часов, затягивается на несколько дней или недель
Разработчик говорит: «Это на пару сторипоинтов». Проходит день, потом два, и выясняется, что в процессе работы всплыли интеграционные проблемы, тестировщики нашли баги, а кто‑то еще ждет согласования. В итоге задача, которую оценили в несколько сторипоинтов, затягивается на несколько спринтов
Вместо того, чтобы пытаться точно оценить время выполнения каждой задачи, собирайте реальные данные о том, сколько времени занимает выполнение похожих задач.
Что-что-что? Я вижу фразу "сколько времени занимает"? А почему это вдруг времени, а не ткани, хлопка, или из чего там сторипоинты шьют?
Вместо того, чтобы признаться самим себе, что учёт всегда ведётся только во времени, проджект-менеджеры по всему миру изобретают новые названия для всего, что было придумано до них сто лет назад.
Единственная здравая мысль в вашей статье - это то, что задачи нужно оценивать, опираясь на реальные сроки выполнения похожих задач в прошлом. Если задача в прошлый раз заняла 20 часов, то будет столько же и в этот раз. Аналогично и со сторипоинтами - было 10 СП в прошлый раз, будет столько же и в этот. Но если разработчик ошибся и назвал вместо 20 часов 4, то он точно так же ошибётся и со сторипоинтами, назвав один вместо трёх.
И ещё, не надо спекулировать на том, что якобы точное прогнозирование в часах невозможно. Если у вас один сторипоинт занимает два дня, вы точно так же можете прогнозировать сроки в часах с квантом в 16 часов и у вас всё будет сходиться так же, как на сторипоинтах.
Мы спорим в чем измерять время, в часах или попугаях, трусах, майках...,
Но у меня возникает вопрос: а вообще зачем оценивать время выполнения задачи? Ведь стоимость проекта мы так не определяем.
Конечно, если аврал, можно поднапрячься, иногда можно (и нужно) чуть расслабиться.
Занимаясь прогнозированием по каждой задаче, мы тратим время и силы команды на бесполезную активность. Почему нельзя просто спокойно работать? Если руководство считает что за те же деньги может найти других, которые будут работать быстрее, пусть ищет, это его право.
если вам не надо обещать сроки - замечательно можно работать.
как сказала одна девочка РП из Яндекса на каком то тренинге: "вы знаете, наш best practice, это по возможности не давать никаких сроков заказчику, потому что все может поменяться.
А заказчики, паразиты, вечно просят определенности, все беды от них :)
Если серьезно, когда РП подписывается под срок реализации, он должен подписываться не сам (ибо он просто админ), а с командой. Вот тут каждый участник начинает отвечать за свою работу. И тут у каждого исполнителя персональная отвествтенность
Я не говорил, что не нужно давать сроков заказчикам. Их можно и нужно давать давать и нужно стараться выполнять.
Сроки по проекту определяются на основе верхнеуровневого анализа. Мы не знаем всех атомарных задач и не складываем время на выполнение каждой, что бы озвучит сроки заказчику.
тогда прошу вас, поясните, что вот тут вы имели в виду: а вообще зачем оценивать время выполнения задачи? Ведь стоимость проекта мы так не определяем. Как вы определяете стоимость проекта?
Ну и подвопрос: если вы его определяете без учета оценок от исполнителей, каким образом вы страхуете риск превышения бюджета и сроков и демотивации команды (которая сроков не давала, а их директивно спустили сверху)?
В статье идет речь про оценку атомарных задач при планировании спринта. Это оценка происходит, когда оценка сроков по проекту, или просто по конкретной бизнес задачи уже дана.
Как оценивать сроки по проекту целиком статья не рассматривает, и я каких то советов давать не буду.
Ага, спасибо.
А оценка атомарных задач к оценке общей не имеет отношения в вашей методологии?
В моем понимании (почему и спрашиваю):
Оценка атомарная сама по себе никому не нужна, всех интересуют сроки. И в статье выше речь про сроки, которые даются на основании прогнозирования исполнения атомарных задач.
для меня естественно, когда высокоуровневые оценки делает, условно скажем, тех лид.
Но далее , при более детальной декомпозиции, все задачи оцениваются непосредственными исполнителями. Для чего это надо - я написал в комментарии к статье: каждый берет ответственность за свой небольшой объем. Если оценка превышает ту, что дал лид в первоначальном виде, это повод уже лиду обсудить с командой, что не так (далее или лид признает косяк или исполнитель соглашается с лидом.
Таким образом получаем равномерное распределение ответственности по команде, каждый отвечает за свое и учится своему (и отвечает не только РП, с которого спросили оценку)
Тут ответ простой. Разработке можно работать просто. А те ребята, которые этой разработке платят, планируют сроки и деньги, чтобы оценить возврат инвестиций. А для этого надо знать, что тот или иной продукт или фича выйдут в таких-то пределах, потребуют столько-то людей (которых надо донанаять и обучить к такому-то сроку), когда нужно докредитоваться и получить определенный объем денег на счете для того, чтобы платить зарплаты и дивиденды, да и прочие подобные скучные вещи. При этом никто не требует точного до дня планирования, так как планы идут кварталами и годами, но хочется, чтобы эти планы выполнялись в целом, и для этого и нужны взвешенные и не пущенные на самотек процессы, а какое-то внятное по процедуре планирование в спринт, в силы команды и в людей. Так как эти сущности не прогнозируемы точно, то идет вероятностная оценка, выстраивается доверительный интервал в +-20 процентов, и балансируется переработками/уделением времени в обучение и техдолг, чтобы все заработали свое бабло. Кодить в вакууме хорошо, когда ты несешь отвестственность за самого себя. А когда у тебя таких кодеров 15000, бюджеты в миллиарды и триллионы - без планирования и слоя бюрократии никуда. Главное без перегибов и энтузиастов бюрократии - чтобы эта процедура была быстрой и БОЛЕЕ-МЕНЕЕ реальной, в среднем сходилась, риски учитывала и ехала
Вообще, сбор статистики по метрикам среднего выполнения, отклонений и тп - безусловно интересная штука.
При этом отказ от оценок разработчиками ведет нас к паре интересных моментов
Разработчик не несет ответственности за сроки. С одной стороны, мы создаем комфортную среду для разработчика, с другой - снимаем с него ответственность за выполнение задачи. А ответственность - мера взрослости. Умение дать оценку и попасть в нее - это , по сути, менеджерский скилл. А менеджер, по Адзизесу - любой, кто дает срок на работу. То есть оценка задачи и последующее старание попасть в эту оценку создает стресс для работника, но в тоже время каждый раз делает его профессиональнее. Разговоры про искусственные завышения оценок валидны только если доверия в команде нет. Там ребята начинают страховаться. Но это претензия к РП, это не проблема исполнителей.
Итого:- оценка в часах помогает расти команде профессионально, обучаясь ответственности
- оценка в часах позволяет выделить узкие места процесса (сотрудник) и , поговорив с ним, добавить в это место резервирование.Может возникнуть соблазн (раз уж мы заботимся об исполнителях) вообще не учитывать время в трекере, потраченное на задачу. А вот тут последствия вообще могут быть печальными (некорректный учета факта)
Самое главное в оценке задачи: чтобы её оценивал тот, кто её будет выполнять.
Как стоит оценивать задачи, чтобы улучшить прогнозирование сроков?